Bootstrapping fabrik_subelement

[aksmith]

Hello:
I've been having issues with mobile rendering of subelements like checkboxes. In F 3.3.2, the layout is set in the 'alist' function starting at line 782 in components/com_fabrik/helpers/html.php.
Lines 788-92:
if ($options_per_row > 1)
{
$percentageWidth = floor(floatval(100) / $options_per_row) - 2;
$div = "<div class=\"fabrik_subelement\" style=\"float:left;width:" . $percentageWidth . "%\">\n";
}

This works fine for full-screen - if you set the options per row for your checkboxes at 4, then each label/input pair floats at just under 25%.

On mobile - not so good (for obvious reasons - width is not responsive).

I popped in a new variable that converts the 'options per row' to a Bootstrap integer and changed those lines to the following:
if ($options_per_row > 1)
{
$percentageWidth = floor(floatval(100) / $options_per_row) - 2;
$bootcalc = (12 / $options_per_row);
$div = "<div class=\"fabrik_subelement col-md-". $bootcalc ." \">\n";
}

Now this is perfect - the label-input pair converts to 100% width on smartphones, etc.

Caveats:
1. We all know that revising a core file is a cardinal sin - God probably kills a kitten every time we do this.
In this case, it's a minor revision of the presentation layer, so I can live with that (I kept the $percentageWidth in case it gets used downstream). It would be lovely to see this layout object outsourced to its own template file for an override that removes the inline style (hate those).
2. My templates run Bootstrap 3, hence the 'col-md-$' syntax versus 'span$' (Bootstrap 2). Retrofitting my css universe to run Bootstrap 2 side-by-side is bit awkward - I would be curious to get the view from 30,000 feet on what a full-scale conversion of Fabrik to Bootstrap 3 would entail.

Cheers!
Alan

 

[cheesegrits]

I don't mind putting this in the code, with our usual "if ($j3)" test around it. I think the only way I can do BS 2 and 3 is to add both classes, col-md-X and spanX, which I don't think will hurt anything.

The longer term solution is to convert all of our markup to use layouts. We've converted all (I think) of the non sub-options elements to use layouts, but ones based on the elementlist model (an extension of the main element model, for elements which have sub-options) haven't yet been converted. We've also made inroads into converting a lot of other things we generate the markup for in the core code, into layouts, like filter displays etc.

The beauty of layouts being that you can override them. So in effect each element type (or whatever) then has it's own little mini, customizable template. So you could then make whatever BS3 tweaks you need.

It's work in progress ...

-- hugh

 

[aksmith]

Hugh:
Element layouts (with overrides) would be awesome!!
I'll keep an eye on github for updates.
Thank you!
-Alan

 

[cheesegrits]

Hmmm, any idea why I'm seeing this, with 4 options per row ... four elements on the first row, three thereafter?

http://screencast.com/t/FU94t3GFpcxd

-- hugh

 

[cheesegrits]

Oh, never mind, I figured it out. Forgot I'll need row-fluid containers around tuple for BS2.

Hmmmm.

-- hugh

 

[aksmith]

Yup. Of course 'row-fluid' becomes just plain ole 'row' in B3. It's worth noting that B3 also changed some layout rules - .row does not have a min-height - in fact the only default rules are negative left/right margins. This does impact the layout of Fabrik element objects, esp label and input. Easy to address but potentially startling.

 

[cheesegrits]

Yeah, I can't really fix this in the helper it would have to be extracted into a layout, as unfortunately there is really no way to programmatically figure out if we're in a BS2 or BS3 site.

It really is a major pain in the ass, which we've been fighting for quite some time. We're basically hosed until J! itself moves to BS3.

And that's a bigger task than I have time for right now.

-- hugh

 

[aksmith]

Assuming that there are few (maybe none at all) BS2 selectors hard-wired into the AJAX functionality, it should not be that hard to track them down and swap out for BS3 (recognizing that there are a LOT of files). There will always be some ad hoc challenges and inline styles to remove, but I think this could be done as a fork (Fabrik 3.3.for BS3 or something). I would be willing to make an initial foray if you think it is of any value to the project.
It would certainly make my life easier - and it would be nice to leverage the improvements/new features in BS3.

 

[cheesegrits]

Really don't want to fork. We're going to be stuck with the whole BS2 vs BS3 thing for quite some time, and I really, really don't want to have to maintain two code trees. So anything we do needs to be done the same way we've handled BS2 vs No BS (J! 3 vs J! 2.5), with conditional code.

I think what we need to do is add a global config for setting for BS3.

But I need to talk to Rob before starting on anything like this, see what he thinks.

And yes, we sure could use the assistance of someone with BS3 knowledge and PHP skillz to help out. You could work on a fork and submit PR's, once we've worked out the best approach.

-- hugh

 

[aksmith]

That's actually what I had in mind (last point).
In the Fabrik MVC, converting to Bootstrap 3 would mostly involve the view with some impact on controller (theoretically could make things simpler).

The more I use Fabrik, the more ways I see how it can be implemented - the underlying concept is brilliant (maybe because I love shortcuts).
I do have another broader question - is there a strategy/plan for the js libs (i.e. continuing to run Mootools and Jquery)? Just curious - I'm fine with the current set up but some developers hold Mootools in contempt and would argue for a unified library.
I'll be happy to help in any way you feel is appropriate - I have another BS3 snippet to contribute later today (mod of the repeat group Bootstrap tmpl - replaces dynamic inline style with class name).
Cheers!

ps: nice to see there are Bernie Sanders fans in AL..

 

[cheesegrits]

No plans to convert the 3.x series to jQuery, simply because we have ... erm ... I dunno, probably tens of thousands of lines of Mootools code, and converting to jQuery would essentially be a complete rewrite of our JS. I don't know if you know the history of J!, but Mootools was the official JS framework for many years, then they decided to move to jQuery, but have kept Mootools around for backward compat, so jQuery runs in compatibility mode. Unless for some bizarre reason they decide to junk that approach, Mootools and jQuery can coexist perfectly happily. As for which one is better - they both have their pros and cons. Moo is a better "framework" for large projects, jQuery is easier and lighter. In 4.x we're moving to jQuery. But 4.x is a whole different kettle of fish, it's basically a total rewrite, with a very different approach.

Yeah, I'm all in for Bernie. There's actually a surprising number of us, at least in North Alabama. Way down South, not so much.

Do you Skype? I'd like to add you to our Skype chat where we have a few developers and power users hanging out.

-- hugh