>>> 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.
On Feb 28, 11:39 am, Niels Braczek <nbrac...@bsds.de> wrote:
>> 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.
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()).
Answers to quite a few different E-Mails here. You guys were busy while I was away ;)
On 28.02.2012, at 17:25, Paladin wrote:
> 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.
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.
> (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.)
Sorry, I misread. Could you point me to one or two you like? I reading up on form validation a bit right now and would like to look at some other scripts out there (no promise any code will come out of it thou).
On 28.02.2012, at 19:08, Amy Stephen 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.
In theory that's the perfect solution. There are two caveats: -Most popular JS plug-ins depend on certain classes/id/elements. Bootstrap is actually a pretty good example of that. I recently changed my website to use Bootstrap (I'm no designer, it looks pretty - but just like any other bootstrap page), I used MooTools ports of the bootstrap script (I'm only using one) and had to create a view layout overrides to make things match bootstrap. Now think about something more complex like modals which you can configure quite a bit trough the rel attribute, you'll never find a second script that's just a drop in replacement for Squeezebox. You can however write a compatible one with any framework you like. -We kinda already offer that - not prefect thou - the HTML behaviors were, from my understanding, designed to make it easier to use other frameworks with Joomla. You just add JHtml::_('behavior.keepalive'); to your layout and you get the keep alive behavior and you don't have to care about how it is implemented JS wise. There are limitations to this, some things are not replaced by this approach (strengthmeter in JFormFieldPassword, lots of things in JHtml) but these are rarely used in the frontend. The bigger issue is that no one has stepped up and actually provided behaviors for another framework.
On 28.02.2012, at 20:47, CirTap wrote:
> 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?
> 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.
On 28.02.2012, at 20:52, Paladin wrote:
> 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()).
Correct. I just recently added some HTML5 support to JDocument so we can get the new <meta charset=""> element.
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.
> The bigger issue is that no one has stepped up and actually provided > 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.
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.
On Tue, Feb 28, 2012 at 12: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 ;)
> On 28.02.2012, at 17:25, Paladin wrote:
> 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.
> 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.
> (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.)
> Sorry, I misread. Could you point me to one or two you like? I reading up on > form validation a bit right now and would like to look at some other scripts > out there (no promise any code will come out of it thou).
> On 28.02.2012, at 19:08, Amy Stephen 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.
> In theory that's the perfect solution. There are two caveats: > -Most popular JS plug-ins depend on certain classes/id/elements. Bootstrap > is actually a pretty good example of that. I recently changed my website to > use Bootstrap (I'm no designer, it looks pretty - but just like any other > bootstrap page), I used MooTools ports of the bootstrap script (I'm only > using one) and had to create a view layout overrides to make things match > bootstrap. Now think about something more complex like modals which you can > configure quite a bit trough the rel attribute, you'll never find a second > script that's just a drop in replacement for Squeezebox. You can however > write a compatible one with any framework you like. > -We kinda already offer that - not prefect thou - the HTML behaviors were, > from my understanding, designed to make it easier to use other frameworks > with Joomla. You just add JHtml::_('behavior.keepalive'); to your layout and > you get the keep alive behavior and you don't have to care about how it is > implemented JS wise. There are limitations to this, some things are not > replaced by this approach (strengthmeter in JFormFieldPassword, lots of > things in JHtml) but these are rarely used in the frontend. The bigger issue > is that no one has stepped up and actually provided behaviors for another > framework.
> On 28.02.2012, at 20:47, CirTap wrote:
> 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?
> 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.
> On 28.02.2012, at 20:52, Paladin wrote:
> 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()).
> Correct. I just recently added some HTML5 support to JDocument so we can get > the new <meta charset=""> element.
> 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.
The reason why I choose Joomla over Drupal was Mootools. I'll be sad if that goes away.
Also, using popularity as the signal, I think we should all move to Wordpress then as it is more popular than Joomla.
On Tue, Feb 28, 2012 at 22:52, Paladin <arlen.wal...@gmail.com> wrote:
> On Feb 28, 11:39 am, Niels Braczek <nbrac...@bsds.de> wrote: > >> 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.
> 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()).
-- Jonathan Seni.
There are 10 kinds of people in this world, Those who knows numbers, and Those who wait for the other 8 people to be listed ---------------------------------------------------- SimplyMepis, SuSE 9.2, openSuSE 10.2 /10.3/11.0/11.1/11.2 /11.3/11.4(x86-64).
On 29 February 2012 04:08, Amy Stephen <amystep...@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 ;)
>> The bigger issue is that no one has stepped up and actually provided >> behaviors for another framework.
> maybe because of debates like this? ;)
Who says those behaviors have to ship with the CMS from the beginning or event at all? They could just be a plug-in overriding JHtmlBeahvior and - IMO - would give the whole "jQuery into core" dicussion much more benefit.
> wrong question. > Why was it limited to async and defer in the first place? > Any HTML standard since 1996 allows for more.
Because I cared about those two and thus I added them. The script element doesn't allow that many attributes, the only non global attribute were missing is charset. Most of the global ones are not very useful in in elements added to the HEAD. So I'd actually be curios what you're missing.
> Same for <link> just slightly different, and "custom" just ain't the
Link's certainly a different discussion, than thing could use some work.
On 28.02.2012, at 22:17, Andy Nagai wrote:
> 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.
It's not. But we're able to keep up with new versions much better because the MooTools team has invested more energy in backwards compatibility. The only thing that was updateable was Joomla 1.5 that could be updated to MooTools 1.2 starting with - I think - 1.5.19. Interestingly using the override JHtmlBehavior method ;)
> 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.
Yikes. Maybe the world *is* going to end in December... ;)
On Tuesday, February 28, 2012 4:09:20 PM UTC-6, Andrew Eddie wrote:On 29
February 2012 04:08, Amy Stephen <amystep...@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 ;) about the (optional) use of jquery instead of mootools ?
> 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.
> Yikes. Maybe the world *is* going to end in December... ;)
> On Tuesday, February 28, 2012 4:09:20 PM UTC-6, Andrew Eddie wrote:On 29 > February 2012 04:08, Amy Stephen <amystep...@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 ;)
> about the (optional) use of jquery instead of mootools ?
@Andrew, sorry about that. I am not certain where that last line came from. Looks like that line remained somehow when I (tried to) delete the other responses.
@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.
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 ;)
Sorry. Just was fresh in my mind.
> 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.
> 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. ;{>}
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.
On 29.02.2012, at 18:23, Paladin <arlen.wal...@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.
> Who says those behaviors have to ship with the CMS from the beginning > [...] They could just be a plug-in overriding JHtmlBeahvior
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; } }
([*] 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
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.
On Wednesday, February 8, 2012 6:15:18 PM UTC, Rouven Weßling wrote:
> 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
HI Rouven
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.
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.
As for your second point, im quite happy to help writing jQuery scripts.
> 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.
By that line of thought we'll all be developing Wordpress very soon ;) Also no one should use anything but Windows on the desktop, Linux on webservers, PHP to develop web apps. Also no tablet but the iPad should be used. See where I'm going? Popularity is an indicator but no sufficient argument for the quality of a product or technology. In general I think that monocultures are generally bad but admittedly in the JS libraries space we haven't seen any effects from this.
> 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.
If activity stopped completely - which I see no evidence of happening - there'd be very soon very good reasons to switch. For starters bugs with browsers that don't get fixed. That we'd have no choice but switching. Also if switching to a different framework would bring us big rewards it could be considered. But don't forget that there's a huge cost associated with such a change. Dozens of scripts will have to be rewritten, extensions will have to change, etc.
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.
And I'm not a heavy jQuery user ;) But so far I'm not missing anything.
It all comes down to target audience. Who is the JS library primarily for?
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.
On Thu, May 3, 2012 at 10:13 AM, Rouven Weßling <m...@rouvenwessling.de>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.
> By that line of thought we'll all be developing Wordpress very soon ;)
> Also no one should use anything but Windows on the desktop, Linux on
> webservers, PHP to develop web apps. Also no tablet but the iPad should be
> used. See where I'm going? Popularity is an indicator but no sufficient
> argument for the quality of a product or technology. In general I think
> that monocultures are generally bad but admittedly in the JS libraries
> space we haven't seen any effects from this.
> > 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.
> If activity stopped completely - which I see no evidence of happening -
> there'd be very soon very good reasons to switch. For starters bugs with
> browsers that don't get fixed. That we'd have no choice but switching. Also
> if switching to a different framework would bring us big rewards it could
> be considered. But don't forget that there's a huge cost associated with
> such a change. Dozens of scripts will have to be rewritten, extensions will
> have to change, etc.
> 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.
> And I'm not a heavy jQuery user ;) But so far I'm not missing anything.
On 4 May 2012 05:29, Amy Stephen <amystep...@gmail.com> wrote:
> It all comes down to target audience. Who is the JS library primarily for?
Mootools was originally chosen because it made more sense in the
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).
I was about to respond to this, but Andrew and Amy have said pretty much
exactly what I would have said.
The question of what the CMS should do can be discussed on the CMS list or
other appropriate places, and I agree with Andrew and Amy's assessment
here. I also strongly agree that we should move the JavaScript out of the
Joomla Platform repository.
On Thu, May 3, 2012 at 8:24 PM, Andrew Eddie <mambob...@gmail.com> wrote:
> On 4 May 2012 05:29, Amy Stephen <amystep...@gmail.com> wrote:
> > It all comes down to target audience. Who is the JS library primarily
> for?
> Mootools was originally chosen because it made more sense in the
> 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).
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.
That said, the ultimate question on this side of things is what is the purpose of the platform other than being a place to have forward looking classes that are either fun to write or useful to the people writing them (which is fine). If the goal is actually intended to attract developers writing moderately complex applications some consideration might be given to why someone would use the platform as a platform rather than the CMS as a platform given that the CMS provides you with implementations of what the platform offers for authentication, user management, access control, session management, routing and other useful things that many web applications need and that includes one or more javascript frameworks. If every time someone writes a platform application they are going to be told that the choice is start from scratch or go copy the CMS plugins for everything from authentication to editors or copy the toolbar library from the cms or go grab the media folder or system template, that does make one wonder if there needs to be a middle layer where those building blocks reside. Or, perhaps, CMS 4.0 should be thought of as that layer since JContent is going to make it so much more streamlined.
In that case it makes sense to move the javascript framework out of the platform to the CMS and for the CMS team to determine what developers (whether site developers/designers or application developers) using it as a platform find useful.
On Friday, May 4, 2012 2:45:03 AM UTC-4, Louis Landry wrote:
> I was about to respond to this, but Andrew and Amy have said pretty much > exactly what I would have said.
> The question of what the CMS should do can be discussed on the CMS list or > other appropriate places, and I agree with Andrew and Amy's assessment > here. I also strongly agree that we should move the JavaScript out of the > Joomla Platform repository.
> On Thu, May 3, 2012 at 8:24 PM, Andrew Eddie <mambob...@gmail.com> wrote:
>> On 4 May 2012 05:29, Amy Stephen <amystep...@gmail.com> wrote:
>> > It all comes down to target audience. Who is the JS library primarily >> for?
>> Mootools was originally chosen because it made more sense in the
>> 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).
