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
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.
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.
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?
Labels |
Added:
?
|
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.
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...
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.
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!
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.
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...
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.
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...
Status | New | ⇒ | Discussion |
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.
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)?
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...
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
It'll never happen again. Look how many issues came with when Andrew and Louis were getting paid...
Hi folks
Are there any cms's out there that you think have done it right?
Labels |
Removed:
?
|
@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.
@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.
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:
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.
@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
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.
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
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'.
@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...
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).
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.
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.
Category | ⇒ | Feature Request JavaScript |
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-06-30 20:26:04 |
Closed_By | ⇒ | rdeutz |
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.
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