Never ending story: Jquery vs mootools
Sybrek
For quite some time, i read a lot stuff about "best way to integrate jquery and prevent the problem of different versions"
and i seriously don't understand the discussion. It shouldn't be difficult to add a sort of "version" to the scripts array we use to avoid duplicated entries.
I think the main question should be if we want to use jquery or mootools in core, which also will show our prefernces.
Mootools is a great (and real) JS framework, but since most of the extensions are using jquery i thought that we should see that
as a wake-up call. The community wants to use jquery.
So is there any concern about the (optional) use of jquery instead of mootools ?
Niels Braczek
> So is there any concern about the (optional) use of jquery instead of
> mootools ?
after having written a fat client application in JavaScript with Joomla!
as backend, I really don't know, what the advantage of introducing
jQuery should be. I've never seen solutions based on jQuery that could
not be made with MooTools, but I have vice versa.
The approach should not be to support jQuery inclusion, but to provide a
set of widgets, like we do with modal, captions and tabs, which are
unobtrusive and easy to use.
Just my 2 cents.
Regards,
Niels
--
| http://barcamp-wk.de · 1. Barcamp Westküste 2./3. März 2012 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Andrew Eddie
any javascript at all. It's really something the application should
take responsibility for. In that way, it's no big deal for one app to
use Mootools, another jQuery and yet another YUI. I'm leaning more
and more to a state where maybe it's not our (the platform's) problem
to solve.
Just throwing it out there…
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.7 developers
Sybrek
Paladin
included, I think it's clear the library with the best case for
inclusion is jQuery. Currently 99% (possibly dropping to 90% over the
next few years) of the use case for javascript is DOM manipulation,
something jQuery excels at, and jQuery is typically the first js lib
anybody picks up and starts to use.
Niels, the question isn't whether something can't or can't be done in
MooTools. I've written in both and I think what you can do in one can
pretty much be done in another. The question is *has* it been done?
IOW, is it better to spend time creating something in MT that already
exists in jQ? Yes, I can empathize with your rich client experience.
But that's what? 0.1% of the uses Joomla sees? Having to add MT to a
js-less framework would have increased your workload by 5%, maybe,
probably less. But just as many, even more, would drop MT from the
framework and build their rich client in jQuery (take a look at what
can be done with SproutCore, for example; SC requires jQuery).
The reason the jQ choice seems so obvious to me is that most every
widget or validation you want to use already exists there, all you
need is to stitch it in. That's why so many designers won't consider
using anything else.
I have a fond spot in my heart for both MT and Scriptaculous, but more
and more the teams I work with insist on jQuery. At this point, the
question needs to be asked and answered: are unique javascripts part
of Joomla's "core competency," part of what can differentiate it from
the rest of the market? If the answer to that comes back as "Yes",
then the right path is to stick with MooTools and start developing all
the support scripts sites will need. OTOH, if the answer (as I
suspect) is "No," then it's time to bite the bullet and either remove
javascript from the framework completely, or make the switch to the
800-lb gorilla that is jQuery.
For example, the Rails framework grew up with Prototype and
Scriptaculous, but with version 3 they went library agnostic, and with
version 3.1 switched to jQuery being shipped as part of the framework.
As for JForm, Sybrek, don't get me started. I've been swearing at the
unreasonable rigidity of JForm's 1.7 incarnation for weeks, now.
To return to the jslib-agnostic idea:
I'm of two minds on it. For one, I like the idea of leaving the js
choice up to the developer. The choice of which js library to use
isn't made in a vacuum; it's made according to the requirements of the
application and the expertise of the application developer(s), neither
of which is known at Platform development time, so any choice made
there is bound to be suboptimal.
But more and more we're living in an AJAX world, and the ability to
function in it requires javascript, and some core functions could
productively use that capability. Since Sybrek brought it up I suppose
we can use JForm as an example of that:
If the idea of using js to do form validations, etc., in the client is
kept in JForm (something I'm not convinced of, but can see an argument
for, at least) then make that an optional selection, the developer
installs the option while starting to work on the application. An
additional advantage of that approach is that one library can easily
be dropped in favor of a new one if for some reason the initial
selection is found wanting as development progresses (or in future
versions of the app, as requirements change). The mechanism for this
would need to be developed, of course, making more work for everyone
concerned.
There are enough minor differences in how AJAX-y things are handled
between libraries, that custom php code is necessary, I think, to pull
that off, hence the optional bit.
On Feb 7, 1:11 am, Andrew Eddie <mambob...@gmail.com> wrote:
> Another way to look at it is maybe the Joomla Platform should not have
> any javascript at all. It's really something the application should
> take responsibility for. In that way, it's no big deal for one app to
> use Mootools, another jQuery and yet another YUI. I'm leaning more
> and more to a state where maybe it's not our (the platform's) problem
> to solve.
>
> Just throwing it out there…
>
> Regards,
Gary Glass
I think mootools is great and it's the JS lib I prefer, but it seems that
jQuery has really won the war. J!3.0 seems the opportune time to bite the
bullet.
See: http://w3techs.com/technologies/overview/javascript_library/all
jQuery has an 85% share. Mootools is a very distant 2nd place with just 10%.
______________________________
Gary Glass
http://ShutterGlass.com
http://OnlyBegotten.com
Rouven Weßling
I'd much rather discuss technical differences to decide where to go.
Also for those calling to drop MooTools for jQuery, this would involve rewriting all scripts. I wonder who's gonna do that? I offered numerous times to help write a jQuery replacement for JHtmlBehavior that is as compatible as possible to the MooTools one (at least from the PHP side of things). I'd just need help with writing the jQuery scripts since I don't know the library that well and frankly don't wanna do it all by myself. So far no one has agreed - I wonder where all the competent jQuery devs are gonna appear from magically.
Best regards
Rouven
Mark Dexter
While it is possible that the PLT will change its mind at some point, I am not aware of any movement in this direction. That is why the focus was to allow JQuery and Mootools to work together (which I believe is accomplished).
So, unless (a) someone can articulate a compelling reason to change from Mootools to JQuery and (b) someone writes the behaviors in JQuery, I don't see this changing. My .02. Mark
RedEye
which uses jquery and maybe can be provided by a system plugin so that
users can choose what they want to use.
Rouven I would give you a helping hand on this, but I`m also not very
good with the jquery stuff, at the moment I only replaced caption,
keepalive and noframes, so only the little ones^^, tooltip is on todo
as the next one.
Andrew Eddie
all have to remember that the Platform can and will want to cater for
more than just the CMS, and just because the Platform is doing
something different, doesn't mean the CMS has to follow. However,
anyone that thinks that we can just chuck Mootools out and put in
jQuery and all our problems go away is sadly mistaken.
For the CMS, I don't see any reason why jQuery can't be added as a
disabled plugin (that extension developer can then turn on at install
time). Do that and I think a lot of the moaning goes away. It's only
a pull request aware and I don't see why it couldn't go into a 2.5
point release.
The Platform, however, is a slightly different matter, but if we go
down the road of "adding" another JS library, whatever that is (and I
don't think we can escape the popularity of jQuery, but neither can we
escape the fact that jQuery is a subset of the features many other
richer frameworks offer, and jQuery will eventually "lose" it's
popularity contest to something else one day), I think we need to sit
back and reinvent our JS anyway and make sure we are using composition
where it count so that we can swap out the libraries (usually for
fancy display purposes). That probably means going back to
fundamentals for the structural wrappers or making so that we can
write client side applications in Mootools and you can swap out your
"special effects" engine with jQuery, Mootools FX or similar (you
aren't going to build a client side MVC in jQuery, but you would do it
in Mootools or even, and maybe better, from first principles).
Whether or not you like JForm, I contend that it was a huge step in
the right direction when it was implemented (remembering it's changed
little since the end of 2009 when it went into the core). But there
is no denying JForm will now need further consideration because we
need to have more flexibility dealing with the client and server sides
aspects separately. I would say we need to working on separating the
form as a logical construct on the server, something that displays in
the client and then the responsive aspects which include, but are not
limited to, client side validation (the logic for which may or may not
live on the client). JForm itself is a little off topic, but it's
probably a good use case for trying to work out how we deal with the
JS issue in the Platform.
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 2.5 developers
Elin Waring
Ofer Cohen
Elin,
Is there any tracker for this?
Ofer Cohen Joomlics Anonymous Group
Elin Waring
Azrul Rahim
But for the CMS, jquery is pretty much as must. If we ship the CMS with jquery plugin (disabled by default maybe), it will do a lot of good. Absolutely nothing bad will come out of it. The only possible outcome is happy users and happy developers!
Viktor Iwan
I think there's lot of issue that can happen on early days of most
joomla developers that related to mootols-jquery conflict...
- using $ instead of jQuery (or something else)
- forget to use .noConflict()
- 3rd party extension load jquery framework multiple time (and
sometime with many different version as well) even many 3rd party
template framework (or club) give option to load jQuery.
Can you see how much mess by having jQuery not in the core of joomla ?
if you talk as experience joomla developer, you can easily think
'mootools vs jquery' thing is not really a big deal..
but if you see this matter with passion or spirit : "Joomla for
everyone" , this really does matter.
I found many 3rd party extension is not experience joomla developer as
well, many time i have to tweak the code. Fortunately i understand
enough to use jQuery and Mootools altogether.
But many joomla user is not like us, there are small companies,
blogger, internet marketer that use joomla as is .. and they really
depend on 3rd party extension.
i'm still hoping joomla will have jquery on its core or hopefully we
can have option wheter to use jquery or mootols as core js
framework... it would be a great feature..
just my 2 cents
On Feb 18, 8:03 am, Azrul Rahim <write...@azrul.com> wrote:
> I agree with Andrew that the on the platform level, this need more thought and perhaps js-agnostic is the best option for now.
>
Niels Braczek
> i'm still hoping joomla will have jquery on its core or hopefully we
> can have option wheter to use jquery or mootols as core js
> framework... it would be a great feature..
I really hope not. As an extension developer, I'd have to provide
alternative JS code for MooTools and jQuery (and Dojo and Prototype and
...) to make it able to run together with other components on the same
installation. I would have to do so, because the sitebuilder would
decide, which framework to use, and that decision would depend on the
poorest (least flexible) extension used. This will end with making
sitebuilding a horror.
Let developers rely on Joomla supporting MooTools. If some developer
decide not to follow that, he has the problem to integrate his
additional library. And I think, that's absolute ok.
Regards,
Niels
--
| http://barcamp-wk.de · 1. Barcamp Westküste 30./31. März 2012 |
Miguel Tuyaré
This is a good article that justifies the use of Mootools, I'm no
expert in the area, but ....
http://jqueryvsmootools.com/index.html
in Github:
https://github.com/anutron/jquery-vs-mootools
Paladin
preference." You'll find that written all over the document (check for
example, the section on chaining). He's a MooTools framework
developer, so while he tried very hard to be objective, it can't be
seen as a surprise he personally prefers the MT way of doing things,
and finds it easier to understand. I daresay Andrew finds it far
easier to understand the process of writing a Joomla component than,
say, a Zend developer who simply takes a look at the Joomla API.
For myself, having worked extensively in both jQuery and MooTools, I
find that if you're going to use AJAX to make modifications to the
existing DOM tree, rather than going back to fetch complete pages, jQ
is better than MT, because jQ has a way to link event handlers to DOM
elements that don't exist at the moment, while with MT you need to
reattach the event handlers if you replace an element via AJAX (at
least, that was what I had to do, if MT can do it, I couldn't see
how).
It's also easier to use jQ to validate forms, because it has extensive
form validation plugins that work automagically with forms (or would
be easy, if JForm weren't so stubborn about refusing to let you use
perfectly valid form field attributes -- they work perfectly with non-
JForm forms).
Bottom line, MooTools works quite well, and so does jQuery. Most
things to do with the DOM jQ does more cleanly and easily than MT, but
MT works better in situations where you want to use classical
programming techniques. This attracts some developers, and repels most
designers, vice versa for jQuery. So you pays your money and takes
your choice.
That's the reason I favored including neither. It's a choice based
more on personal taste than any objective technical merit, and choices
like that should be left to the site builder. When you mandate one
over the other, you add a "tax" on everyone whose taste run
differently.
On Feb 26, 7:11 pm, Miguel Tuyaré <migueltuy...@gmail.com> wrote:
> Hi,
> This is a good article that justifies the use of Mootools, I'm no
Niels Braczek
> For myself, having worked extensively in both jQuery and MooTools, I
> find that if you're going to use AJAX to make modifications to the
> existing DOM tree, rather than going back to fetch complete pages, jQ
> is better than MT, because jQ has a way to link event handlers to DOM
> elements that don't exist at the moment, while with MT you need to
> reattach the event handlers if you replace an element via AJAX (at
> least, that was what I had to do, if MT can do it, I couldn't see
> how).
MooTools has Event Delegation for that purpose.
> It's also easier to use jQ to validate forms, because it has extensive
> form validation plugins that work automagically with forms
Client-side validation has to be provided from JForm (its renderer),
because (only) there the requirements for a specific field are known. It
can't do that, if the chosen JS libray is unknown. I'm pretty sure, that
there never will be support for all possible libraries in the core.
> That's the reason I favored including neither. It's a choice based
> more on personal taste than any objective technical merit, and choices
> like that should be left to the site builder. When you mandate one
> over the other, you add a "tax" on everyone whose taste run
> differently.
In consequence, no extension can support any JS library. The current
situation is: "If you need JS enhancement, use MooTools. If you want to
use another library. you're responsible for it." This is IMO the right
approach, so no change is needed from what we have now.
Rouven Weßling
On 27.02.2012, at 18:58, Paladin wrote:
> For myself, having worked extensively in both jQuery and MooTools, I
> find that if you're going to use AJAX to make modifications to the
> existing DOM tree, rather than going back to fetch complete pages, jQ
> is better than MT, because jQ has a way to link event handlers to DOM
> elements that don't exist at the moment, while with MT you need to
> reattach the event handlers if you replace an element via AJAX (at
> least, that was what I had to do, if MT can do it, I couldn't see
> how).
Thank you for bringing this up. I think this is the first time someone actually tried to bring this discussion to be about technical merits instead of preference or popularity. As Niels pointed out you probably mean event delegation which is available in MooTools as well (core since 1.4, earlier it was in more which is why you might have missed it)
> It's also easier to use jQ to validate forms, because it has extensive
> form validation plugins that work automagically with forms (or would
> be easy, if JForm weren't so stubborn about refusing to let you use
> perfectly valid form field attributes -- they work perfectly with non-
> JForm forms).
I never used the MooTools form validation utility and I couldn't find any documentation about form validation in jQuery (are you sure its not a plug-in?) but neither really matters to us since we roll our own form validator that is (more or less) integrated with JForm. I'd actually like to rip that one out and replace it with a validator based on the new HTML5 form features but since we're still supporting IE7-9 (which have no support whatsoever for the new form features) we'd need fallback code for everything - a lot of work.
> Bottom line, MooTools works quite well, and so does jQuery. Most
> things to do with the DOM jQ does more cleanly and easily than MT, but
> MT works better in situations where you want to use classical
> programming techniques. This attracts some developers, and repels most
> designers, vice versa for jQuery. So you pays your money and takes
> your choice.
jQuery certainly has the better documentation, more tutorials and right now the greater mindshare. But so has Wordpress. I think that MooTools has the better system because it still "feels like JavaScript" but allows me to use classes. Then again I'm obviously not a designer.
> That's the reason I favored including neither. It's a choice based
> more on personal taste than any objective technical merit, and choices
> like that should be left to the site builder. When you mandate one
> over the other, you add a "tax" on everyone whose taste run
> differently.
That's not really possible anymore today. If we included neither we'd probably have our own (much worse) custom library sooner or later. Both provide a level of abstraction and compatibility with older browsers (*cough* IE *cough*) that's very hard to do with vanilla JavaScript. Of course we could just stop using JS at all in Joomla, but do you really want that?
Also what do you expect from extension developers? Write JS for both frameworks? Use no JS?
What we should strive to is make it possible to run the frontend with other framework. As far as I know that's why the behaviors system has been developed, it abstracts (some) of the JS away from implementations and allows extension to require a certain behavior (keepalive, modals) without relying on what JS lies behind it. Unfortunately I know of no one from the community who has run with the idea and created a jQuery behavior.
Best regards
Rouven
Paladin
On Feb 27, 12:17 pm, Niels Braczek <nbrac...@bsds.de> wrote:
> Am 27.02.2012 18:58, schrieb Paladin:
>
> > For myself, having worked extensively in both jQuery and MooTools, I
> > find that if you're going to use AJAX to make modifications to the
> > existing DOM tree, rather than going back to fetch complete pages, jQ
> > is better than MT, because jQ has a way to link event handlers to DOM
> > elements that don't exist at the moment, while with MT you need to
> > reattach the event handlers if you replace an element via AJAX (at
> > least, that was what I had to do, if MT can do it, I couldn't see
> > how).
>
> MooTools has Event Delegation for that purpose.
until about a year after I was looking for it, so that's probably why
I didn't find it.
>
> > It's also easier to use jQ to validate forms, because it has extensive
> > form validation plugins that work automagically with forms
>
> Client-side validation has to be provided from JForm (its renderer),
> because (only) there the requirements for a specific field are known. It
> can't do that, if the chosen JS libray is unknown. I'm pretty sure, that
> there never will be support for all possible libraries in the core.
would let me create and output the attributes valid for that
particular field, *any* js library could validate the fields, without
interference or assistance from JForm, et al. In fact, in many cases
today the browser's built-in field validation logic would work, and
for them I wouldn't need javascript at all. But since it blocks me
from using all but a select portion of the valid field attributes, it
not only doesn't know how to trigger the form validation in other
libraries, it actively *prevents* me from using it. In this case in
particular, it can't be said that joomla allows you to use whatever
library you want to use.
(And yes, Rouven, I said the jQ form validations were plug-ins. There
are several, you can choose which one you want to use based on your
needs and preferences, but they all work well. Again, I think this is
a choice best left to the site builder, because they know their
particular use case and audience better than anyone else does.)
> The current
> situation is: "If you need JS enhancement, use MooTools. If you want to
> use another library. you're responsible for it."
form validation so you'll have to load all of MooTools as well, even
though you're not going to use it for any other purpose." And even "If
you actually want to take advantage of the capabilities built into
some of your visitor's browsers, we're not going to let you."
Niels Braczek
> If JForm and the assorted field classes
> would let me create and output the attributes valid for that
> particular field, *any* js library could validate the fields, without
> interference or assistance from JForm, et al.
JForm (+ field classes) in conjunction with the (XHTML, HTML5, PDF, ...)
renderer is responsible for (triggers for) validation, server-side and
client-side. If it doesn't do that right, its a bug or a missing feature
and ought to be corrected.
> In fact, in many cases
> today the browser's built-in field validation logic would work, and
> for them I wouldn't need javascript at all. But since it blocks me
> from using all but a select portion of the valid field attributes, it
> not only doesn't know how to trigger the form validation in other
> libraries, it actively *prevents* me from using it.
You won't solve this by including jQuery into the core.
Amy Stephen
I believe it's a little more clear today that flexibility is best achieved by keeping the JS/CSS with the template and making certain the HTML markup is simple and standard.
With that approach, one simply has to change a module class suffix to switch between Twitter Bootstrap for their tabs -- http://foundation.zurb.com/ and a Mootools option. http://net.tutsplus.com/tutorials/javascript-ajax/sexy-animated-tabs-using-mootools/
IMO, the inflexibility today came from combining those elements unnecessarily into the JHTML element, for example with the sliders - https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/html/html/sliders.php#L62
So, in response to your question if the core should use JS, or not, the best approach, IMO, is to create a javascript-agnostic core, fully functional, and then leave it to the frontend developers to decide how to craft the presentation layer shared in the core distribution. That should also make it very easy to swap out by users.
I personally believe the whole "which JS framework is better" debate is divisive and counterproductive. We all know that there is no authoritative answer to that question, nor is there any way that the Joomla project can force all people to only use a specific choice with the CMS.
Whether we like it or not, learning to work around the technical conflicts that result from the amazing choices available today is simply part of what an open source project must do to be successful. IMO, it will be important to be careful in the future with how the JS is used to make certain not to tie the presentation layer unnecessarily to the view and layout HTML.
My 2 cents.
Paladin
On Feb 28, 11:39 am, Niels Braczek <nbrac...@bsds.de> wrote:
>
> You won't solve this by including jQuery into the core.
to do that. I was the guy who said "no js framework", remember?
Matt Thomas
Best,
Matt Thomas
Twitter: @betweenbrain
Niels Braczek
"No JS framework" wouldn't solve your issue as well. Your issue is with
how JForm works, not the JS library.
CirTap
> I personally believe the whole "which JS framework is better" debate is
> divisive and counterproductive.
... and more often than not has the charme of a religous debate where
each party tries hard to evangelize their beliefs and nothing but beliefs.
And 3 times KOTAU to Sam who happens to be the only other person
presenting us a neutral POV.
Keep on going, folks.
It's fun and entertaining to see this again going nowhere...
CirTap
CirTap
>>>
>>> You won't solve this by including jQuery into the core.
>>
>> Perfectly correct, which is one reason why my stated preference wasn't
>> to do that. I was the guy who said "no js framework", remember?
>
> "No JS framework" wouldn't solve your issue as well. Your issue is with
> how JForm works, not the JS library.
I don't think it's *the* issue, but just *one* that sticks out.
Like JDocument prevents me from adding useful attributes to get more
control over any external JS file if I rely on the "official" API to add
a script.
And yes, I do have a patch to solve this - for my needs -, but I'm also
utterly reluctant to go through the current process called "pull
request"... yet.
CirTap
Paladin
> renderer is responsible for (triggers for) validation, server-side and
> client-side. If it doesn't do that right, its a bug or a missing feature
> and ought to be corrected.
sure. There is no html5 renderer for form fields. They only render as
xhtml, and the attributes they allow are hard-coded in the PHP (ex:
text.php::getInput()).
Rouven Weßling
You're not understanding me. If JForm and the assorted field classes
would let me create and output the attributes valid for that
particular field, *any* js library could validate the fields, without
interference or assistance from JForm, et al. In fact, in many cases
today the browser's built-in field validation logic would work, and
for them I wouldn't need javascript at all. But since it blocks me
from using all but a select portion of the valid field attributes, it
not only doesn't know how to trigger the form validation in other
libraries, it actively *prevents* me from using it. In this case in
particular, it can't be said that joomla allows you to use whatever
library you want to use.
(And yes, Rouven, I said the jQ form validations were plug-ins. There
are several, you can choose which one you want to use based on your
needs and preferences, but they all work well. Again, I think this is
a choice best left to the site builder, because they know their
particular use case and audience better than anyone else does.)
I believe it's a little more clear today that flexibility is best achieved by keeping the JS/CSS with the template and making certain the HTML markup is simple and standard.
With that approach, one simply has to change a module class suffix to switch between Twitter Bootstrap for their tabs --http://foundation.zurb.com/ and a Mootools option. http://net.tutsplus.com/tutorials/javascript-ajax/sexy-animated-tabs-using-mootools/
Like JDocument prevents me from adding useful attributes to get more
control over any external JS file if I rely on the "official" API to add
a script.
And yes, I do have a patch to solve this - for my needs -, but I'm also
utterly reluctant to go through the current process called "pull
request"... yet.
Sorry for the delay, I wanted to go back and double-check, just to be
sure. There is no html5 renderer for form fields. They only render as
xhtml, and the attributes they allow are hard-coded in the PHP (ex:
text.php::getInput()).
CirTap
> behaviors for another framework.
maybe because of debates like this? ;)
>> Like JDocument prevents me from adding useful attributes to get more
>> control over any external JS file if I rely on the "official" API to add
>> a script.
>
> What attributes are you missing?
wrong question.
Why was it limited to async and defer in the first place?
Any HTML standard since 1996 allows for more.
Same for <link> just slightly different, and "custom" just ain't the
right way, imho.
However, that's all up for a different discussion -- if ever.
>> And yes, I do have a patch to solve this - for my needs -, but I'm also
>> utterly reluctant to go through the current process called "pull
>> request"... yet.
>
>
> Pull requests are now very common in open source development but if there's
> a way you think the process can be improved speak out.
There's nothing wrong with pull requests per se. I do push, pull, and
commit all over the place, and for the most part it can even be fun.
I wrote "yet" and that means "not now" -- nor in the very near future, fwiw.
CirTap
Andy Nagai
is not tied to a specific version of mootools, right? This was the
only reason why we used jquery in !J 1.5.11. It had some features that
made manipulations alot easier then mootools 1.1. This was just for in
house development.
Jonathan Seni
Jonathan Seni.
There are 10 kinds of people in this world,
----------------------------------------------------
SimplyMepis, SuSE 9.2, openSuSE 10.2 /10.3/11.0/11.1/11.2 /11.3/11.4(x86-64).
Andrew Eddie
>
> I believe it's a little more clear today that flexibility is best achieved
> by keeping the JS/CSS with the template and making certain the HTML markup
> is simple and standard.
+1
Something big is definitely going to happen in 2012 one way or the
other if I'm agreeing with you ;)
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers
Rouven Weßling
The bigger issue is that no one has stepped up and actually providedbehaviors for another framework.
maybe because of debates like this? ;)
wrong question.
Why was it limited to async and defer in the first place?
Any HTML standard since 1996 allows for more.
Same for <link> just slightly different, and "custom" just ain't the
just wondering. Is mootools upgradeable now in the latest platform? It
is not tied to a specific version of mootools, right? This was the
only reason why we used jquery in !J 1.5.11. It had some features that
made manipulations alot easier then mootools 1.1. This was just for in
house development.
Niels Braczek
> Sorry for the delay, I wanted to go back and double-check, just to be
> sure. There is no html5 renderer for form fields. They only render as
> xhtml, and the attributes they allow are hard-coded in the PHP (ex:
> text.php::getInput()).
So what is needed is a HTML5 renderer, maybe even a more advanced
rendering algorithm (and I fully aggree to that), but that has nothing
to do with the subject: jQuery vs. MooTools.
Amy Stephen
On Tuesday, February 28, 2012 4:09:20 PM UTC-6, Andrew Eddie wrote:On 29 February 2012 04:08, Amy Stephen <amyst...@gmail.com> wrote:
>
> I believe it's a little more clear today that flexibility is best achieved
> by keeping the JS/CSS with the template and making certain the HTML markup
> is simple and standard.
+1
Something big is definitely going to happen in 2012 one way or the
other if I'm agreeing with you ;)
Niels Braczek
> The issue with HTML5 support is that we have to make up our minds
> (both CMS and Platform) what kind of output we want to support.
> Currently we're pretty much in XHTML1 land (despite a few HTML5
> templates). Would we be happy to just support HTML5? That's easy,
> writing a patch to significantly improve JForm with HTML5 goodness in
> that case is a matter of a few hours. Or do we want to support both
> XHTML1 and HTML5 output? That isn't so easy anymore for JForm.
I'm dreaming of an Composite structure for categories and any kind of
content (hoping UCM is going that direction), complemented with a
renderer following the Visitor pattern. That way, only the Visitors have
to know anything about output format. XML (DocBook, Dita), XHTML, HTML5,
PDF, WAP, <add your favorite here> can easily be supported. Everything
but the renderers would be totally output agnostic.
Andrew Eddie
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers
Amy Stephen
@Rouven - I agree it's not 100% there but standardization on approach in markup has come a long ways since Mootools was initially added to Joomla. If there is an opportunity to redo the Administrative interface, it will be good to architect this differently so that the JS approach isn't hardwired in. That'll just make Joomla more flexible and useful. But, I do agree it's an over-simplification to suggest that swapping out the package somehow magically addresses the problem. Sorry for overstating.
Paladin
On Feb 28, 2:55 pm, Rouven Weßling <m...@rouvenwessling.de> wrote:
> Answers to quite a few different E-Mails here. You guys were busy while I was away ;)
> Are you talking about HTML5 validation? Because otherwise I don't quite understand how you wanna tell a validator "this is a username" without a convention. The convention in Joomla is to indicate it trough the class validate-username. Same for email, and others.
example micro-data. IIRC, the validators built-in to current browsers
require attributes like "required" and "pattern" (for a regex that is
to be applied), etc. Insisting on using class names only effectively
takes good tools out of the users hands, never a Good Thing To Do.
> The issue with HTML5 support is that we have to make up our minds (both CMS and Platform) what kind of output we want to support. Currently we're pretty much in XHTML1 land (despite a few HTML5 templates). Would we be happy to just support HTML5? That's easy, writing a patch to significantly improve JForm with HTML5 goodness in that case is a matter of a few hours. Or do we want to support both XHTML1 and HTML5 output? That isn't so easy anymore for JForm.
biggest issue is the entire field rendering system needs to be
changed, because you don't *know* ahead of time what attributes are
going to be on the field, and the current attribute names are
infinite, thanks to microdata. Have to admit I was flabbergasted when
I saw the allowed attributes were hardcoded. I mean, I can understand
how user input might need to be sanitized, but if you're sanitizing
input from an XML file on the server, I have to think filtered input
isn't going to be your biggest concern at the moment. ;{>}
IMO best approach is a new method on the field superclass which
returns a properly formatted string of *every* attribute given in the
XML. That would allow the form builder to specify precisely the
attributes he needs for a given form. I know some attention will have
to be paid to what a particular attribute is, etc., but that way we
can be sure of allowing the greatest flexibility to the form builder.
If I get some time this week I'll rough out an approach to doing it
and pass it around.
As for HTML5 v XHTML, there's not a lot of twisting needed between the
two for forms. Might be able to manage it with a flag and if-then
output. A really "off the wall" approach might even be to pass the
chunk through different XSLT's to output the various forms of markup.
That way new markup "flavors" wouldn't require a code change, just
another available XSLT. After all, HTML is a living document; it's
going to be changing again and again. Unless we're saying Joomla isn't
going to be around, I think setting output in stone like this will
turn out to be a costly mistake.
Rouven Weßling
On 29.02.2012, at 18:23, Paladin <arlen....@gmail.com> wrote:
>> Are you talking about HTML5 validation? Because otherwise I don't quite understand how you wanna tell a validator "this is a username" without a convention. The convention in Joomla is to indicate it trough the class validate-username. Same for email, and others.
>
> I know. But there are other (and better) ways of doing that. For
> example micro-data. IIRC, the validators built-in to current browsers
> require attributes like "required" and "pattern" (for a regex that is
> to be applied), etc. Insisting on using class names only effectively
> takes good tools out of the users hands, never a Good Thing To Do.
That's what I mean by HTML5 validation. That's definitively a way I'd like to go in the future but right now it's more hassle than it's worth. Too many browsers with broken or incomplete implementations - or no implementation at all in case of IE.
The nice thing about this is since we abstracted it away in the future when we decide to embrace HTML5 forms this will be possible without extensions having to change their forms.
>> The issue with HTML5 support is that we have to make up our minds (both CMS and Platform) what kind of output we want to support. Currently we're pretty much in XHTML1 land (despite a few HTML5 templates). Would we be happy to just support HTML5? That's easy, writing a patch to significantly improve JForm with HTML5 goodness in that case is a matter of a few hours. Or do we want to support both XHTML1 and HTML5 output? That isn't so easy anymore for JForm.
>
> Not sure how hard it actually would be, but I'll find out shortly. The
> biggest issue is the entire field rendering system needs to be
> changed, because you don't *know* ahead of time what attributes are
> going to be on the field, and the current attribute names are
> infinite, thanks to microdata. Have to admit I was flabbergasted when
> I saw the allowed attributes were hardcoded. I mean, I can understand
> how user input might need to be sanitized, but if you're sanitizing
> input from an XML file on the server, I have to think filtered input
> isn't going to be your biggest concern at the moment. ;{>}
I think JForm was designed with another approach in mind. It's not a tool that just translates some XML 1:1 into a HTML form, it mostly abstracts away how HTML forms work. A good example of this is how the readonly and disabled attributes influence each other.
> As for HTML5 v XHTML, there's not a lot of twisting needed between the
> two for forms. Might be able to manage it with a flag and if-then
> output. A really "off the wall" approach might even be to pass the
> chunk through different XSLT's to output the various forms of markup.
> That way new markup "flavors" wouldn't require a code change, just
> another available XSLT. After all, HTML is a living document; it's
> going to be changing again and again. Unless we're saying Joomla isn't
> going to be around, I think setting output in stone like this will
> turn out to be a costly mistake.
Well for starters, how would you output the placeholder to a XHTML1 form?
An XSLT by itself probably won't cut it either, we do a lot of things in the form fields besides generating the HTML code.
Best regards
Rouven
CirTap
Am 28.02.2012 23:17, schrieb Rouven We�ling:
> Who says those behaviors have to ship with the CMS from the beginning
reality check...
http://extensions.joomla.org/extensions/core-enhancements/scripts
I confess, I haven't used any of these nor do I know (or care) if
there's one based on JHtmlBeahvior, but there seems to be not much of an
agreement on how this ought to work.
Beat's recent take on this as a 'behavior.jquery' wasn't much of a
success either, IIRC.
Am 28.02.2012 23:17, schrieb Rouven We�ling:
> Because I cared about those two and thus I added them.
Lucky you, to modify the Core API and hardwire some parameters that suit
your needs :)
Maybe we/someone/I can "improve" on this in the near future so others
can use a Core API for what _they need_ as well, w/o hacking, patches,
or a bloat load of plugins.
Anway, given your expressed curiosity, my dear Padawan, it seems to me
you didn't bother to do enough research in the first place, which makes
"Most of the global ones are not very useful in elements added to the
HEAD" a pretty cocky statement, don't you think?
Next time you may have a closer look at the correct specs, since you
missed the ID attribute, defined in XHTML ~ anno 2002, and (among
others) is a member of the global attributes that apply to any element
since then an up to "HTML5".
And all browsers handle them very well.
So allow me to remedy your apparent lack of imagination/experience of
what *can* and *could* be done if those "not very useful" attributes
actually come into use:
Lesson 1: Because a <script> can load an external resource (just like
embedded content via img, iframe, video etc.) it also throws an
interesting event, namely: 'onload'.
Stunning, isn't it?
Now what if we populate this "event" attribute according to its purpose?
We can run some JavaScript code, aka event handler.
Disclaimer: We don't want to do such thing in the markup that shows up
in the <body>. That's considered bad practice and obstrusive, but we can
pick our favorite JS lib to handle this.
HEAD or SCRIPT, however is none of the user's business and belongs into
the realm of the developer.
Lesson 2:
Let's have a look[*]:
<script>
var Libs = {
js: {},
mt: {},
push: function(lib, elt) {
if (lib.fn) {
console.log('jQuery', lib.fn.jquery, elt.src);
Libs.jq[lib.fn.jquery] = lib.noConflict(true);
}
else if (lib['version'] && ('implement' in Function.prototype))) {
console.log('Mootools', lib['version'], elt.src);
Libs.mt = lib;
}
}
};
</script>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"
onload="Libs.push(jQuery, this)"></script>
<script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6.4.min.js"
onload="Libs.push(jQuery, this)"></script>
<script src="//ajax.googleapis.com/ajax/libs/mootools/1.4.1/mootools.js"
onload="Libs.push(MooTools, this)"></script>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"
onload="Libs.push(jQuery, this)"></script>
([*] I used CDNs so you can copy and paste this w/o downloading each
library version. It also won't work in a local file using the file://
protocol.)
//end of lessons
As usual our buddy from Redmond needs a little extra care and a slightly
different event attribute to execute this kind of code. As web
developers we're aware that we might "stretch" a standard once in a
while if it comes to support browser emulators from Redmond.
While this little demo snippet doesn't provide much functionality by
itself, in its simplicity and by combining a darn useful attribute with
the mechanics of modern browsers, it already takes care of calling
`noConflict([deep])` automagically and provides access to multiple
versions of jQuery -- should anyone care.
It also lets Mootools do its job poluting the global namespace and to
impose an alternative programming paradigm for those developers that
can't get their head around the prototypal inheritance system which is
native to JavaScript, and who therefor need "classes".
Some consider this the Good Parts of JavaScript ;)
I'll leave it as your homework to find the name of the attribute / event
name and the condition to add prior calling sth. like `Lib.push()` in IE.
Hint: if you've ever dared to work with the native XHR object you most
certainly ran into it. Its name also starts with 'on' and triggers
several times while a resource loads...
This simple trick eventually moves the handling where it's handled best:
to the client.
Any attempt doing this in PHP on the server will end up being guesswork.
Have a nice day,
CirTap
PS: slightly OT:
addScript()'s partner in crime is addScriptDeclaration() and literally
"counter productive" in its own way. There's indeed no use for "onload"
with an inline script, but the inability to add the standard ID
attribute gets in the way doing stuff like this:
2008: http://ejohn.org/blog/javascript-micro-templating/
2012: http://stackoverflow.com/questions/4912586
Rouven Weßling
On 29.02.2012, at 19:46, CirTap <c...@webmechanic.biz> wrote:
> Am 28.02.2012 23:17, schrieb Rouven Weßling:
>> Because I cared about those two and thus I added them.
>
> Lucky you, to modify the Core API and hardwire some parameters that suit
> your needs :)
> Maybe we/someone/I can "improve" on this in the near future so others
> can use a Core API for what _they need_ as well, w/o hacking, patches,
> or a bloat load of plugins.
I dislike your tone. If you don't take me seriously, why should I even consider working on anything you suggest?
I provided a patch for something I found useful for my myself and potentially others - and which I'm still planning to use in the core. It would be trivial for you to provide a patch that adds $attributes to addScript() - it already exists for other methods. I didn't feel it would be useful, you obviously disagree. So provide a patch, don't expect others to do it.
I'm in this for fun and because I enjoy working with Joomla. I don't get paid to work on Joomla and have no bigger business or financial interest in it.
I'd also like to mention that at the time I provided that patch to add defer and async - which is more than a year ago - I had no role or influence or ability to make decisions, just the ability to provide patches and lobby for them.
Since we have gone quite a bit off topic and frankly I don't like talking with people that are condescending I consider this the end of this subdiscussion on my part.
Regards
Rouven
Jason Williams
I have to admit I have a pretty strong dislike for jQuery's syntax, so I'm not the most neutral person in this discussion. But what really worries me is that the whole jQuery vs. MooTools discussion seems to be so centered around the relative popularity instead of technical merit. To exaggerate a bit: Shouldn't we just drop Joomla! development since Wordpress is vastly more popular? (http://w3techs.com/technologies/overview/content_management/all)I'd much rather discuss technical differences to decide where to go.
Also for those calling to drop MooTools for jQuery, this would involve rewriting all scripts. I wonder who's gonna do that? I offered numerous times to help write a jQuery replacement for JHtmlBehavior that is as compatible as possible to the MooTools one (at least from the PHP side of things). I'd just need help with writing the jQuery scripts since I don't know the library that well and frankly don't wanna do it all by myself. So far no one has agreed - I wonder where all the competent jQuery devs are gonna appear from magically.
Best regards
Rouven
Rouven Weßling
On 30.04.2012, at 12:08, Jason Williams wrote:
> Although you say this is centered around popularity, I do feel the CMS needs to move with the times. Statistics don't lie, if jQuery has a very high (90%?) usage compared to other js frameworks then that obviously means a majority of developers/companies prefer to use it. As someone said earlier, its quite clear jQuery has won the war and various developers need to accept that.
> My question is what would happen if mootools activity got so low it stopped completely? Im some circumstances sticking with a framework/tool which is decreasing in popularity can actually do a lot more harm to the CMS than moving on to something else. I don't think mootools will ever die but It looks more risky to leave the whole CMS using it.
Also from what I gathered in the discussion regarding jQuery in the last few weeks there backwards compatibility isn't any better or even worse than MooTools.
> Technical merits: I can't answer this one as im not a heavy mootools user (I don't know anyone who is either) but I would say jQuery seems to be developing at a faster pace.
Rouven
Amy Stephen
IMO, the choice of JS library included in the CMS is mainly a frontend developer issue. Consider this from a perspective of workflow and profit margins. Frontend devs are not hired to create a new carasol or photo gallery or video player with each site build. Instead, they must look for easily integrated solutions that are readily available. Now, with that in mind, consider the difference in offerings and quality and accessibility and road maps and developer teams between jQuery and Mootools. There is simply no question in my mind at all that jQuery has more to offer site builders.
Now, maybe dev teams looking to build powerful applications might need a tool like MT's or Backbone or Spine or one of dozens, if not hundreds of compelling options available. But, now that we have the platform separated from the CMS, those teams are far more likely to take that route and then they can choose their own JS tools.
I think the separation can help us focus the CMS more clearly on it's target audience. IMO, that's frontend devs working on tight budgets, looking to integrate that which is available, not start from scratch.
My 2 cents.
Andrew Eddie
> It all comes down to target audience. Who is the JS library primarily for?
context of software engineering principles. If the problem you are
still trying to solve requires an SE solution, Mootools and a host of
other will serve you well. Having said that, it has to be conceded
that most of the Joomla CMS world doesn't need a SE solution for
simple Javascript behaviours like menus and tabs and image sliders,
and because you don't need to be a programmer to get a result with
jQuery, that's why it's so popular. I think the CMS, for what it's
worth, should swap over to jQuery … provided those that want it put up
a sane change management plan to do so
However, when you are talking about ground-up applications, I don't
think we should lock into any JS framework - it should be left up to
the developer. The reality is the JS in the platform and the CMS is
far from par by any standard and just refactoring the current code to
work with jQuery is a non-solution - that's just painting the bike
shed a different colour without giving any thought for its state of
disrepair.
Recommendation: remove JS from the platform altogether (and probably
start a completely separate UI element sub-project in the process).
Louis Landry
Elin Waring
Discussion of what the CMS should do most certainly doesn't belong here, though as most people presumably know there are potentially changes to the CMS (involving possible use of the Bootstrap framework which in turn incorporates jquery) that are under discussion and those who might be interested in that topic should really participate on the appropriate lists and in the jux forum.
Rafael Corral
I just did a pull request of an implementation I did months ago for a "javascript library manager" it allows an extension to register a javascript library along with any CSS and JS files that it may require (which is something other implementations have not considered) and it allows for loading it to the document afterwards.
Here is the link to the pull request: https://github.com/joomla/joomla-platform/pull/1192
Here is an example on how it would be implemented through a plugin to load jquery:
https://github.com/rcorral/joomla-cms/commit/bf71fa00ede7620c67367ae05a5b3d6dc7b410c5
Let me know your thoughts on it.
Rafael
On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
I know, it's always the same question, but should we not prefer one of these libraries ?
For quite some time, i read a lot stuff about "best way to integrate jquery and prevent the problem of different versions"
and i seriously don't understand the discussion. It shouldn't be difficult to add a sort of "version" to the scripts array we use to avoid duplicated entries.
I think the main question should be if we want to use jquery or mootools in core, which also will show our prefernces.
Mootools is a great (and real) JS framework, but since most of the extensions are using jquery i thought that we should see that
as a wake-up call. The community wants to use jquery.
So is there any concern about the (optional) use of jquery instead of mootools ?
piotr_cz
between jQuery an Mootools.
I've learned Mootools, because I was forced to by Joomla :) and now
I'm happy this happened.
jQuery is DOM manipulation tool but in today's world I see it's
optimal usage as a polyfill for IE6-8. Most of it's funkineness (and
more) is available in modern browsers natively and on majority of
smartphone browsers (CSS3 animations, queryselector, forms validation,
etc).
Developer has to choose carefully JS tools based on the project type:
Full version of Mootools Core and jQuery (both ~94kb minified) are not
necessary for smartphone websites when much of the functionality is
available natively, or just not required for simplified layout.
jQuery (and often) MooTools is appropriate tools when building
structured client-side webapp with Joomla platform as the backend.
Moving to jQuery would make sense if Joomla would decide to target
only desktop cms users on ancient browsers.
I'm rather interested in the Javascript library management effort
(https://groups.google.com/group/joomla-dev-cms/browse_thread/thread/
6b6016bc08f0bbb7#) with added dependency support (like
https://github.com/kamicane/packager) and compression tool.
It really doesn't make sense to force developers to use one thing to
fit all scenarios. It all depends on project:
CMS frontend on desktop: simple DOM manipulation tool (native /
jQuery/ Mootools)
CMS frontend on mobile: native features: CSS3 + JS html5 api,
additionally DOM manipulation tool with small footprint (Zepto/ custom
Mootools builds)
CMS Backend: any framework with ajax and DOM stuff for UI
Platform webapps: simple: Mootools, complex: MVC tool (https://
github.com/addyosmani/todomvc/tree/master/architecture-examples)
Platform webapps on mobile: above + moobilejs / jQuery Mobile
On May 9, 6:39 am, Rafael Corral <rxcor...@gmail.com> wrote:
> Hello everyone,
>
> I just did a pull request of an implementation I did months ago for a
> "javascript library manager" it allows an extension to register a
> javascript library along with any CSS and JS files that it may require
> (which is something other implementations have not considered) and it
> allows for loading it to the document afterwards.
>
> Here is the link to the pull request:https://github.com/joomla/joomla-platform/pull/1192
>
> Here is an example on how it would be implemented through a plugin to load
Rafael Corral
reasons but if MooTools is going to always be there, then so be it, I won't loose sleep over it,
maybe what we need is to do a poll like the ones that have happened in the past.
Ideally we would have all the javascript which comes with a standalone package of Joomla
written without any dependency to any library, unfortunately this would be very time consuming
for anyone to take on. BUT if this was done it would allow the person developing a site to pick
extensions that use the library that they want to use.
What I developed allows extensions to register any libraries that they use so that there
are not 3 different version of jQuery on a website, this way only one loads.
Nick Weavers
David-Andrew
Op maandag 6 februari 2012 14:53:35 UTC+1 schreef Nils Rückmann het volgende:
Elin Waring
Elin
piotr_cz
comprehensive bundle like this.
I guess any kind of extended javascript library management in the
Platform would be just a complication for the developer. There are
just too many ways to do it, ie: loading scripts with require.js or
generating platform specific applications on the fly on client side
(http://walmartlabs.github.com/lumbar/) or server side.
In Joomla CMS frontend, I think centralized library management could
be really useful for reasons that were mentioned numerous times +
asset minification. People prefer jQuery for frontend extensions as
(let's be honest) - most of Joomla users are going for painless trendy
effects.
Now, since PLT has agreed on including Twitter bootstrap and jQuery in
Joomla 3.0, I see this kind of solution (this concerns Platform too):
There must be some framework for CMS backend for handling UI
components and backend further ajaxification. I don't think anybody
has problems with Mootools being there. In my opinion when somebody
decides to write complex extension for admin area, this is the more
logical choice then jQuery.
Anyway to use Twitter bootstrap we would need to rewrite UI components
(JHtml::tooltips, calendar, panes, JHtmlSliders, JHtmlTabs,
JHtmlGrid...) to output Bootstrap namespace compatible html, and move
the javascript parts that configure UI component out from document
head to component initalization.
When there is UI functionality not supported by bootstrap yet or UI
component init options (currently opened tab, enabling client-side
storage for tabs state), this could be set in html output using data-
attributes and picked up by JS UI class.
There are possibly few other places in the platform, where javascript
is used (JText output for JS) but this can be possibly handled by
vanilla JS.
Completely other issue are MooTools classes like validate.js or
core.js package
piotr_cz