Compared to j3 the styling of subform field in j4 is zero

Are you talking about subform fields generally or the one in the custom fields component specifically?

In the end it use the same layout 😉
For input rendering

Yeah I am about subform fields generally, but this affect custom fields

To give some further explanation: The fields used in a subform field simply show up in the list of custom fields and it's not obvious that they belong to the subform field. At the same time it is absolutely non-obvious that you have to set the category of those fields of a subform to "none", to not have them show up multiple times. I only knew that because I searched the documentation.

It is called subfields.

we use the term "sub fields" to describe two different things - see https://docs.joomla.org/Custom_fields_type:_Subfields

Subfields contain subfields (see documentation). Why not call it fieldscontainer? Or something like that?

About the usage of a category "none". I also had to search for it in documentation and code. I found a discussion in the first PR where an extra param was mentioned "subfield_only". If this is set, the select of cateory can be hidden.
This seems a better solution.

Yep that was my idea haha. I'd still like that approach to be implemented as well: #22446 (comment)

So what do you guys think of what I had suggested in that comment?

I'm not entirely convinced about the "None" category method myself either. At the same time, I'm thinking that if a field is set to be used only as child field, then the category selection doesn't make sense for it anymore. Maybe it could be be something like...
image

It's set to "No" as default. If you set it to "Yes", the Category input disappears (hides). And if it's set to Yes, it won't display in any article form in any category (the equivalent of category "None"), but will only be available to be inserted inside a subfields field.

There could also be another menu item that filters fields by only the ones that have been marked as "Use as Sub Fields only": (sorry, using J3 interface as example)

What do you think?

Tagging the original developer as well: @continga

On another note, I also suggest:
It woud be good if an option could be added to select a maximum number of rows for the subfields (how many times it can be repeated).

Also, check this: #22923 (comment)

Just a note, I found out that this does not work for the new Subfields

Meaning that saving a subfields type that contains a disabled/hidden child field (due to ACL), will empty the value for that child field, instead of keeping the existing value for it

So to recap everything that has been reported:

1) "The fields used in a subform field simply show up in the list of custom fields and it's not obvious that they belong to the subform field. At the same time it is absolutely non-obvious that you have to set the category of those fields of a subform to "none", to not have them show up multiple times. I only knew that because I searched the documentation."

Proposed solution: Add a parameter subfield_only "Only use as Subfield"? If this is enabled, the category field gets hidden (UX) and becomes ignored (PHP).

There could also be a new list of "Sub fields" added in the navigation menu, that filters by fields set as "Only use as Subfield". Either that, or a new Filter in "Search Tools" for this.

See this comment for UX example: #28389 (comment)

2) "It is called subfields. Subfields contain subfields (see documentation). Why not call it fieldscontainer? Or something like that"

Proposed solution: see PR #32864
There is a list of suggested names ideas in my comment #32864 (comment), including "Fields Container". Let's decide there which one to use? Help us with the best terminology to use before shipping 4.0.

3) "If you have no existing fields created, and you try to create a subfields type, the UX is not clear"(#31587)

Proposed solution: If no existing fields exist, instead of the fields input, show a message that indicates that Subfields allows you to select from existing fields. So you must define those fields first.

4) "Saving a subfields type that contains a disabled/hidden child field (due to ACL), will empty the value for that child field, instead of keeping the existing value for it" (see: #22923 (comment))

Proposed solution: This is an issue so it should be fixed.

5) "It woud be good if an option could be added to select a maximum number of rows for the subfields (how many times it can be repeated)."

Would be a good idea to have this option. Right now you can create unlimited repeatable rows and it might not be always the use case. There is a data-maximum="..." in the subform parameters, so this should be easy to implement.

Let me know if I missed something.

@AndySDH Could you please look at my prototype PR #33096 to see if we should go with that approach?

@AndySDH Could you please open a new issue for your the item #4 in your suggestion so that we can look at it and get it sorted?

For #5, I guess it is a nice to have feature and we can leave it to future (not a release blocker)

Do we need a new issue for #4? I think it's well explained and referenced. We only need a PR for the fix if someone is willing to do it.

For #5, I agree that it's only a nice-to-have feature, not a release blocker. But it's so much of a super quick fix, that I think it may be worth adding it at launch already, as I imagine is a very quick implementation (the subform only needs to have the html data-maximum="..." attribute added to set a maximum # of rows)

the subform only needs to have the html data-maximum="..." attribute added to set a maximum of rows

The subform field already have min/max attributes https://docs.joomla.org/Subform_form_field_type

the subform only needs to have the html data-maximum="..." attribute added to set a maximum of rows

The subform field already have min/max attributes https://docs.joomla.org/Subform_form_field_type

I know, that's whay I'm saying. We only need to add a Field Option for the user to enter a number of maximum rows they want for that field. And put that number inside the data-maximum="..." attribute :)

@AndySDH Added Max Number Rows parameter. The remaining thing is #4 but that's hard to fix (I don't understand custom fields enough find a solution). Unless someone comes up with a solution, we might have to stay with that limitation for now. Personal, I think that if user does not have permission to edit value of a child field, he should not be allowed to edit other fields in the Subform, too, and in that case, the system is still working properly.

if user does not have permission to edit value of a child field, he should not be allowed to edit other fields in the Subform

I agree.

For now we can do like this:
Child fields inherit access from a main Subform field. Or just ignore access for child fields in general :)
(maybe just hide access field if it a "child field", if possible)

What is asked in 4 requires an extra logic in before save, to preload previous data and merge with User data.
We can leave it for future improvement.

Awesome! Great job @joomdonation, thanks for your effort!

I will test this current PR probably today, and confirm if everything works!

We can close this as we have working PR

@AndySDH Once you confirmed that the PR works and solves the issue, we will close this issue and mark the PR as ready for testing/review.

Received good feedback from @AndySDH for the PR #33096 , so closing this issue.