Multiple Bootstrap versions and hooks for other ui...

[boblennes]

I've been keeping the BS3 branch up, but after a couple iterations, I have a proposal to make Bonfire friendlier to BS3 and soon to be released v4. The below pattern may also be good for others.

My thought is to add an entry into the constants.php config file:

// -----------------------------------------------------------------------------
// The 'ALTERNATE_UI' constant provides for use of other UI than the default.
// If blank OR BS2, Bootstrap 2.3.x (BS2) is used.
// The current additional UI available is: Bootstrap 3.x (change to BS3)
// -----------------------------------------------------------------------------
define('ALTERNATE_UI', '');

Then in the top of the bonfire views which have forms like login, register, et al, something the following block filled in for Bootstrap3: These lines could go in a subview?

<?php
$ctlGrpClass = empty($ctlGrpClass) ? 'form-group' : $ctlGrpClass;
$labelClass = empty($labelClass) ? 'control-label col-sm-3' : $labelClass;
$ctlWrapClass = empty($ctlWrapClass) ? 'controls col-sm-9' : $wrapClass;
$ctlClass = empty($controlClass) ? 'form-control' : $controlClass;
?>

And fields would follow the pattern:

<div class="<?php e($ctlGrpClass . iif( form_error('email') , ' error'); ?>">
    <label class="<?php e($labelClass) ?> required" for="email"><?php echo lang('bf_email'); ?></label>
    <div class="<?php e($ctlWrapClass) ?>">
    <input class="<?php e($ctlClass) ?>" type="text" name="email" id="email" value="<?php echo set_value('email') ?>" /></div>
</div>

The other hardcoded places would then reference the new constant as well.

Thoughts? And anyone wanting to help? This is assuming Bonfire might get reignited in popularity now that Codeigniter 3 is getting some steam. Btw, thank you Mat for working so diligently on keeping Bonfire kicking!

[mwhitneysdsu]

While I like the simplicity of defining a few variables in a partial view, I'm not a fan of adding another constant. I haven't been keeping up enough on Bootstrap 4 to determine whether the same scheme will work in that environment, but I'd like to see something that might have more value for non-bootstrap users, as well.

One thing I've been considering is a helper/library combination similar to the BF_form_helper (but not using the same function names, so we don't have compatibility and other conflicts to worry about). The helper would check a config value and attempt to load/call the configured library to generate the output. Rather than dealing with the headaches of CI's Driver system (which isn't going to be around much longer anyway), we could supply a base class and ensure that is loaded by the helper, then implementation libraries would extend the base class.

Unfortunately, my time has been really crunched lately, and I haven't been able to do as much as I'd like to maintain Bonfire. Thank you to everyone who has continued to contribute and send feedback.

[mwhitneysdsu]

Actually, in thinking about this some more, I'm wondering if it's possible to just use our own class names and distribute CSS which changes the definitions of those classes to fit the particular version of Bootstrap. It may be a little more difficult, or even impossible, for some other parts of Bootstrap, but it seems like it should be fairly straightforward for the forms.

[boblennes]

The downside of that is it makes it hard to use code snippets.

[mwhitneysdsu]

I don't think it would really make it any more difficult, it would just mean that they would have to be specific to (or modified for) Bonfire, rather than the CSS/JS framework.

Further, I'm not talking about modifying the Bootstrap CSS, so Bootstrap code snippets would still work, they would just have to be updated when you switched front-end frameworks, as usual.

In other words, you might have something like this:

<div class="bf-form-group<?= form_error('email') ? ' error' : ''; ?>">
    <label class="bf-control-label bf-col-sm-3 required" for="email"><?= lang('bf_email'); ?></label>
    <div class="bf-controls">
        <input class="bf-form-control" type="text" name="email" id="email" value="<?= set_value('email'); ?>" />
    </div>
</div>

In Bootstrap 2.3.2, the outcome might be equivalent to this:

<div class="control-group<?= form_error('email') ? ' error' : ''; ?>">
    <label class="control-label required" for="email"><?= lang('bf_email'); ?></label>
    <div class="controls">
        <input class="" type="text" name="email" id="email" value="<?= set_value('email'); ?>" />
    </div>
</div>

While in Bootstrap 3.x it might be equivalent to this:

<div class="form-group<?= form_error('email') ? ' error' : ''; ?>">
    <label class="control-label col-sm-3 required" for="email"><?= lang('bf_email'); ?></label>
    <div class="col-sm-9">
        <input class="form-control" type="text" name="email" id="email" value="<?= set_value('email'); ?>" />
    </div>
</div>

The bf- prefixed classes would be changed by including an additional CSS file in your theme based on which version of Bootstrap (or whatever front-end framework) you are using. So, bf-form-control, for example, would be undefined or empty in Bootstrap 2.x, but in Bootstrap 3.x it would have all of the CSS required to behave as if you had used the form-control class on the input.

Other types of forms or frameworks which require a different structure in the HTML to generate a similar output would be a bigger problem than just supporting the 2 versions of Bootstrap.

As I mentioned before, I haven't had a chance to mess around with Bootstrap 4, though it looks like it should work in a similar manner. At the same time, we could probably support the slimmer HTML structure of Bootstrap 4 forms for users who don't need backwards compatibility, but still want to use the Bonfire classes in case of a future version of Bootstrap changing things further.

[boblennes]

Ok that makes sense. How do we start making the transition? I have bs 2.x and 3.x projects myself...

[mwhitneysdsu]

That's a good question. Unfortunately, I don't have a great answer, at the moment.

I'm a little concerned that, with this approach, we'll end up including 2 copies of bootstrap, one of which has all of the classes renamed to something even more unwieldy than the original bootstrap classes.

[boblennes]

I have another idea. Going with the KISS principle, and since 2.x is unlikely to change, why don't we move to v3.x and create a supplemental v2.x compatibility css file which only contains common styles like span* and others obsoleted, so older projects could run with minimal or no adjustmments... I've identified those mostly. The only hairy ones are the nav related ones. Bootstrap v4.x seems to be a less dramatic change once that comes to release... I have to say though I'm a little bummed no one else has commented on this thread...

[mwhitneysdsu]

That sounds good to me. If we could find a way to make some of the code a little less dependent on the Bootstrap version along the way, that would be a bonus.

I think we're working against a number of factors in getting more participation here, but improving the core code and making it easier to transition between front-end frameworks will eventually help bring more attention back to the project.