#1130 ✓resolved

Feature request: develop better paradigm for multi-framework operation

Reported by dleffler | January 27th, 2014 @ 09:03 PM | in 2.3.1 (closed)

We need to develop or standardize a paradigm or approach to using multiple frameworks within Exp. E.g., we historically had used YUI, but are moving to Twitter Bootstrap and jQuery. However in our move to Bootstrap under Twitter Bootstrap v2.3.x, that framework was given a major revision by its moving to v3.x. Therefore...we have three (3) distinctly different (theme) frameworks we use within Exp based on the theme itself. This approach works well so long as there is/was only ONE administrative framework (slingbar & chrome & configuration views) which until now had been YUI.

Since we are moving away from YUI as the primary framework, YET want to maintain (some?) backwards compatibility, we'll have to overcome some currently limitations. In a pure sense, we would NOT want to FORCE users into a new admin UI simply because of an Exponent upgrade (unless it is a major upgrade) In other words, you should be able to get bug fixes without having to re-train your site admins/editors.

Comments and changes to this ticket

  • dleffler

    dleffler April 9th, 2014 @ 12:02 AM

    Perhaps the best approach is to follow this hierarchy based on the theme's framework which includes styles, view templates, form controls, & smarty plugins:

    1. custom theme overrides (ALWAYS take precedence over system files)
    2. bootstrap 3 (new recommended styling/coding level v2.3.0+ restyles everything)
    3. bootstrap 2 w/ traditional/yui slingbar/chrome (added v2.2.0, but now bootstrap 2 is deprecated)
    4. jquery (not a framework, only used to override controls & plugins in a normally traditional/yui theme)
    5. traditional/yui (doesn't autoload any framework styles)

    The system would work its way through that chain starting at the current theme framework level and then working down the chain until the requested 'item' is located.

    With bootstrap 3 implemented, it will have a new bootstrap 3 styled slingbar/chrome, while the other theme frameworks would still use the old yui slingbar/chrome. This would also include a bootstrap 3 replacement for all yui controls/styles in the system such as tabs, etc... for the bootstrap 3 themes (eventually)

    At some point thereafter, we'd also want to add a NEWUI (constant/setting) option which could be added to any traditional theme thus giving it the new slingbar/chrome, and perhaps restyled controls, etc... without that theme requiring twitter bootstrap styling (bootstrap 3 themes would already automatically have all these features)

    Since bootstrap 2 is deprecated and doesn't play well with bootstrap 3, it will NEVER have a NEWUI option, but will continue to be supported for the near future. We also may want to deprecate the 'jquery' framework option since it hadn't been used up through v2.2.3.

    So, the hierarchy would become:

    1. custom theme overrides (ALWAYS take precedence over system files)
    2. bootstrap 3 (new recommended styling/coding level v2.3.0+)
    3. bootstrap 2 w/ traditional/yui slingbar/chrome (added v2.2.0, but now bootstrap 2 is deprecated)
    4. NEWUI (not a framework, but overrides the controls/plugins in a traditional theme)
      4a. jquery (if not deprecated by moving the existing jquery controls)
    5. traditional/yui (yui, 'awesome' buttons, etc...)

    With this approach, bootstrap 3 is equivalent to NEWUI, however NEWUI would only add certain features to an otherwise traditional theme (not replace the views)

    Form controls and smarty plugins are segregated by the folder they are stored in, with the traditional/yui versions in the base folder and the variants (if any) in the framework named folder (jquery, bootstrap, bootstrap3, newui).

    Template views are segregated within the same views folder by an additional variant suffix before the file type. e.g., if the traditional/yui view is 'showall.tpl' the bootstrap 3 variant would be 'showall.bootstrap3.tpl' (bootstrap, bootstrap3, newui)

  • dleffler

    dleffler May 2nd, 2014 @ 02:04 AM

    • State changed from “new” to “resolved”
    • Assigned user set to “dleffler”
    • Milestone set to 2.3.1

    This was implemented in v2.3.0

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Bug Tracker for Exponent CMS

Shared Ticket Bins

People watching this ticket