?
avatar dgt41
dgt41
4 Dec 2016

The issue

Alerts, tooltips, dropdowns, tabs, accordions and modals are tightly coupled to Bootstrap.
This is WRONG, we're back at Mootools days, but we can do better than that

Expected result

Switching to ANY other framework (given that HTML will be handled by installable layouts for each component, etc) should not require any changes to the scripts as well for #3rd PD.

Actual result

Switching to ANY other framework (given that HTML will be handled by installable layouts for each component, etc) requires changes to the scripts as well for #3rd PD.

PROPOSAL

Use bootstrap-init.js from #11922 and also define a simple abstraction that will free us from Bootstrap

// Only define User Interface if not defined
Joomla.ui = Joomla.ui || {
		/**
		 * UI frameworks SHOULD register the following:
		 *
		 * ALERTS
		 * alertClose              Type  Function
		 * onAlertClosed           Type  Function
		 *
		 * ACCORDION
		 * onAccordionShown        Type  Function
		 * onAccordionShow         Type  Function
		 * onAccordionHidden       Type  Function
		 * onAccordionHide         Type  Function
		 *
		 * DROPDOWN
		 * dropInit                Type  Function
		 * dropToggle              Type  Function
		 *
		 * MODAL
		 * onModalShown            Type  Function
		 * onModalShow             Type  Function
		 * modalShow               Type  Function
		 * modalClose              Type  Function
		 * modalToggle             Type  Function
		 * onModalHidden           Type  Function
		 * onModalHide             Type  Function
		 *
		 * TAB
		 * tabInit                 Type  Function
		 * onTabShow               Type  Function
		 * onTabShown              Type  Function
		 *
		 * *********************************************************
		 * ANY INTERACTION WITH THE UI SHOULD USE THE ABOVE API
		 * *********************************************************
		 */
	};

So to give a simple example, instead of the bootstrap specific:

$(".alert").alert('close'); // works only for Bootstrap 

We use a framework agnostic:

Joomla.ui.alertClose($(".alert")); // works with any framework

which is defined in bootstrap-init.js as:

alertClose(element) = return function(element) { element.alert('close')};

PS. The html/bootstrap.php needs to be deprecated in 3.x and use a html/ui.php

EDIT: Someone CAN STILL use directly the bootstrap methods/events (but that will defeat the aim of an API, but then again who's using correctly Joomla's API), I am not proposing to replace them...

Any thoughts on this?

avatar dgt41 dgt41 - open - 4 Dec 2016
avatar joomla-cms-bot joomla-cms-bot - change - 4 Dec 2016
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 4 Dec 2016
avatar ggppdk
ggppdk - comment - 4 Dec 2016

This besides making easier to support a different than boostrap framework,

will also help supporting different bootstrap versions too,
thus upgrading to later bootstrap versions will be less of a headache

avatar Bakual
Bakual - comment - 4 Dec 2016

Don't see that as something we should pursue because it will either be not complete (not every BS function will be abstracted) or it will not be documented as good as Bootstrap.

I don't see what you're trying to solve here. JHtml methods are overrideable and layouts are anyway. We just need to make sure the calls to Bootstrap functions are done in layouts. The most of it is already done like that, thus allowing to switch frameworks if someone wants to do that.

avatar dgt41
dgt41 - comment - 4 Dec 2016

not every BS function will be abstracted

Joomla doesn't use out of the box all bootstrap's components, but we could abstract all BS components...

JHtml methods are overrideable and layouts are anyway. We just need to make sure the calls to Bootstrap functions are done in layouts.

That's half of the story (server side) I'm talking about the other half (client side).
So for server side you get a well defined API, but for client side you say oh well, do it your way?
Also keep in mind that if for any reason BS breaks it's API Joomla needs to break it as well.
So obviously we see this from different perspectives but I think we can agree that a CMS that lacks a good API falls to toy category...

avatar Bakual
Bakual - comment - 4 Dec 2016

Sorry, I don't understand what you mean with client side vs server side. JS is executed always on the client, but we prepare the layouts (which include the JS calls) on the server. If you override the layouts, you can also change the JS that is loaded and called within that layout and thus you change the client side. So that distinction makes no sense to me.

avatar dgt41
dgt41 - comment - 4 Dec 2016

if you override the layouts, you can also change the JS that is loaded and called within that layout

@Bakual well that's the point of abstracting, you won't have to do that. One less thing to care. Also a well defined JS API will eliminate all short of incompatibilities between 3rd PD components, as all the events and methods will be the same, always!

avatar Bakual
Bakual - comment - 4 Dec 2016

You will have to override the layouts anyway because changing the framework isn't just about the JS part. It has implications on how the HTML is built and what classes are being used. The JS is usually the least concern actually and is already possible to override (remember that JHtml methods are overrideable).

Also a well defined JS API will eliminate all short of incompatibilities between 3rd PD components, as all the events and methods will be the same, always!

Yeah, "well defined". Lets add "maintained" and "documentated" to the list. And we have three issues to solve that will not be solved.

avatar dgt41
dgt41 - comment - 4 Dec 2016

The JS is usually the least concern actually and is already possible to override

Exactly Javascript is not a concern for Joomla

So let me recap here: Joomla already tried to do some short of javascript API:
https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/behavior.php#L414-L416
and
https://github.com/joomla/joomla-cms/blob/staging/plugins/editors-xtd/article/article.php#L51-L61
which is obviously a joke.
For the second part jSelectArticle() I proposed #12561 which solves all the shortcomings of a global function and eliminate the 1 editor per page limitation.

For the first part jModalClose I do propose the same thing, but also covering all the UI elements (methods and events) that Joomla is using.

Yeah, "well defined". Lets add "maintained" and "documentated" to the list.

Well, then let's keep it broken forever...

avatar Bakual
Bakual - comment - 4 Dec 2016

Well, then let's keep it broken forever...

Nah, but don't create another layer on top which is unuseable and broken (because it is undocumented and unmaintained).
If you find an existing, maintained and documented solution which could applied here, then lets do it. But inventing our own API is bound to fail imho.
Maybe others see that different, but imho this projects lacks usually a lot in the (developer) documentation area and also there aren't a lot of people who can maintain the JS part.

That is the big plus we got by adopting Bootstrap. We have a maintainaed and very good documented framework / API. It has its cost, yes, but from my point of view the advantages overweigh the costs by far.

avatar dgt41
dgt41 - comment - 4 Dec 2016

That is the big plus we got by adopting Bootstrap. We have a maintainaed and very good documented framework / API

That is an unnecessary coupling, that turns front end devs away from joomla. Bootstrap is not ideal for each project...

Nah, but don't create another layer on top which is unuseable and broken (because it is undocumented and unmaintained).

Well we already have some short of js API which is undocumented and unmaintained

But inventing our own API is bound to fail imho.

Well, is https://github.com/joomla/joomla-cms/commits/staging/libraries/cms/less/less.php unmaintained or undocumented?
Check the history, code only changed when moved to a new version other than that never touched. An abstraction (if done correctly in the first place) will not need any maintenance, plus we keep B/C, if they change something radically...

avatar brianteeman brianteeman - change - 4 Dec 2016
Status New Discussion
avatar mbabker
mbabker - comment - 4 Dec 2016

JLess isn't an abstraction layer, it's an extension of a broken as all can be PHP LESS compiler. Same can be said for JMail, which actually breaks the documented API of the PHPMailer class its extending.

Joomla sucks at adding abstraction layers, documenting things, and not forking third party libraries implementing hacks (I'm still waiting to see where the event name changes for Bootstrap's hide events are documented).

In an ideal world, everything would be abstracted and no third party's documentation would really be usable in Joomla. HTML elements would be wrapped in a Joomla wrapper (hello j-col-sm-6), JavaScript would go through Joomla.ui.alert(), and everything would be well documented and easy to understand. Now speaking realistically, as much as we like to try, we all suck hard at documenting anything about Joomla and frankly the only way to work in the Joomla environment is to reverse engineer everything. I had a project where I needed to do something in JavaScript on Bootstrap's collapse plugin's hide event, it didn't work, and I had to reverse engineer the code to find out that Joomla emits a "hideme" event instead of hide because of MooTools issues. AND NEVER DOCUMENTED THE HACK.

That single example is why I have little faith in abstraction layers with Joomla. They're going to make things more difficult for little gain, they aren't going to be documented, and the people that understand how they're implemented are going to move on to other projects leaving the masochists still contributing here to figure out what to do with it on their own.

avatar dgt41
dgt41 - comment - 4 Dec 2016

and the people that understand how they're implemented are going to move on to other projects

So what makes you think that these won't go away if J4 doesn't really deliver anything fancy (code wise)?

avatar mbabker
mbabker - comment - 4 Dec 2016

Just pointing out that we have issues with personnel turnover. Often someone will get a major feature implemented then stop contributing to Joomla leaving others to deal with the issues of those changes. The team that got SQL Server support added, the individual who did a large bulk of the work for PostgreSQL support, the first "real" JUX team...

avatar dgt41
dgt41 - comment - 4 Dec 2016

Honestly that's the deeper problem with this project. People spend money for freaking trips, instead of paying 4-5 people to maintain and improve the code. After all we're all humans and life happens...
But I do believe deeply, that such improvements (if done right) will bring people back not kicking them away

avatar mbabker
mbabker - comment - 4 Dec 2016

It'll never happen again. Look how many issues came with when Andrew and Louis were getting paid...

avatar Bucklash
Bucklash - comment - 5 Dec 2016

Hi folks

Are there any cms's out there that you think have done it right?

avatar dgt41 dgt41 - change - 6 Dec 2016
The description was changed
Labels Removed: ?
avatar dgt41 dgt41 - edited - 6 Dec 2016
avatar dgt41
dgt41 - comment - 6 Dec 2016

@Bucklash not that I know of...

avatar Bucklash
Bucklash - comment - 7 Dec 2016

@dgt41 It's interesting to me that all three of you guys know your stuff, like many others, and that something like this is a sticking point. Good discussion ?

avatar photodude
photodude - comment - 10 Dec 2016

@Bakual (this is probably a bit off topic)

JS is executed always on the client,

That might have once been mostly true, but not any longer. Node.js, GromJS and MarkLogic to name a few are Server Side JS (SSJS).... while many (most) other JS libraries/frameworks are only client side.

avatar Bakual
Bakual - comment - 10 Dec 2016

@photodude I'm aware of that. But we're talking about Joomla here, and there is no way we are going to run JS on a shared server side.

avatar Fedik
Fedik - comment - 11 Dec 2016

Currently I am not sure that we need something like this for all that fancy stuff. It actually just a styling.
Joomla should provide an "easy editable" layouts for them.

Couple things about JavaScript in CMS, for what we use JavaScript:

  • the code for CMS logic, eg: submit form, check all (in table), renderMessages, language stuff etc... without them will work nothing.
  • the styling stuff: tooltips, alerts, tabs, etc... without them all can looks ugly, but continue to work.

We should care that the Logic code work without any frameworks, as good as possible.
And all that fancy styling stuff should come form the template, and only from the template.

Complicated things comes when we need some advanced stuff for the CMS logic, like: calendar, select Article (User etc) in modal, tags field, subform (multiple) etc.
From my point of view, these things can be separated libraries, and should not be related to any framework (as modal currently). jQuery dependency is fine for them, but not Bootstrap, Foundation etc.

avatar dgt41
dgt41 - comment - 11 Dec 2016

@Fedik I feel that I should be blamed for moving most modals to bootstrap from Mootools.
This might sounded like a nice solution to get away from Mootools but, unfortunately, it created another dependency to Bootstrap and Jquery.
For joomla 4, which won't have support for bad browsers, simple vanilla scripts SHOULD be used from joomla for it's core needs. Basically Joomla SHOULD come as framework free as possible (modal, tooltips, tabs, accordion and alert). Then it would be a nice, clean base for any css framework to be used in the templates.
Unfortunately PLT is convinced that Bootstrap dependency is not something bad (actually there are people that think it's a good thing ?) so there is no will to change that...

avatar Bakual
Bakual - comment - 11 Dec 2016

Unfortunately PLT is convinced that Bootstrap dependency is not something bad (actually there are people that think it's a good thing ?)

Kepp in mind that Michael and me are not in PLT anymore. From PLT there isn't any response in this thread so far. But maybe you got feedback from them elsewhere.

avatar Fedik
Fedik - comment - 11 Dec 2016

I feel that I should be blamed

Sorry, I do not blame you ?
You did all what you can, and there was no one else around to do it ?

avatar mbabker
mbabker - comment - 11 Dec 2016

You want a JavaScript abstraction layer in front of some things, because from the JavaScript API alone there isn't a clean way to override things the same way you can from the PHP API. In some cases this makes sense, in other cases, I think it's just overhead.

Others want Joomla to make an abstraction layer over the markup (so some frontend person can translate j-col-sm-4 into whatever they need). We might as well go back to the 1.5 and 2.5 days where the templates just wrote whatever markup they wanted and you had to reverse engineer everything to make usable layouts. At least from a markup perspective, folks could build layouts using a common structure and them work more often than not with more than the core templates.

Either way though if nobody is going to document and maintain this abstraction layer, we're just making Joomla harder to use for everyone for the benefit of a small group. That "hideme" change is still undocumented, the entire JavaScript API is undocumented, and the 2.5 templates have no documentation on their structures. Just sayin'.

avatar dgt41
dgt41 - comment - 11 Dec 2016

@Fedik I 'll happily take the blame (even if people don't want to blame publicly). The idea to replace mootools dependency with jQuery+Bootstrap was (and still remains) stupid. We should never have followed that route.

@Bakual I wasn't pointing to you or Micheal here, although I do appreciate your view (even if it's not in line with mine)

@mbabker so one thing is accepting the unneeded jquery+bootstrap dependency and try to easy the pain with some abstraction like the one I propose here. Another thing is figure out what is core and deliver that as vanilla js scripts (e.g. replace SqueezeBox with some vanilla script). The benefit is that these UI will work no matter what's the preferred css (js) framework. Reducing dependencies and deliver up to date UI scripts will have a positive impact for frontenders.

To wrap this up: this proposal isn't the only way out from the bootstrap mess...

avatar mbabker
mbabker - comment - 11 Dec 2016

To be clear, I have no issue trying to improve things in general. I just worry about going "too far", introducing steps that actually makes it harder to work with Joomla. Having framework-less dependencies in and of itself isn't a bad thing, but it needs to be well thought out in the end and not just changing the underlying libraries for the sake of change.

And ultimately, if we're adding an abstraction/mapping layer, DOCUMENT THE DAMN THING! There is no excuse today (or in 2012 for that matter) to be adding stuff to our UI layer and not documenting how to use it or noting any differences in behavior as it relates to the upstream package (see Bootstrap and Chosen).

avatar N6REJ
N6REJ - comment - 11 Dec 2016

What about moving the bootstrap reliance to a plugin. What I mean is
build it so that it uses bootstrap ( like now ) but where bootstrap is a
regular plugin. If someone wants to not use bootstrap they could turn
the plugin off and turn on another.
Documentation has always been the worst aspect of J! George was working
his tush off to solve this but alas it never got completed. the
repeatable form field is a great example. There is NO clear docs on how
to use it. And its probably one of the most complicated things we
have. I haven't looked but i bet there is nothing on its replacement
either.
Bear

On 11-Dec-16 14:47, Michael Babker wrote:

To be clear, I have no issue trying to improve things in general. I
just worry about going "too far", introducing steps that actually
makes it harder to work with Joomla. Having framework-less
dependencies in and of itself isn't a bad thing, but it needs to be
well thought out in the end and not just changing the underlying
libraries for the sake of change.

And ultimately, if we're adding an abstraction/mapping layer, DOCUMENT
THE DAMN THING! There is no excuse today (or in 2012 for that matter)
to be adding stuff to our UI layer and not documenting how to use it
or noting any differences in behavior as it relates to the upstream
package (see Bootstrap and Chosen).


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#13080 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABw66W0LWTpLUza7ZoI5S68OwM7KVwoxks5rHGFbgaJpZM4LDjzg.

avatar mbabker
mbabker - comment - 11 Dec 2016

Bad idea. The issue isn't the markup which as of 3.7 should be 100% overridable. It's the JavaScript API, which you can't override the same way as layouts.

avatar nibra nibra - change - 16 Mar 2017
Category Feature Request JavaScript
avatar rdeutz rdeutz - change - 30 Jun 2017
Status Discussion Closed
Closed_Date 0000-00-00 00:00:00 2017-06-30 20:26:04
Closed_By rdeutz
avatar rdeutz rdeutz - close - 30 Jun 2017
avatar rdeutz
rdeutz - comment - 30 Jun 2017

Seems to me the discussion is finished and the idea didn't get so much support. Closing this for now, can be re-opened if needed.

Add a Comment

Login with GitHub to post a comment