Thoughts on template/form styling

[Bauer]

Just to add to this (now closed) thread...
http://fabrikar.com/forums/index.php?threads/how-to-add-special-bootstrap-classes-to-elements.35371/

I have attempted in the past to convince the powers that be to change the way both the javascript and css for elements are presented/included in html forms.

The idea of using ?form_#.js? or the template.css php is on the right path ? but does not quite meet the real needs.

Instead of the form id being the determining factor, IMO, it should be the group id.

For example - As is now, if you have a form that contains elements from a repeat group, the ?form_#.js? that is used is taking the ?#? id from the parent form id. So any form_#.js that you may have created ? intended for use with that repeat group - is ignored (not included when rendering the html). ONLY the parent ?form_#.js? is included.

So why not make the ?#? part of ?form_#.js? - or ?details_#.js? - correspond to the group ID ? not the form ID? (And ?include_once? when any repeat group is added.)

This way you could include customized javascript pertinent only to that group ? and, when rendering a form that includes a repeat group, not have to include the javascript for the repeat group as part of the parent ?form_#.js? file (like you must do now).

Also another formatting issue where I?ve requested a change is due to the fact that there is really no unique identifier for the div wrapper that contains an element. This would go a long way in identifying that element within the form (without ?working backwards? from the input element ) when working with css or javascript for that element.

I ?fixed? this by changing one line of code in components/com_fabrik/models/element.php
At line 1940 I changed the code from

protected function containerClass($element)
{
          $item = $this->getElement();
          $c = array( 'fabrikElementContainer', 'plg-' . $item->plugin);

...To?

protected function containerClass($element)
{
          $item = $this->getElement();
          $c = array($item->name.'_'.$item->group_id, 'fabrikElementContainer', 'plg-' . $item->plugin);

This way there is a unique class name added for each of the elements - added to the element?s ?parent? div wrapper ?making it MUCH easier to identify any of the contents within that element wrapper ? (or to manipulate the element?s div wrapper itself via javascript - show/hide,etc.)

When I first edited the code, I started out adding just the $item->name as the ?unique?class ? but then came to realize that, in some repeat groups I am using, the same element name is also contained in the parent or child group/table ? so I appended the $item->group_id to make it a ?unique? identifier class name.

Wouldn't this concept (using the group id for form_#.js) - coupled with css files working in a like manner - work better than editing or having to create a custom template for each form - as your custom javascript or css files for that group would then ?work? for all form templates, whether the element is in a repeat group or not.

 

[Sophist]

Several months ago, a class was added to the fabrikElementContainer which is fb_el_placeholder. I quite like the idea of a group added, and now that I think of it, I don't see why it needs to start fb_el either.

S

 

[Sophist]

I am including this change pretty much as Bauer has coded it in a change I am working on.

 

[Bauer]

Thanks Sophist.
I was aware of the "fb_el" class being added - and that was how I was identifying an element's 'wrapper' div container. But somewhere along the way that stopped showing in the html that was being generated for the forms.

After the last github update I made (on 08/19) this "fb_el..." class was not being shown in the element 'wrapper' div. I just assumed this was another change made and (without whining about it ) spent hours modifying my javascript and css for the forms affected to compensate for this change. That was when I decided to do it 'my way'. I appreciate that you recognize my efforts.

Having a quick look at it just now, I see there are 2 references to "fb_el" in the element.php code - but I haven't dived into trying to figure out why that element-specific class stopped showing as such.

But the "fb_el..." class, even when it was there, still did not take care of the issue I was having for forms that had a repeat group containing elements with a same element name that was in the 'parent' form. Because of the way the template.css.php file works - I had to add the css styling for the repeat group into the css styling intended for the 'parent' table/group and then specify both classes - e.g. 'fb_el_tablename1___elementname' and 'fb_el_tablename2___elementname' - in the stylesheet (because the only distinguishing identifier between the 2 is the "tablename' part of that "fb_el_tablename___elementname" class). So there was still no easy way to use wildcards to distinguish between those elements with the same name when trying to reference them in css or javascript.

So this method will make using wildcards a little easier too.

Though I'd still like to be able to use/include css and js files that are pertinent only to elements in that parent group (or repeat group) rather than the 'master' form css and form_##.js file being used for controlling both the master table elements and the repeat group elements combined, as is now. This does not make configuration of a form containing a repeat group (or groups) any easier, especially for a user who is not so proficient with using css or javascript.

It is ONLY because of this "fabrik way of handling css" (and javascript) that I must create a custom template for this type of situation. The need to create a special template could be eliminated in these cases if the CSS and javascript was also 'group ID' dependent - and not "form ID" dependent. That is - if the css and javascript would each get imported into the template as multiple parts - based on the group_ID(s) as the identifier - rather than the one form_id. (Not to mention that "the way it works" is also just plain confusing to understand for users who don't understand "how it works" now.)

I'm not trying to get anyone to re-invent the wheel - but I do see this as being an issue that should be "simplified" sooner rather than later. (Even you have agreed with my calls for consistency - and right now javascript imports and css imports are being handled as if they are 2 entirely different species, when they could easily be made to both work the same way - at least if it can be agreed that they could/should.)