On 9/29/2015 16:33, Michael Babker wrote:
> Knowing full well I'm about to get told to STFU because I'm responding
> as a developer...
>
ohhhh... the temptation :P
> Moving forward, we need to decouple style decisions such as number of
> columns in a layout from the component. Those need to be template
> options. How you do this without alienating that part of the target
> audience that can barely write "<?php echo 'Hello World!';" means
> making more efficient use of our plugin system and the layers of
> overrides that exist throughout the application. Yes, this means
> template shops will need to get stronger on their PHP skills and their
> understanding of some of Joomla's cool features, like extending forms
> with plugin events or the override API of JHtml, but IMO if we try to
> move this direction in the end it only improves the ecosystem for
> everyone.
>
I would love to sit and hear you lecture in intimate detail about that
someday.
> Picking on those grid options for a moment, they right now only map
> directly to Bootstrap 2.3 spanX classes. Which makes sense, Bootstrap
> 2.3 is the core CSS framework. What about those folks who are
> building Bootstrap 3 templates or using another CSS framework
> altogether? Those options don't translate over as well. Enter the
> plugin approach. My Bootstrap 3 template framework ships a plugin(s)
> that enables my framework's design options, to include number of
> columns to use for the different viewports (I'm gonna get technical
> and map my options to the extra small, small, medium, and large
> viewports that Bootstrap offers versus trying to call them mobile,
> tablet, or desktop; to me that makes more sense and aligns with
> Bootstrap's documentation or implementation of the grid, as
> examples). So I use that plugin to add the options specific to my
> framework, the user is able to customize these aspects of their
> layouts still via the backend UI, and we take some options out of
> places in the system that they don't really belong. We get better
> data and responsibility separation without compromising usability, how
> can we go wrong here?
>
And with BS4 just around the corner all the rules change. It's going to
be an exciting and evolutionary stepping stone I think.
> Jumping to the blog.php example specifically, Kevin you can already do
> this without changing a line of core code using the layout override
> system and the API that we have for detecting the active device and
> you can use that to decide which sub-layout to serve from there. That
> alone doesn't address the column issue because like I said the one
> option that we have now is only really compatible with Bootstrap 2.3,
> and you see me arguing for not adding more of those types of options
> directly into the component but rather in a way that they can be
> altered based on the CSS and template framework in use.
Especially with the PLT(?) decision to make everything a smorgasbord of
parts to make up a single cms install
> I honestly think we're barely scraping the tip of the iceberg with
> what can be done with the existing code. Yes, right now doing some
> advanced things needs those big bad developers, but once those types
> of structures start getting released by developers and we have
> efficient examples in the ecosystem on how you can leverage our
> existing infrastructure to do some powerful things, we can start to
> change the game in the frontend department. The core CMS in itself
> doesn't need to be able to do everything under the sun, but if we
> provide the APIs to do these advanced tricks, we give the template
> developers, the site integrators, and the code purists the power to
> accomplish a lot of things.
>
core needs to have a solid , flexible , generic layout that , for
example, will look good for any blog / simple site layout. Nothing More
Nothing less. Just a great "default" layout. Everything else should
come from the magic of the template dev's minds.
Bear