[4.0] Subform field conflicts when merging to J4

[wilsonge]

List of PRs

#20222
#12996

Due to large merge conflicts I have skipped merging the PRs above (I just kept the current version). Basically we only set options now in JHtml bootstrap and these belong somewhere in the bootstrap init javascript file. I'm unclear exactly what the best way to 'retrigger' them are is. It's tempting to just reinitialise everything to be consistent (i.e. make the current callback in bootstrap init a named function that can also be called in the subform-row-add callback, but that could be a large performance drain. So I'm sitting on it for now and going to see if either @dgrammatiko has any great ideas, or indeed anything comes up on the tracker related to this. But this issue tracks that this was done somewhat knowingly and should be re-evaluated at a good time

Subforms Refactor (NEW)

These had too many conflicts with the new repeatable form field layouts in j4. They definitely need porting

#17552
#22444
#23190

[dgrammatiko]

Short version: once Joomla gets all the replacement components for the old Bootstrap ones this hack doesn't need to be forwarded to Joomla 4.

Long version: this issue ( #19427 ) was created as a placeholder for the JS Working Group to move all. the fields into custom elements. TBH I didn't explained enough the reason behind this (people might think that this was dictated 🤷‍♂️) so here is a good spot to explain why moving most of the scripts to custom elements is the best option.
In the previous era, call it jQuery, all the scripts were dependent on, guess what, jQuery, and this solved way too many problems and freed devs to do nice things. Since jQuery is somehow technology of the past and Joomla is embracing the vanilla (no dependencies) approach some cases need to be exposed and also the most important part the scripts should also work for these cases. So you might ask what are those cases? To answer that we need to go back to the jQuery repo and read the source code there. jQuery was a great tool, once you've queried one UL elements all the children elements were automatically tracked. Keep this word: tracked. Moving forward to vanilla javascript such a handy functionality is not provided, rightfully I would say, by default. And this might be a problem! To cut it sort: think of a vanilla script that adds accessibility to a menu. This would work marvellous out of the box, until you add programmatically another link to the menu. Then you have to either re initialise the script (pretty expensive) or use mutation observers and track the elements you care for. Hold on here, this is how custom elements should work out of the box.
There you have it then, custom elements are the closest you can get to jQuery, keeping things simple and also covering all cases.
In the particular issue the problem is exactly what I've explained above and you either:

• re initialise the script (if this is your first javascript script)
• use mutation observers
• just get the tooltips and popups as custom elements

All 3 options here will work, from a future proof point of view Custom Elements seems the best bet!

[N6REJ]

tracking

[brianteeman]

Please use the tools on GitHub to follow a topic

[Fedik]

@wilsonge drop subform script from J3 and use only j4, the script was rewritten two year ago #19184

#17552 this was need only for j3, it already implemented in j4
#22444 some random classes that may even not exits in j4, little layout changes
#23190 this fix of #17552 that only for j3, it is not need for j4

This should work without modification:
#20222
#12996
the event subform-row-add still exists in j4

[Fedik]

I just noticed the issue from Dec 2018 😁

[wilsonge]

OK if this should be working then what issues are you having @N6REJ

[N6REJ]

@wilsonge the tab shows blank when subform is used.

[Fedik]

the tab shows blank when subform is used.

This something with <fieldset> inside subform xml, maybe something changed in JForm class, or with form layout rendering.
It was fixed once in past #12813

If you remove <fieldset> from your subform, it should work again.

[N6REJ]

@Fedik that would mean half of the purpose of subforms would be lost.

[Fedik]

can you please open an issue for your problem with detail description and subform example?
it may lost here

[wilsonge]

OK Closing this as apparently none of these issues need porting