Joomla 1.6 going incompatible Mootools 1.2 ? or jumping onto jQuery 1.3 while it's anyways incompatible to joomla 1.5 mootools 1.1 ?

[Beat]

Sorry if this debate has already been done, but just to be sure that
we don't miss something here...

Joomla 1.5 uses Mootools 1.1.

Mootools 1.2 is incompatible with Mootools 1.1 (that's by design
principles).

Joomla 1.6 seems to intend to use Mootools 1.2, which will break all
Mootools 1.1 based templates and extensions.

I'm not going into the debate which is better, but simply seeing that
jQuery 1.3 has a way bigger community and is way faster than Mootools
1.2, and is still compatible with previous jQuery versions, I would
like to ask IF in Joomla 1.6, as Mootools 1.2 is incompatible anyways,
we shouldn't go following route:

- Keep Mootools 1.1 for compatibility with Joomla 1.5 in legacy mode

- Use jQuery 1.3 latest for Joomla 1.6 native mode.

Again, *don't wish to start a debate which js-library is better*, but
simply looking at compatibility track-records, and number of plugins
available and size of community using each, it would probably make
sense for leading Joomla CMS to use leading js-library jQuery (+
jQueryUI in backend) instead of Mootools 1.2 ?

Best Regards,
Beat

[Mr Phil E. Taylor]

Totally agree! for all the same reasons.

Plus Mootools has a stupid name :-) :-)

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send email to joomla-...@googlegroups.com
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB
> -~----------~----~----~----~------~----~------~--~---
>
>

[Andrew Eddie]

Let's avoid bagging the names of other projects and keep the debate to
technical merit only, shall we?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer


2009/6/9 Mr Phil E. Taylor <ph...@phil-taylor.com>:

[Mr Phil E. Taylor]

Lighten up :-) It was merely a light hearted comment - geessh.

[Andrew Eddie]

Take it seriously, and I will (lighten up).

Beat, I don't think you're going to win that one just on it's a bigger
community. You would need to present a very solid case to head down
that track.

[Jonathan Cheung]

+++

but i think they will use mootools 1.3

2009/6/9 Andrew Eddie <mamb...@gmail.com>

[Hannes Papenberg]

Joomla 1.6 wont have a legacy mode, so we can't keep mootools in legacy
mode anywhere. Besides that, we already had the discussion about JS
libraries on this list. About 1.6 breaking templates and extensions:
Mambo/Joomla has been stable for extensions for at least the last 5
years. Show me a software (especially open source) that still allows you
to use the same plugins for the last 5 years. At one point we just have
to make changes that break extensions.

Hannes

Beat schrieb:

[dukeofgaming]

Beat, why don't you take a look at this article by Aaron Newton?: http://www.jqueryvsmootools.com/

I see constantly the mootools framework is not the most popular vs. other frameworks like Dojo, Prototype or jQuery, but IMHO (as a developer, not designer) it does the best job balancing elegance, design (syntax, api, extensibility) and simplicity.

I think the decision of adopting mootools was based on the extensibility factor, not that it had the biggest devbase or the most snazzy widgets. I once did a distributed online ajaxy quiz game for a client that needed this for a big country-wide event, all in a very simple fashion , you could swear it was flash ;P... later on for the closing event the client requested me to add concurrency to the application, and it was a no-problem situation.

My point here is that mootools is great for developing your own stuff. Unfortunately the rework of mootools towards the 1.2 version was a violent one, but it is unlikely this will happen again so I think the argument of backwards compatibility is a rather circumstantial one.

I do think that the framework should add more freedom for the devs allowing the deactivation of mootools, something being discussed here.

[Amy Stephen]

This past few weeks, I have been looking for "easy to use" UI widgets that I need for a project a team of us are working on. It is Intranet environment with a lot of varied content, the need for groups, sophisticated ACL, and a high degree of interactivity.

Traditional page reloading after each minor task will not cut it. These people will be working all day with this tool, it has to be easy to access what they need, make changes, approve work, schedule meetings, message one another, etc.

To be perfectly honest, after reviewing options out there, there is no question in my mind about which JS Framework will enable me to offer more functionality, quickly today: JQuery. It is not even close for me.

From what I have read, most tend to agree Mootools is the "better" solution from an application infrastructure perspective. But, UI experts are not developers and JQuery is more geared towards those needs and skill sets.

The size and engagement of a community does matter. We know this because we, the Joomla! community, are also a huge, active, powerful community. When people are comparing CMS's, one look at the Joomla! Extensions Directory says - this community will help you build cool Web sites. I get that same feeling about JQuery's community. They are active, creating, and sharing a lot of excellent UI options. They are growing. There are lots of training material, blogs, videos, and books.  As is the case with the Joomla! community, they are putting solutions on the shelf on a regular basis and they don't appear to have hit full stride, yet, either.

The work that community produces enables someone like me, someone without strong Javascript skills (heck, someone without even weak Javascript skills!), to be able to tackle a Web site like this.

To be honest, the fact that Joomla! has Mootools in core does not cause me, one tiny bit. I know how to remove it and I know how to replace it with JQuery and that is what I will do in order to provide this customer the best solution, possible.

I probably would not have raised this issue, because I know it's a huge challenge to make a change like this. We will not all agree on this one and there is no way to scientifically conclude, one way or the other. I also understand and *value* the freedom the GPL offers me and I will, without apology, exercise those rights. So, Joomla! is not stopping me.

But, after reading Beat's comment about how, since 1.2 is not compatiable with 1.1, anyway, that *now* is as likely the best opportunity we will ever have to consider a change to JQuery. I realized when I read that, that he is right and he is right to raise the issue and advocate for what he sees as a better path for our project. I would be wrong to just do my own thing quietly without also letting it be know that I also believe JQuery is best for this project.

I also believe it would very wise for this project to get behind Ajax and share examples of how to use it with Joomla!. Like it, don't like it, doesn't matter, it's a key building block for developers today and an absolute requirement if you are heading into rich internet applications. So, framework decision aside, we should show how to use Ajax with that framework to create those types of Joomla! interfaces. (BTW: by "we should" I mean all of us posting in this thread, not the guys working too hard for us, already.)

So, I agree, it is time to think about those things. It's that big of a deal that, we should at least pause for a moment, to think about which direction might offer the community the best options moving forward. We need to bear in mind that since this is one of those either/or kinds of deals, some of us aren't going to get our way. There is no reason for anyone to fall into a heap of tears when it is likely decided we will stay the course with Mootools. Let's remember the GPL empowers us to modify this code base and crank it up in whatever way we find suitable for our needs. We are all empowered as we choose to be.

With respect to all of you,
Amy

[eveevans]

I like jQuery , whatever, but I think J!1.6 doesn´t need to have a js
framework for the default, because there are a lot of designer that
prefer other js framework , and for now the only option is to use the
compatible mode (if apply) or hack the J!

[eveevans]

I mean,
J1.6! doesn´t need a js framework for default in the front-end , but
in the back-end there is no problem whatever it uses

On 9 June, 04:20, Beat <beat...@gmail.com> wrote:

[G. D. Speer]

Nicely said.  My take ...

 

1)  Beat is correct in that we have an opportunity to take a white sheet of paper approach to selecting a framework as backwards compatibility or legacy operation is not a possibility.

 

2)  The referenced article is very persuasive about the technical merits of Moo and it's holeistic approach.  The engineer in me says that it give us the broadest technical richness.  The more explicit language structure makes it more readable.  However, the business manager asks, 'but do we really need it and is it worth the cost?'

 

3)  I, like Amy, use jQuery frequently because it helps me get to "done" quickly.  I am not versed in the subtleties of the JS inheritance model so I am frequently looking at the code examples by 'those who have gone before'.  I will admit to having copied and pasted code and done rigorous testing instead of understanding it line by line, arguement by arguement simply because I don't have the luxury of time sufficient to get to exquisite knowledge on a minor UI feature.  I try a tool and if it works - unless the site is mission critical - that's usually good enough for me.  I know there is a cost of using abstractions of abstractions, but the performance hit - time to first page - while important, is relatively minor compared to the dozens of other things on the page that generate too many http requests or bloat page weight.  A minified library or even two or three in the download stream is a fair price to pay, especially if I can get at a previously cached copy of a framework via Google/Yahoo, etc.

 

4)  It seems like it's forgotten in the discussion.  jQuery and Mootools can co-exist.  jQuery can run in compatibility mode and this gives us the best of both worlds.

 

5)  We haven't taken the discussion and given it true context.  Mootools as it's used today in J! core and in many frequently-used extensions - is it being used to manipulate the DOM and therefore jQuery is a functional equivalent in scope or are there a lot of dependencies in 1.5 upon Mootools-only features like extended inheritance that have no jQuery analogous feature?  My impression is that all the core uses of mootools is to provide UI enhancement via DOM manipulation functions and therefore either tool could be implemented with no loss of existing functionality - just a reduced playground for future development by JS coders.

 

6)  Given all this, my take is that if we have to rewrite framework calls anyway, and there is a way to actually provide both frameworks to those that have deeper needs, and the community resources and easier-to-approach syntax of jQuery, that the vast majority of Joomla adopters are better served by giving them an easier environment to plug-in a feature and gently tweak easier-to-read code.

 

So, between:

1)  Rewrite to Moo 1.2 and figure out how to manage Moo / Moo-More / Moo-Joomla.

2)  Rewrite to jQuery 1.3 native

or

3)  Rewrite to jQuery 1.3 compatible allowing optional addition of Mootools for non-core needs,

I vote to choose #3 even though it means that the simple $ is not available and that an extra effort is needed to

teach devs that they should either rewrite their extensions to work in compatibility mode, or to migrate to Moo 1.2 knowing that jQuery is also loaded by default and by default is running in compatibility mode.

 

Knowing that I am not alone in finding jQ more intuitive to use and that Amy is taking the same workaround approach I am to get the job done, I have to think that much of our community would be similarly benefitted and that supporting jQuery without excluding Mootools will enhance our market presence, particularly for the 80% of the market that will not be learning JS as part of using Joomla except to locate and plug in a bit of jQuery code or plugin they found on a site somewhere.

 

 

---

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.58/2164 - Release Date: 06/08/09 17:59:00

[Ethan Gardner]

I have used both MooTools and JQuery, and I prefer MooTools.
Personally, I don't rely on a very many plugins so it doesn't really
matter as long as you can still place PHP in the index.php file to
strip out the script blocks in the head of the document for the guest
users. I have been using this approach to 1) include MooTools 1.2 on
my site almost since its release date, 2) gzip and combine js files
into 1 file before serving it to the browser 3) put the script blocks
close to the bottom of the html so the page loads quicker.

Even if Joomla doesn't use MooTools in v1.6, it would still be great
to have the ability to override the default settings.

[Mr Phil E. Taylor]

> 2) The referenced article is very persuasive about the technical merits
> of Moo and it's holeistic approach. The engineer in me says that it
> give us the broadest technical richness. The more explicit language
> structure makes it more readable. However, the business manager asks,
> 'but do we really need it and is it worth the cost?'

Did you mis this bit:

"Disclaimer

I am a MooTools developer. I work on the MooTools framework. I blog
about MooTools. I wrote the main online tutorial and the book about
MooTools. Obviously, I have a perspective that is somewhat biased."

:-) :-)

Kindest regards
Phil.

[Antti Tuppurainen]

I would like to give some advices from purely web developers perspective - not backend developer, but site builder, theme builder and JavaScript developer.

I don't like basically any output that is not somehow easily overrided or semantically correct. This said: Microsoft Moss is worst "CMS" for theme builder. The core outputs so much of stuff to theme that is just too hard to handle. Maybe this is one of the reasons why Microsoft is developing the .net mvc framework: output is clear. They have choosen jQuery into the core just to give some standards for developers - it is not included to output but its there. http://blog.jquery.com/2008/09/28/jquery-microsoft-nokia/

Nokia is using jQuery in mobile devices

ah - drupal and wordpress are too.

what ever, but I would like to say: Keep the core output as clean as possible and do not include any css/javascript from core that is not easily overridable.  The backend can be "what ever javascript"  and the frontend in "edit mode" could be in combatibility mode.

--
Antti Tuppurainen
http://antti.tuppurainen.fi || http://www.mediawrox.com 

[Ron Severdia]

Having used both myself, MooTools isn't as widespread (or powerful) as
jQuery, but it's a better solution when you take all the previously
discussed factors into consideration (I won't bore you with a rehash
of the same arguments for and against). It's not a popularity contest,
it's about using the right solution for Joomla out of the box. As
mentioned above, they can fairly easily co-exist in Joomla so if
you're a jQuery developer, just add it and get on with your work.

[G. D. Speer]

<warm smile> No, I didn't - I'm just giving full credit to some of the
points made and that going too Moo 1.2 is not an inherently wrong choice.

I just agree with Amy, that our default option for the 80-20 rule users
would be better off with jQuery as the default with Moo as
the add-on for rare cases as opposed to taking the opposite Moo-centric
approach.

This choice has Mac v. PC fervor to it and the real issue is whether the
Core Devs adapt to meet needs of the majority of the j! market or
the users and TP Devs adapt to the coding convenience of the Core Devs.

Do the needs of the many outweigh the needs of the few? <Spock paraphrased>

----- Original Message -----
From: "Mr Phil E. Taylor" <ph...@phil-taylor.com>
To: <joomla-...@googlegroups.com>
Sent: Tuesday, June 09, 2009 1:00 PM
Subject: Re: Joomla 1.6 going incompatible Mootools 1.2 ? or jumping onto
jQuery 1.3 while it's anyways incompatible to joomla 1.5 mootools 1.1 ?

>

[Andrew Eddie]

With respect this is a bit like splitting hairs over the Drupal vs
Joomla debate. Both are stunning, both have supportive and different
communities with strengths and weaknesses.

We have had good connections with the Mootools creators and experts so
far. We don't have that relationship with the jQuery community (note
the lowercase 'j'; JQuery is our new database query class <cough>) as
far as I know. I don't see any particularly good reasons to sever
that goodwill where there is honestly no better argument than personal
preference. That might change in the future, but right now it does
what it needs to in the backend and the frontend is being made as
agnostic as possible.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/6/10 Amy Stephen <amyst...@gmail.com>:

[Amy Stephen]

Yes, Mootools is certainly in the Administrator. I suppose if someone feels passionately enough about swapping out the frameworks, then, coming with a well developed patch in hand would be requisite.

I think you hit the nail on the head in terms of how most people feel - the front-end should be agnostic to JS.

You raise a good point, too, about the need to begin working with the jQuery community and develop good working examples of how to use jQuery with Joomla!.

I think designers love what's available in JQuery and when they learn those UI objects can be used with an equally easy to use and highly functional CMS, like Joomla!, we should see some cool things coming out of that powerhouse combination.

Andrew, thank you for always being thoughtful and open to ideas.

Amy :)

[Stian Didriksen]

Relationships between you and Mootools devs is completely irrelevant.
There are far too many developers using jQuery to ignore.

And if Joomla used jQuery, preventing Mootools based scripts from
breaking is as simple as writing your jQuery in noConflict() mode.
That would mean no 1.5 based mootools 1.1 scripts breaking.

Can we achieve the same by using Mootools?

I say core scripts should be coded like shadowbox, using adaptors that
is: http://www.shadowbox-js.com/support.html#adapters

Your relationship with Mootools wont help me in my next project, but
being able to code with whichever framework I need will.

I would like to see some hard facts on what goodwill Joomla as an
project get, that you are afraid of loosing?
That's the most personal and biased argument I've heard today.

Regards,
Stian Didriksen

[Beat]

Hi Andrew,

Sincerely don't wish to open a PC/mac-style debate here.

I don't wish to "win" my case, and do not care to "loose" either, as I
don't want to make a case for jQuery or for mootools.

For many reasons that are well documented in the web, I use jQuery in
my projects, and fully understand and respect that others are more
used or prefer mootools for many other well documented reasons.

Switching joomla to jQuery would require careful planing, design and
implementation, something way too short for June 22nd alpha.

I just wanted to make sure that the "white sheet" approach was taken
for joomla 1.6, and issues taken into account. Seems to be the case,
thank you.
Thread could thus be closed to avoid further loss of time.

Best Regards,
Beat

P.S. Regarding "legacy", I didn't mean "joomla 1.0-legacy" in joomla
1.6, but "joomla 1.5-legacy mode" in joomla 1.6.

On 9 June, 12:43, Andrew Eddie <mambob...@gmail.com> wrote:
> Take it seriously, and I will (lighten up).
>
> Beat, I don't think you're going to win that one just on it's a bigger
> community. You would need to present a very solid case to head down
> that track.
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/6/9 Mr Phil E. Taylor <p...@phil-taylor.com>:

>
> > Lighten up :-) It was merely a light hearted comment - geessh.
>
> > Andrew Eddie wrote:
> >> Let's avoid bagging the names of other projects and keep the debate to
> >> technical merit only, shall we?
>
> >> Regards,
> >> Andrew Eddie

> >>http://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> >> 2009/6/9 Mr Phil E. Taylor <p...@phil-taylor.com>:

> >>> Totally agree! for all the same reasons.
>
> >>> Plus Mootools has a stupid name :-) :-)
>
> >>> Beat wrote:

[Andrew Eddie]

The other side of the coin is that popular does not always translate
to quality. You just have to look at our JED to know there is a lot
of, lets say, sub-par material.

Now, one caveat to this is core supported js magic on the frontend is
going to use mootools - case in point, the AJAX features of the
comments system. Form validation will be JS framework (aka Mootools)
based. So there are going to be issues simply because different
developers choose to use a different JS framework. Having said that,
if we keep it all in the layouts, someone could write jQuery overrides
to make it suitable for a site that uses mission-critical jQuery
extensions.

I think there is a way for Mootools and jQuery to coexist so we should
obviously make sure library loaders do allow for that.

But, at the end of the day, you have to choose one for a CMS and thus
far we have an excellent relationship with the Mootools community.

[Andrew Eddie]

2009/6/10 Beat <bea...@gmail.com>:

>
> Hi Andrew,
>
> Sincerely don't wish to open a PC/mac-style debate here.

No, we definitely don't, because I love my Mac :P

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[G. D. Speer]

Andrew - Points well taken.

I see zero reason to change the backend - I would agree that Mootools is the
best adjunct for that.

To clarify, my comments solely relate to the frontend, the Behaviour
Mootools situation and
while you say we are agnostic, the default is to enable use of Mootools 1.1
which is now obsolete - hence the discussion.

----- Original Message -----
From: "Andrew Eddie" <mamb...@gmail.com>
To: <joomla-...@googlegroups.com>
Sent: Tuesday, June 09, 2009 3:17 PM
Subject: Re: Joomla 1.6 going incompatible Mootools 1.2 ? or jumping onto
jQuery 1.3 while it's anyways incompatible to joomla 1.5 mootools 1.1 ?

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - www.avg.com

Version: 8.5.339 / Virus Database: 270.12.59/2165 - Release Date: 06/09/09
05:53:00

[Andrew Eddie]

Hi Stian and thanks for joining in.

Everyone has biases ;) This thread would not have started.

Here's the argument. Mootools is very good. jQuery is very good.
Both have good communities. Joomla devs have a good relationship with
Mootools developers, the chose JS framework for Joomla. Mootools
serves Joomla's needs well. There is no *compelling* argument to
change.

I take issue with your comment about being afraid of loosing goodwill.
If you know your Joomla and Mambo history, we've had good
relationships with a lot of 3rd party library providers, DOMIT and
InputFilter to name a few. I had good relationships personally with
both those developers and they were thrilled to work in with us while
they were active. We regularly access the relationship with people
(because, after all, communities are about relationships) and you'll
know that we've sought other options when these developer's have moved
on (as both have done). Should Mootools become poorly supported, then
I would be making a call on using a different framework for my own
stuff and Joomla would be wise to make the same assessment. Should
jQuery fall in a heap, we are unaffected. It's the circle of software
life. We work with people while they are active, and when they
aren't, we find the best alternatives that meet the greater needs of
the project.

As I already stated, we will make an effort to allow people to use
their JS framework of choice, but the bottom line is Joomla core will
use Mootools when it needs it and 3rd parties will have to take that
into account.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/6/10 Stian Didriksen <st...@ninjatheme.com>:

[dukeofgaming]

There is a way of working with JQuery, it is in the "Learning Joomla! Extension Development" book: http://www.designvsdevelop.com/using-mootools-and-jquery-together-in-joomla/

Stian, FYI Mootools needs to load first for the noConflict() mode to work. Really, what about the mootools developers then?, just ignore them?. jQuery can already work along with mootools, so what is the *bleepy* problem? =P.

I beg to differ from your opinion that "Relationships between you and Mootools devs is completely irrelevant"; taking the decision of using a framework for your own framework is a biiiiiiiig maintenance risk, since the authors of the integrated framework can and will take decisions that will affect you, and affect you bad if there is no friendly relatioship, the other guys can just not care they are breaking your own framework... on the other side, things can be worked out.

I don't intend to open wounds but if this have been true for Joomla! and SMF, SMF would still support some kind of integration for Joomla!, things were not worked out nicely and a lot of people, including me, got affected being stuck for a long time with Joomla 1.0.x. Although, thank god this happened since this issue contributed to the origin of the great JFusion framework.

Regarding Mootools version shenanigans... are there any plans for adopting Mootools 2.0?, I know its not out yet but, wouldn't like Joomla to stay 1 version of Mootools behind for a long while again. Following my paranoia protocol, I just got an answer from Aaron at tweeter regarding Mootools 1.2 -> 2.0 compatibility:

MT 2.0 will have a compat layer included by default. Some internal features will change, but 99% of plugins should still work.

So, can we expect Mootools 2.0 along J! 1.6.x? (depending on the date of release of course).

[Ron Severdia]

Also, we're not at the development juncture assumed at the start of
this thread. The latest version of Mootools is ALREADY in the 1.6
alpha trunk so, technically speaking, we're past the point of re-
evaluating JS frameworks. So it's pretty much a moot point.

[Amy Stephen]

Stian -

Relationships *do* matter and if we want the support of other people to help our community, then recognizing that will help you with your next gig.

You are apparently recognizing this is a moot point in terms of what we are able to accomplish. Work with the others of us who want to explore Joomla! and jQuery to show that it's an amazing solution. In the end, the proof is in the pudding, eh?

(The "eh" was for our Canadian community, in case they are trying to follow along.)

Honestly, we have so many options, it's tough to even have enough time to research them.

Let's make sure that our relationships stay healthy, here, too. It's okay to say your piece here.
Amy :)

[Rey Bango]

Hi Andrew,

I'm part of the jQuery Project team. I just wanted to say that if the
Joomla team wanted to include the jQuery library so that your
community could benefit from it, we'd be very open to discussing how
the two teams could collaborate on this.

Rey Bango
jQuery Team

On 9 June, 17:17, Andrew Eddie <mambob...@gmail.com> wrote:
> With respect this is a bit like splitting hairs over the Drupal vs
> Joomla debate.  Both are stunning, both have supportive and different
> communities with strengths and weaknesses.
>
> We have had good connections with the Mootools creators and experts so
> far.  We don't have that relationship with the jQuery community (note
> the lowercase 'j'; JQuery is our new database query class <cough>) as
> far as I know.  I don't see any particularly good reasons to sever
> that goodwill where there is honestly no better argument than personal
> preference.  That might change in the future, but right now it does
> what it needs to in the backend and the frontend is being made as
> agnostic as possible.
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/6/10 Amy Stephen <amystep...@gmail.com>:

[Stian Didriksen]

I agree that relationships do matter, but the relationship the rest of
us got with Mootools,
should matter more than core devs and Moo devs being buddies.

I'm more than willing to work with others who wants to show off how
awesome Joomla would be powered by jQuery.
I honestly didn't know I where in company.

I'm not trying to offend anyone here, especially not Andrew as got
great respect for him.
I may sound harsh, but that's just me being clear ;)

Regards,
Stian Didriksen

[Omar Ramos]

I think in any case, one of the earlier posts is pretty accurate in saying that not-so-advanced developers could benefit greatly from additional AJAX+Joomla Specific Tutorials using a number of different Frameworks, but especially Mootools related ones like the one Laurens put together that Amy linked to.

Maybe some AJAX-related Core HTML Behaviors would be useful in making it easier for people to use Mootools with Joomla?

I think one of the things that Mootools lacks is in the lack of a centralized plugin repository, and also useful "grids" that people tend to want to use (I'm just familiar with what I've seen on the ExtJS site: http://extjs.com/deploy/dev/examples/samples.html#sample-1) which lends itself to developers having to work harder to bring that functionality into their Joomla project unless they resort to another framework that already has that type of functionality built-in.

Maybe there is a way that the Joomla community can "bootstrap" the Mootools community some of the features (such as the JED) that have made the Joomla project so successful?

-Omar

[Amy Stephen]

Rey -

I do think some of the third party devs, here, like myself, will want
to begin working with the jQuery community.

Ron Severdia's point is right - Mootools has been upgraded for 1.6 -
we are a couple of weeks from Alpha, in hindsight, some of those
*factoids* would have been good ones to think on. Even Beat sees that
this was a bit crazy, given where we are at in the project life cycle.

HOWEVER, let's all think about how we can work together for 1.5 and
1.6 to show some of the very cool stuff that's out there for the
pickin today. Maybe in a few weeks, or so, we should brainstorm those
ideas on where to go from here.

You must have eyes like a hawk! ;-) Thanks for noticing us and thank
you for your willingness to work with your community. As you can see,
there is some interest here. I'm going to use jQuery in this next
project. And, I'll share some of my experiences, good and bad, with
others. I hope people do the same.

Omar's points are good ones, too. If there are ways to help Mootools
revitalize - I'm all for it. I know that project has struggled keeping
forums open and getting people to join in and help with support.
Lately, I have noticed renewed passion trying to reconnect with their
community and make things happen. The truth is, it is going to be an
uphill battle for Mootools to catch up, again, and in the end, it's
about building functional sites people want to use and that means
making available widgets and other tools that are easy to use. (Omar -
yes, Ext JS is pretty cool.) Anyway, I do hope to see Mootools back at
it.

Amy :)

On 9 June, 18:44, Rey Bango <reyba...@gmail.com> wrote:
> Hi Andrew,
>
> I'm part of the jQuery Project team. I just wanted to say that if the
> Joomla team wanted to include the jQuery library so that your
> community could benefit from it, we'd be very open to discussing how
> the two teams could collaborate on this.
>
> Rey Bango
> jQuery Team
>
> On 9 June, 17:17, Andrew Eddie <mambob...@gmail.com> wrote:
>
> > With respect this is a bit like splitting hairs over the Drupal vs
> > Joomla debate.  Both are stunning, both have supportive and different
> > communities with strengths and weaknesses.
>
> > We have had good connections with the Mootools creators and experts so
> > far.  We don't have that relationship with the jQuery community (note
> > the lowercase 'j'; JQuery is our new database query class <cough>) as
> > far as I know.  I don't see any particularly good reasons to sever
> > that goodwill where there is honestly no better argument than personal
> > preference.  That might change in the future, but right now it does
> > what it needs to in the backend and the frontend is being made as
> > agnostic as possible.
>
> > Regards,

> > Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer

[Amy Stephen]

On Tue, Jun 9, 2009 at 5:46 PM, dukeofgaming <dukeof...@gmail.com> wrote:

Although, thank god this happened since this issue contributed to the origin of the great JFusion framework.

Amen to that!

[John Resig]

Hi Everyone -

I'm John Resig, the creator and lead developer of jQuery. I just
wanted to jump in and answer any questions that may have come up.

I can't speak to the use of MooTools or your current, working,
relationship with the MooTools project but I wanted to bring up some
points concerning how we run the jQuery project.

- The jQuery API is stable. We take great pride in the stability of
our API. Every major release that we've had (1.1, 1.2, 1.3) has
offered complete backwards compatibility for our users. This includes
full documentation, upgrade information, and compatibility plugins. As
it stands the number of API changes that we've been making is greatly
diminishing - our API is quite stable at this point.

- Release synchronization. We are very experienced in working with a
number of large projects and companies, synchronizing on release
schedules. Right now we actively work with large projects and
companies like Google, Microsoft, Nokia, Wordpress, and Drupal on
every release (along with the many other developers who use jQuery) to
make sure things go smoothly. You can feel safe knowing that any
release will take concerns from the Joomla! project very seriously and
will be handled quickly.

- Bug triage. For our larger users (some of which were mentioned
previously) we provide bug triaging for any issues that may arise.
Since the Joomla! project would be an important part of that we would
handle all tickets with a top priority.

- Foundation. The jQuery project is the process of becoming a
foundation - established around jQuery and its sub-projects (jQuery
UI, QUnit, etc.). This will mean that the jQuery project is going to
be around for a very long time to come - the source code and the
licensing won't be under the control of a single person, you can feel
safe knowing that the code that you're using will be here for quite
some time.

- Large developer community. The importance of this cannot be
understated - a large community means more people around to offer
support, submit tickets, write patches, commit, and ultimately
participate in the growth of the library. Currently we have around 1.5
million developers using jQuery on a month-by-month basis.

If you have questions regarding how it is to work with the jQuery team
I can certainly put you in contact with some developers and teams
who've had experience working with us.

--John

[Russell Winter]

OK folks, probably putting my ill-fated nose in where it might not be needed, nor technically astute enough to have an opinion, but.....

I have some custom applications within one of the environments I work in (It's a GEO type graphics Application)  and this application at installation time offers alterntive librries to use as default, including the opportunity to change this later through a configuration option.

Is this a possibiity?  Say, during installation there is a question, default to the J! Projeects default choice, but with an option to switch to an alternative.

In the Global Config there is also another option, where this can be changed later.

With my limited understanding of either of these two environments, I seem to be under the impression that the following is correct;

1.  MooTools 1.1 is beginning to be outdated and superceded
2. MooTools 1.2 is not backward compatible to MooTools 1.1
3. JQuery is compatible with both MooTools 1.1 and 1.2 in "compatibility mode"
4. JQuery is backwards compatible, currently with previous verisons.

Hence, the options at install "could" be;

Please Choose default your dynamic framework.

  * MooTools 1.2 (Default)
  * MooTools 1.1 (Superceded)
  * JQuery x.x
  * MooTools 1.2 and JQuery (Compatibility Mode)

I understand it is all too simple to write it down here, and that it involves a vast amount of background thought and work,  just a thought though.




Regards,

Russ Winter

2009/6/9 Beat <bea...@gmail.com>

[Israel Dacanay Canasa]

I've also been tweeting about this issue for quite some time now. And I'm very glad this discussion has been opened.

If ever the Joomla core would reevaluate their decision about Mootools vs JQuery. I'd vote for JQuery simply because as stated in the http://www.jqueryvsmootools.com/, Mootools is a JS Framework while JQuery is a Toolkit which allows you to get things done quickly. Most of the time, we don't need the power of Mootools even if it's actually more powerful and flexible. While developing Joomla extensions, Joomla's Framework is already enough to get your hands full. Coding simple animations and DOM manipulations in Mootools is a chore as heavy as Joomla Framework already. Why not use a lighter, get done quickly tool for JS and DOM?

Johan Janssens justified Mootools by saying "it's similar to how Joomla does things". The problem with this justification is the justification itself. If it's similar to Joomla, then you're doubling your workload.

JQuery as mentioned by others in this discussion is friendly to other JS Frameworks in its noConflict mode. So if ever Joomla uses JQuery by default, we can always include Mootools for advanced JS programming. But making Mootools as default causes conflicts if ever you need to use other JS Frameworks.

JQuery wins hands down!

Regards to everyone!

_________________________________________
Israel Dacanay Canasa
Wiz Media, Inc
http://www.wizmediateam.com

[Ron Severdia]

On Jun 9, 6:39 pm, Russell Winter <winte...@gmail.com> wrote:
> Is this a possibiity?  Say, during installation there is a question, default
> to the J! Projeects default choice, but with an option to switch to an
> alternative.
>
> In the Global Config there is also another option, where this can be changed
> later.
>

I personally think this is a great solution. I wouldn't bother with
the custom install option, but just add the libraries in the media
folder and add an extra bit of code to the JHTML class. So instead of:

JHTML::_('behavior.mootools');

...for Mootools in your templates, you could add:

JHTML::_('behavior.jquery');

...to load the jQuery library instead. It wouldn't change the Mootools
on the back-end, but that's not what people seem to be looking for. So
if people are happy with Mootools in the admin and the option based on
a class tag to load one or the otheron the front-end, that might be an
easy way to do it.

[Jonathan Lackey @zuno]

Are the only 2 things MooTools is required for in the Admin the
accordion menus for parameters and the Modal window (SqueezeBox)?

If so, is that enough reason to keep a full js framework in the admin?

[Israel Dacanay Canasa]

Finally, Joomla 3PDs are coming out and voicing their concern!

Joomla Core devs, I do hope you'll consider going back to the white paper for this one :).

_________________________________________
Israel Dacanay Canasa
Wiz Media, Inc
http://www.wizmediateam.com

[Andrew Eddie]

1.6 Backend will be progressively adding more and more JS features,
particularly the new access controls. Frontend comments, as already
mentioned, already relies on it as will any other AJAX work.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/6/10 Jonathan Lackey @zuno <webmo...@gmail.com>:

[Andrew Eddie]

This is an Open Source project. There is nothing stopping anyone from
doing the hard yards and working out compatibility
layers/mode/whatever. The community is the contributor to the code
(some individuals do more, some less). If you want to explore the
jQuery angle ... "just do it". Check out a copy of 1.6 and start
carving it up. Nobody is stopping anyone from anything.

As for me, I'll tool in Mootools because that's what's there (and it works).

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/6/10 Israel Dacanay Canasa <rae...@gmail.com>:

[Ron Severdia]

On Jun 9, 10:59 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> This is an Open Source project.  There is nothing stopping anyone from
> doing the hard yards and working out compatibility
> layers/mode/whatever.  The community is the contributor to the code
> (some individuals do more, some less).  If you want to explore the
> jQuery angle ... "just do it".  Check out a copy of 1.6 and start
> carving it up.  Nobody is stopping anyone from anything.
>

Well said. Maybe all the jQuery fans and the devs who have posted here
could get together and submit patches/files to accomplish this? Go
for it!

[Mark Simpson]

Hello all :)

Why is it a given that Joomla needs to use a js framework at all on
the frontend?

Why not use custom js (rather then a framework) for the contact form
validation and captions? Couldn't this be done in 1 - 4KB? I propose
the use of custom js and the ability to turn it off in the
Configuration panel.

Then all a user would have to do to have no core mootools at all on
the frontend is disable Comments.

Personally, I prefer jQuery (because i'm not a programmer/scripter and
jQuery is more friendly to cut-and-pasters like me) but even if it was
proven beyond a shadow of a doubt that jQuery was the better
framework, it still shouldn't be forced down a designers throat.

When I develop a website I normally go with whichever one the most
important extension uses. If the website uses JomSocial or Fireboard
(both which use jQuery), I want jQuery loading everywhere and Mootools
nowhere. I wish I didn't have to use a dirty workaround to achieve
this.

Whatever you decide, I'm glad we're having this conversation. I loved
Rob's response here: http://jxtended.com/news/14-company/208-joomla-qa-on-twitter-part-1.html

mark_up asks: Why are there (hundreds of thousands of?) websites out
there with 70KB of JavaScript just to show captions.. which are rarely
even used?
Rob Schley answers: Because the community didn’t object loudly enough
to make us reconsider that decision. We do the best we can. We don’t
always make the best decisions but we usually try to make the right
one. Sometimes people come along and ask if we considered X or Z or
whatever and sometimes the answer is no but unless that dialog
happens, the community might get stuck with whatever crazy idea we
came up with at 4:00 AM after drinking 9 cans of Redbull and not
sleeping for 2 days. This is why community involvement is important.

[Andrew Eddie]

As I mentioned before, layout overrides will be able to used for you
to override the default behaviours (we'll make sure everything
involved with the javascript framework is loaded from the layout). If
you want to create a set where you hand optimise all the JS on the
page to a minimum you have my complete blessing :)

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/6/10 Mark Simpson <ma...@niudigital.com>:

[Louis Landry]

What a fun distraction to read :-)

@Phil, your smugness doesn't help sell your point, it doesn't make you look smart either.

@John, thanks for the marketing look at your project.  It is certainly a more polished pitch than you sent Johan and I a couple of years ago :-) ... You guys have done great stuff with that project and it looks like the future is certainly bright for it.

@Israel, there are thousands of third party developers and that is just the people who publish extensions that are available.  That doesn't even begin to include the many thousands more that implement sites on a daily basis.  To think that this particular smattering of (up to this point) less than 20 people represents the third party developer community is I think going a bit too far out on the limb for my tastes.  Especially when two of those people are jQuery core devs.

@Stian,  I personally am in close contact with several Mootools core devs and they have been very helpful to me in a lot of ways.  We don't use Mootools because I or anyone else is friends with Valerio.  We use Mootools because it was the chosen framework and a better fit for Joomla when the choice was made.  I am friends with Valerio as a result of us using Mootools is probably a better characterization.

@zuno,  there are actually several JavaScript behaviors in the core that use Mootools in one capacity or another.  Look a little deeper.

1) I am all for a framework agnostic approach to the front-end of Joomla.  It shouldn't be that difficult to achieve and all of you people that are so excited about switching frameworks or unhappy about the current state should be discussing how to BEST provide a framework agnostic front-end to Joomla instead of going back and forth piling on me-to's which really don't carry any weight or merit.  We strive to have the JavaScript behaviors in the core be unobtrusive, which certainly serves to help be framework agnostic.

2) This is open source.  That means if you want something changed, do the work.  If your solution is better than the current one, then we have something to talk about.

Those of you who do want to put your proverbial money where your mouth is there are certainly some things that can be done to improve JavaScript handling in the Joomla core.  We have started work a Joomla namespace to hold some key things that are generic and useful to Joomla universally.  It would be great to get people looking into that and figuring out what needs to go there, the best and most efficient implementation of those things, and making sure that it is implemented effectively wherever it is needed in the core.  Having that base namespace sorted out would go a long way to providing the absolute bare minimum without needing any sort of framework for the front-end.

At the end of the day, taking the agnostic approach is going to confuse and frustrate users just as they are now with people not using the framework the core provides.  Some extensions will be written using only Mootools, some will be written using only jQuery ... others will be written using just Dojo or YUI or whatever other fancy framework comes up later this year because someone has an itch to scratch.  For end users who just want everything to work together, navigating all of those things is going to be tricky.  It is tricky now as well, but right now the core has chosen a framework.  It is the standard, and those developers who aren't using it (even if you have good reasons) are the cause for those end users being frustrated when they suffer interoperability problems.

It comes down to who we are designing the system for.  If we are building it for the site implementors (myself included), then being framework agnostic is great.  It means absolute maximum flexibility in how I implement my site and since I know what I am doing, I can make sure that whatever I ad to my site all works together.  If we are building it for the end users to just click and install extensions, then we are IMHO missing the mark.  Those people don't care if so-and-so loves jQuery or so-and-so loves Mootools or whatever else.  All they care about is that all the things they download and install work, and that they all work with the existing things in the Joomla core.

My suspicion is that while I am better served personally going framework agnostic (and am thrilled to be moving in that direction), we wont be doing any favors for the millions of people who just install Joomla to make a site work.

As of now Joomla uses Mootools as its JavaScript framework.  I do not see that changing in the very near future.  Mootools 1.2 has already been updated in the trunk, though I am certain improvements can be made.  That whole thing by the way took only a couple of hours to do.  The adjustment from Mootools 1.1 to 1.2+ from a syntax and compatibility standpoint is not even in the same ballpark as Mootools to jQuery.

I would suggest that those of you interested in making the jQuery thing happen should write a plugin for 1.5 to overload the JHtml calls and re-implement all the core JS behaviors to jQuery.  Get a feel for it.  Know what you are dealing with.  Stabilize it.  Make it better than what we have.  Show it working and then come to the table and you have a compelling case.  

Discussion == Good.

Action > Discussion.

- Louis

--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[Russell Winter]

Folks,

again and as ever, first state of play is to express my lack of in-depth technical knowledge of either Framework or ToolKit and to accuratly describe my sentiment in joining this discussion. 

I have always found that Core Team and Dev Team have been more than willing to listen and "have always" made decisions based on thourogh and deterministic reasoning.  My purpose in joining this discussion was not to fire up the JQuery vs. MooTools arguments, but to further explore what either, or both actually mean to the Community at large and the developers.

We, as more involved users of Joomla! (and I am as quilty of this as anyone else) often forget that there are actually many many more "Community" users out there, than there are (for want of a better word) "Serious" users, this I beleive must be the core of many choices made, and as far as I see, is the core of many choices made, no matter how unfavourable or contraversial they may be.

I guess, like all things in life, there are three sides to all stories,  one persons, the other person and somewhere in the middle......   as Andrew has stated, at this current time and dependant on currently unknown future developments within the Moo or JQ projects (or other new developments), J! 1.6 had to make a choice and has chosen to head in the MooTools 1.2 direction, specifically for reasons of compatibility with the J! framework, which makes absolutely perfect sense at the end of the day.  

These sort of choices or decisions will always offer alternatives and will always spark ongoing discussion, but regardless of Open Source, Commercial and Community interaction, at one point or another, someone has to make a decision, otherwise things dont progress.  This is one of the things I have always liked about the J! Core and Dev Teams, their willingness to make decisions, move on and more importantly, stand by their choices. As far as I can see, this shows, not only great character in the individuals, but also a willingness by these indivuals to "do the right thing" by the greater community (think back to those many users who have no idea what MooTools or JQuery are, except for they do cute stuff).   Of which, in this case, to be honest, I would guess wouldn't actually know or care which choice was made, as long as it works as advertised. 

I think at these sort of "cross-roads",  what we all have to remember (as quoted by many from a single-sided view-point) is that this is a Community based, Open Source Project, which is correct, but also not only means that there is Community Input, but also ensures an undertaking from those involved to actually deliver, what is promised to that same Community.   From my perspective, correct me if I am wrong, but I beleive that this is what Andrew and many others are trying to offer as some of their unwaivering reasoning and choice to continue with MooTools;   - a commitment to the community as a whole to deliver on their promise of J! 1.6,  which is not only admirable, but correct in their approach for the success of the J! 1.6 project.

The Framework and API offers plenty of scope to enhance or add to, the J! framework as has been proven by many many exceptional MooTools, JQuery extension developers in the past.

So, in summary, as to whether JQuery or MooTools..??  Wrong or right??   Well, I guess what I am saying is that the "larger" Community needs is what is being considered and served here;   - hence, MooTools being the choice this far down the line.  


Regards,

Russ Winter

2009/6/10 Louis Landry <louis....@joomla.org>

[sascha]

Hi all,

just want to throw in our thoughts at YOOtheme on this topic.

1.) It is right that Mootools 1.1 scripts may not be compatible with
1.2 scripts but saying that this is a good chance to replace Mootools
with jQuery is totally misjudged.
It is a major difference between modifying existing Mootools 1.1
scripts for 1.2 or re-writing the whole JS for another Framework like
jQuery.
IMHO the JS framework should not be changed for minor versions like
1.6, 1.7 etc. It should only be changed for major versions like Joomla
2.0. Otherwise a lot of people could be alienated.

2.) Personally we would prefer Mootools. Like said in the
"jqueryvsmootools" article "jQuery focuses on expressiveness, quick
and easy coding, and the DOM while Mootools focuses on extension,
inheritance, legibility, reuse, and maintainability".
Mootools offers a lot of design patterns especially for object
oriented programming. We would not change a great framework just
because another one has a faster growing community. So Mootools would
be our choice.

3.) As Louis pointed out Joomla offers the possibility to overload the
JHtml calls. So it is possible to implement everything based on
jQuery. That's great for everyone who wants to use jQuery.

Just our thoughts on this...

Cheers,
Sascha

On Jun 10, 11:42 am, Russell Winter <winte...@gmail.com> wrote:
> Folks,
>
> again and as ever, first state of play is to express my lack of in-depth
> technical knowledge of either Framework or ToolKit and to accuratly describe
> my sentiment in joining this discussion.
>
> I have always found that Core Team and Dev Team have been more than willing
> to listen and "have always" made decisions based on thourogh and
> deterministic reasoning.  My purpose in joining this discussion was not to
> fire up the JQuery vs. MooTools arguments, but to further explore what

> either, or both actually mean to the *Community* at large and the

> developers.
>
> We, as more involved users of Joomla! (and I am as quilty of this as anyone
> else) often forget that there are actually many many more "Community" users
> out there, than there are (for want of a better word) "Serious" users, this
> I beleive must be the core of many choices made, and as far as I see,

> *is*the core of many choices made, no matter how unfavourable or

> contraversial
> they may be.
>
> I guess, like all things in life, there are three sides to all stories,  one
> persons, the other person and somewhere in the middle......   as Andrew has
> stated, at this current time and dependant on currently unknown future
> developments within the Moo or JQ projects (or other new developments), J!
> 1.6 had to make a choice and has chosen to head in the MooTools 1.2
> direction, specifically for reasons of compatibility with the J! framework,
> which makes absolutely perfect sense at the end of the day.
>
> These sort of choices or decisions will always offer alternatives and will
> always spark ongoing discussion, but regardless of Open Source, Commercial

> and Community interaction, at one point or another, someone *has to make a
> decision*, otherwise things dont progress.  This is one of the things I have

> always liked about the J! Core and Dev Teams, their willingness to make
> decisions, move on and more importantly, stand by their choices. As far as I
> can see, this shows, not only great character in the individuals, but also a
> willingness by these indivuals to "do the right thing" by the greater

> community *(think back to those many users who have no idea what MooTools or
> JQuery are, except for they do cute stuff)*.   Of which, in this case, to be

> honest, I would guess wouldn't actually know or care which choice was made,
> as long as it works as advertised.
>

> I think at these sort of "cross-roads",  what we all have to remember *(as
> quoted by many from a single-sided view-point)* is that this is a Community

> based, Open Source Project, which is correct, but also not only means that
> there is Community Input, but also ensures an undertaking from those
> involved to actually deliver, what is promised to that same Community.
> From my perspective, correct me if I am wrong, but I beleive that this is
> what Andrew and many others are trying to offer as some of their unwaivering
> reasoning and choice to continue with MooTools;   - a commitment to the
> community as a whole to deliver on their promise of J! 1.6,  which is not
> only admirable, but correct in their approach for the success of the J! 1.6
> project.
>
> The Framework and API offers plenty of scope to enhance or add to, the J!
> framework as has been proven by many many exceptional MooTools, JQuery
> extension developers in the past.
>
> So, in summary, as to whether JQuery or MooTools..??  Wrong or right??
> Well, I guess what I am saying is that the "larger" Community needs is what
> is being considered and served here;   - hence, MooTools being the choice
> this far down the line.
>
> Regards,
>
> Russ Winter
>

> 2009/6/10 Louis Landry <louis.lan...@joomla.org>

> > On Wed, Jun 10, 2009 at 12:59 AM, Andrew Eddie <mambob...@gmail.com>wrote:
>
> >> This is an Open Source project.  There is nothing stopping anyone from
> >> doing the hard yards and working out compatibility
> >> layers/mode/whatever.  The community is the contributor to the code
> >> (some individuals do more, some less).  If you want to explore the
> >> jQuery angle ... "just do it".  Check out a copy of 1.6 and start
> >> carving it up.  Nobody is stopping anyone from anything.
>
> >> As for me, I'll tool in Mootools because that's what's there (and it
> >> works).
>
> >> Regards,
> >> Andrew Eddie

> >>http://www.theartofjoomla.com- the art of becoming a Joomla developer

>
> >> 2009/6/10 Israel Dacanay Canasa <rae...@gmail.com>:
>

> ...
>
> read more »

[Amy Stephen]

Just to summarize where we are at:

• There is no time to switch out Mootools for JQuery in the Administrator for 1.6. We are two weeks out from Alpha. We have our answer on that and the answer we have is reasonable.
  
• In 1.6 Frontend, Andrew clarified for us that there will be isolated Mootools in the Comment and Form Layouts. It should be easy to replace using Template Overrides by those of us who are motivated to do so.

In a free software community, motivated people make things happen and directions are guided by work that is produced. Think about the implications of this work coming out of 1.6:

• The Administrative components are being refactored into a MVC framework. That means, Template Overrides are going to be easier there, too - without hacking core.
  
• Andy's GSoC project will focus on improving the Administrator HTML to be semantic and accessible.

That work will make it easier for those motivated to redesign the Administrative area -- customize it, even, for their own needs. Again, if the JS is isolated to Layouts, swapping out Mootools will be easier. Right now, most people do not touch the Administrator. Such will not be the case after the refactoring.

If you have not look at the Ajax/JS market in a few months, then take a few hours to look, now. There is an explosion of highly functional, easy to use, Ajax-type toolkits hitting the market right now. It was shocking for me to see what had happened since I last looked. JQuery wasn't an automatic choice for me - I struggled with that decision because of the other toolkits available Ext JS, DHTMLx, Dojo, Flex or Spry, as a short list of examples we can choose from.

I decided on JQuery because of the momentum that community has built. The same openness and opportunities to participate is there, like it is in our project. I am very impressed by the support and involvement of designers (click the links of those people - look at their experiences, their education, their writings) in this project and for their commitment to UI and UX.

This next wave of our industry will be focus on UI/UX and Rich Internet Applications coupled with producing and consuming Web services. My gut feel is the JQuery project has amassed the most involvement of talent in the area of design and that we will see that level of participation continue to increase as this phase of technology starts to mainstream. That means their work will multiply. Things look good there, and getting better.

Now, again, Mootools is going to be in 1.6. For those of us who want to use some of these other tools - and I am quite certain JQuery will not ever be "the one" for us - then, we have a path forward and the monkey is on our back. We get to put our money where our mouth is.

And, I thank our core developers for years of strategy that has ensured the core does not present barriers to choice. The CMSs that end up going the distance are ones architected like Joomla! where no one is backed into a corner, options are open, people can freely develop solutions for whatever purpose they see fit, and more and more solutions developers are encouraged to participate, thus strengthening that offering, as well.

I am very proud of our community and of each of you who have enough interest in our project to advocate your position. It is so nice to see how much we all care.

[Stian Didriksen]

Well, after al I must say in my experience Joomla has been the CMS that's the easiest one to use a different js framework than the core.

I've tried in both Drupal and Wordpress to use alternate frameworks, and it's no easy task I tell you.

But it would be very nice if we could get perhaps a new constant we could check to see if Mootools has been called. 

That wouldlet us optimize for example jQuery in enviroments where Mootools isn't present, or better yet, load Mootools versions of our scripts when Mootools are already called.

This is perhaps most useful for templates that wish to perform the best, and want to avoid two frameworks loading.

By doing that we gain the ability to stay 100% compatible with Joomla core extensions and scripts, as well as other 3rd party extensions that expect Mootools 1.1 to be in use.

I would like to hear everyones thoughts on this suggestion.

Regards,

Stian Didriksen

[G. D. Speer]

I am quite pleased and honored to see John and Rey joining this thread.
Thank you both for your interest and expressions of support.

Given that Mootools 1.2 is now in the trunk, is it practical to consider
actively managing the loading sequence and graceful setting of compatibility
mode
for jQuery via an enhancement of the Behavior settings or should we leave
this
to extension developers (and user hacks)?
Duke

--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.59/2165 - Release Date: 06/09/09
05:53:00

[G. D. Speer]

I personally love this idea.
For the good of the community, I'm concerned about going agnostic on the
front end.
I find that from this discussion, the most compelling reason to go with and
stay with Mootools 1.2
is to have a non-waving stake in the ground for third party devs to know
that extensions built
via Mootools will likely play well with core and each other, and that
extensions built with
anything else, be forewarned that they have to manage the compatibility
issue that results
from their decision and that there will likely be support issues if they do
not build in
compatibility mode and the user brings in other extensions that are Mootools
based.

My point, I feel we do need a stake in the ground - go as light and agnostic
as practical, but
neverthelless have an 'official' framework that compatibility is assured.

To that end, I would like to see any JS Framework dependency listed /
implemented as a filter in the JED!

Duke

----- Original Message -----
From: "Ron Severdia" <ron.se...@community.joomla.org>
To: "Joomla! CMS Development" <joomla-...@googlegroups.com>
Sent: Tuesday, June 09, 2009 11:40 PM
Subject: Re: Joomla 1.6 going incompatible Mootools 1.2 ? or jumping onto
jQuery 1.3 while it's anyways incompatible to joomla 1.5 mootools 1.1 ?

[Israel Dacanay Canasa]

No matter how good our reasons are for jQuery, it won't matter because as our beloved Core Devs say, who will do it?

The fact that Mootools doesn't play friendly with other JS Frameworks should be reason enough to choose jQuery with its noConflict() implementation. How can Joomla Frontend be agnostic when Mootools is shoved to our throats the moment you use it? Mootools is like a bully who goes shouting "hey that's my seat go away!", while jQuery goes, "ok here's your seat, i can manage to find another seat".

If someone has the time and willingness to work on the best way for jQuery work with Joomla, someone who's willing to lead, I'll back him/her up! I want to initiate it, but I don't have the resource of time.

Regards to everyone here :)

_________________________________________
Israel Dacanay Canasa
Wiz Media, Inc
http://www.wizmediateam.com

[dukeofgaming]

So what Russel said put me to think, about having the option of installing mootools or jQuery in different versions... even though he says he lacks technical astucity, he actually proposed the best solution for all problems in a way that can only be imagined having technical astucity =).

Now, I believe what he says can be done simply by decoupling mootools, and allowing N implementations of a same behavior take its place. There are two ways I can picture this happening:

1. The first is by simply using the bridge design pattern, decoupling abstraction from implementation so we could have the framework of choice. Generally ORMs or even nice Database classes are not attached to a single database: you can just choose your DBMS at an entry point and start working with the ORM not worrying about which DBMS you are using.
2. The second is by using the strategy design pattern, quoting wikipedia:
   
   
   In computer programming, the strategy pattern (also known as the policy pattern) is a particular software design pattern, whereby algorithms can be selected at runtime.
   
   The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them.
   
   
   This second solution would allow working with more than one framework at a time (although most probable not in a concurrent fashion), and NOT simply by selecting one framework of choice in Joomla's control panel. In this case its not as straight forward as just applying the pattern, but requires further implementation and design work (for example, "automatic" decission of what library to use), not really that much hard.
   

So its not impossible, really, to allow more than one framework to be used even at the backend. Doing stuff this way would allow just leaving the sockets or placeholders open for different implementations of the same thing and the joomla team would only need to support the mootools implementation while experts in each framework figure out the others. The only problem here is conflict of the libraries at runtime, not conflict framework-wide; if a rendered page does not use mootools at all, why wouldn't one should be able to use ANY other framework, not just jQuery.

Furthermore, with enough coordination everyone can work in what they do best: the joomla team can work on the joomla framework (decoupling and redesign), jQuery enthusiasts and experts can work on the jQuery implementations, and open the doors to Dojo developers, and others... because I assure you, some time later this very discussion will be held again by another party in the future.

Trying to put an example -again- with the JFusion framework, just putting some thought to the problem of universal user integration and synchronization they managed to put the rules to allow any software to be integrated into Joomla!, have you taken a look to the slave/master behavior?, it is quite a remarkable achievement, why would it be that much difficult for javascript?, it boils down to something like this:

If I need mootools tabs, I shal have mootools tabs, If otherwise I need jQuery tabs, I shall have them, same for Dojo, as long as these tabs' implementation is available.

As a developer I'm still worried at the same level for the backend, I bet others are too but are too shy =P.

So what say you?

[Amy Stephen]

I'm calling foul, Israel, and blowing the whistle on that response. ;-)

Seriously, please rephrase and rephrase and rephrase until your message is crystal clear and not diminished by any accusatory or inflammatory shadings.

If we can learn to engage in strategic discussions and keep things at that level, can you imagine what kind of solutions will come out of this community?

Thanks for considering.
Amy

[Compass]

I might suggest (unscientifically) that many 3rd party extensions
prefer to use jquery. That's been my sense anecdotally.

This is also of interest:
http://search.twitter.com/search?max_id=2104761458&page=2&q=mootools+jquery+joomla

I actually think there *is* a compelling argument that most devs would
like the front-end agnostic.

Barrie North

[happy_noodle_boy]

I would recommend creating a behaviour for JQuery and including it in
the core. Mootools 1.2 can remain as the default library for all core
js stuff, but managing the loading of Mootools and JQuery will help
extension developers and prevent compatability issues.

function jquery($debug = null)
{
static $jquery;

// Only load once
if ($jquery) {
return;
}

// If no debugging value is set, use the configuration setting
if ($debug === null) {
$config = &JFactory::getConfig();
$debug = $config->getValue('config.debug');
}

// TODO NOTE: Here we are checking for Konqueror - If they fix thier
issue with compressed, we will need to update this
$konkcheck = isset($_SERVER['HTTP_USER_AGENT']) ? strpos(strtolower
($_SERVER['HTTP_USER_AGENT']), "konqueror") : null;

if ($debug || $konkcheck) {
JHTML::script('jquery-uncompressed.js', 'media/system/js/', false);
} else {
JHTML::script('jquery.js', 'media/system/js/', false);
}

$document =& JFactory::getDocument();
$noconflict = 'jQuery.noConflict();';
$document->addScriptDeclaration($noconflict);

$jquery = true;
return;

[Israel Dacanay Canasa]

I am so sorry if my illustration was a bit offensive. Saying that mootools isn't friendly with other JS Frameworks when used side by side should have been enough. But I can't think of any other illustration to emphasize that point. Let me try again: Mootools is like a Windows PC, you can't run OS X on it, while jQuery is like a Mac, it has BootCamp just like how jQuery has noConflict().

jQuery allows a truly agnostic frontend :).

_________________________________________
Israel Dacanay Canasa
Wiz Media, Inc
http://www.wizmediateam.com

[dukeofgaming]

<offtopic>
Israel, just FTR you could install Mac OS X in a "Windows PC" even before you could install Windows on a Mac ;), I did it with the first leaked Mac OS X x86 version!. PC and Mac hardware is identical, and here is the fresh proof http://www.hexus.net/content/item.php?item=18785 .

Sorry I got a little passionate. I actually came from the hardware world long before entering to the software one ;P.
</offtopic>

!!!!!!!!!!!!!!!!!
Well, before I continue I'd really like to have some feedback on my previous message and proposal for a universal solution!. That said, I continue.
!!!!!!!!!!!!!!!!!

Maybe having the wonderful noConflict() function is good at the short-term, but how about the long term?... I just cannot imagine having a JHTMLBehavior::jsframeworkxyz() function for each js framework people want to use. This shouts for a design solution IMHO.

BTW, I feel jQuery being shoved down MY throat at this point, I like mootools and I want Joomla to stay with mootools... but here I am investing valuable time trying to contribute to a solution for us all... so why don't we get past the point of "changing the framework" and go towards the "allowing other frameworks to get along inside joomla".

I mean, frameworks are tools, there is no single tool for all jobs... so, mootools is a drill hammer and jQuery is an automatic variable-speed battery-powered ultra-shiny chromed designer fashion drill... and you want the drill because you don't like being shaken by the hammer drill, also arguing your drill is more pretty... okay, we agree!... its pretty and nice to handle and popular!, but some of us still need a hammer drill to get through hard concrete.

Trying to measure where we are, it has already been said J! 1.6 won't have jQuery as the default framework. Another thing, as I said, we need to work on a solution for the long term, not only for jQuery... I mean, what about the Prototype + scriptaculous community?, what about the dojo one?.

I think there is more at stake here than just the jQuery & mootools communities, specially since more and more is being done with javascript as a whole.

[Lobos]

I would like to humbly submit ExtCore as a possible candidate for
inclusion. It is quite a remarkable library and boasts the backing of
a large community.

http://extjs.com/products/extcore/

The actual Extjs library it's self is light years ahead of anything
else in regards to JS UI development and I feel this could have a
place as well, especially in regards to backend admin UI development.
I have already made such integrations in Joomla and it is a hell of a
lot easier to work with than what is there now.

Regards

[G. D. Speer]

Nice!

- Keeps Mootools where it needs to be - the front end default that enables
core features.

- Allows a managed dual framework solution for those extensions that also
need jQuery without each dev coming up with a different approach for their
extension, which might trip over each other if multiple jQuery extensions
are on a page.

- Ensures proper load sequencing for front end pages.

- Sets an example/precedent for how to accomodate other JS frameworks in
future versions if there is enough traction to have them managed in core.

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - www.avg.com

Version: 8.5.339 / Virus Database: 270.12.61/2167 - Release Date: 06/10/09
05:52:00

[Stian Didriksen]

You got some very interesting thoughts, and some of them are thoughts I've had myself when thinking about this.

If we made a new JHTMLBehavior function, replacing the Mootools function, allowing you to choose your own framework with Mootools as the default fallback the problem solved.

It could simply check if any script that don't have, say a jquery version of it available, fall back to Mootools.

But instead of adding more work on the core devs shoulders I will rather try on my own to see what I come up with, and submit a feature patch if something useful comes out of it.

Regards,

Stian Didriksen

[SIMBunch]

From a dev point of view:
Whatever path Joomla 1.6 takes, I don't think there should be legacy
support for Mootools 1.11. This is one of those painful things that
should be short rather than long (ie provide legacy support) because
in the real world, Mootools 1.11 is already dead (more or less).
Providing legacy support for Mootools 1.11 (especially if templates
continue to use Mootools 1.11) will cause a lot of problems for
scripts that use Mootools 1.2, and we know that almost the entire
world (sans the Joomla-sphere today) has already moved on to 1.2.

To be honest, if this is strictly between MT and jQ, i think joomla
should adopt MT simply because devs can easily invoke jQ with
noConflict, while there is no such option for MT. If Joomla uses jQ,
it has to invoke it with noConflict by default (and template designers
MUST take heed never to override this). Outside of this, i don't think
it really matters what joomla uses.

[dukeofgaming]

See?, wow... It is already happening, haha. Thanks a lot for making my point so soon! =P, I didn't even know of this framework myself.

So this is, as you can see now a matter of diversity. His request is 100% as valid as the jQuery request. Don't panic Amy =P.

Thanks for the feedback Stian, and that is exactly my point... even while communities are the backbone of any open source project we cannot keep treating core devs as if they were Santa Claus, lets help them help us instead. And yes, well put, and I'm glad I could make myself clear, its all about allowing a dynamical fallback to the compatible implementation.

One thing that I consider important here, lets try treating both backend and frontend the same, otherwise the solution is being based on running away from where mootools is... I remind you we have some front-end administration functionality coming our way, do you seriously think they didn't use mootools?, there are lots of implications of just wanting to cram in features!, as it has been said.

The migration work towards Mootools 1.2 has already been done (it is in the wiki, I don't remember where exactly), so no, Mootools 1.1 won't be supported anymore. SIMBunch has a point too... jQuery guys can still work on their stuff meanwhile, so its not as urgent as it might have been depicted.

As I see it, this is now a matter of engineering, not monkeypatching, I mean, think of the maintenance burden to the core team, so I for one am utter and totally against the JHTMLBehavior::jquery() proposal.

[Steven Pignataro]

Hum - this is very much an interesting read - although I think that a
lot of things need to be put into account. Let me explain the
viewpoint from many different aspects of why I foresee Joomla!
benefiting from jQuery rather then mootools.

1: Size and speed. Mootools is notably slower then jQuery. We all know
this and recognize that the package is considerable in size.
2: License - from a licensing standpoint jQuery is dual licensed under
GPL and MIT while mootools is only MIT. It only seems logical to keep
packages under the GPL licenses since that seems to be over the past
year the strong tactic of Joomla!
3: Community - frankly this has been brought up a few times and there
is no hold on this - who has the largest community. I am putting it
here as a line item because some feel strongly and some don't but it
would be something to consider on a very light basis.
4: Documentation: It is widely known that the documentation from
mootools is not as extensive as jQuery. I have had many times where
people request to get mootools support because they can not understand
the package. While this is good for business - this is not good for
the developers who have to contract out other development companies.
5: Development: While the development mootools is popular you will
find far more companies supporting jQuery and developing within jQuery
6: Support: As said above - many companies do not support or develop
in the mootools environment due to the ease of use and tremendous
documentation for jQuery.
7: What is the voice of the community? I have read many post on how
people would rather see jQuery within the package rather then mootools
or have problems with it. So my suggestion is to ask the community.
We have setup a poll for this type of discussion to determine what is
the right route -> http://poll.fm/10cmp

I think this is a type of topic that should be heavily investigated
into and I think the above are questions that should be looked at
closely.

I thank you for your time and hope that some of this information has
been helpful.

Kindest regards,

--Steven Pignataro

[Stian Didriksen]

This might be a crazy idea, but we could take an approach on it the is similar to how localization works. 

So by default mootools prefixed js files would load, unless another *language* are called. So if a page loads multiple extensions all supporting both Mootools and jQuery/Ext/what-have-you and one extension only support Mootools,

only Mootools related scripts would load. 

Renaming JHTMLBehavior::mootools() to framework($library = 'mootools') is one way you could solve it.

Then all you would need to do is prefix your files accordingly for each library you support in your extension. 

And I agree with dukeofgaming, don't leave the backend out of this. J1.5 suffered enough from the absence of MVC coded extensions which resulted in almost no

3rd party backend templates. I think that the backend is actually more important than the frontend on the subject of javascript.

For one this is where most of the javascript do far more work than just adding eye-candy.

A great performing backend application rely heavily on how your code performs, and loading two frameworks, especially when you can't use tools we use on the frontend that compress, minifies and combine js files, is not benefitial.

Also, I'm sorry if I sound offending, but it's shortsighted to say "Mootools don't have noConflict mode, so it should be in the core". The reason the ones sharing my view say the exact opposite, is that we respect those who want neither Mootools or jQuery in their js toolbox. That's why jQuery is the better choice as it allows any other library you desire side by side with it.

But that's not an argument either, as ideally you should never load two frameworks at once. That's why I think this conditional script loader idea is the best solution as it's adaptable for any situation.

And I intend to prove it instead of trying to convince others to do the work for me.

I've already overloading JHTML in my current project, Ninja Showcase, for the backend as I make heavy use of jQuery UI to push what's possible in a module to show off what an powerful beast Joomla actually is, as an framework for web applications. Overloading JHTML works great, is clean and when done properly ensure compatibility with core scripts. However it's not scalable solution. 

Even though I've half way down the road of replacing every single method in JHTMLBehavior, once I'm finished I can't account for others overriding the same class. So I can't be 100% safe from some other plugin overloading the same method.

If this my idea became an reality, no one would ever have to overload JHTML to get a clean environment for their framework of choice. They would simply have to package core equivalent scripts to prevent Joomla from falling back to Mootools if an script is called that only exists in a Mootools version. 

I honestly can't find any cons to that method, other than it's a lot of short-term work, but long-term it would put an end to the discussions on what frameworks to use, and not to use. 

The Joomla project would also benefit from being the most js framework friendly there is, and all in all that would fit well with the "All together" ideology. 

In addition to that it would leave the maintance of the scripts that use another library than the core would be the developer who choose to use another framework's responsiblity.

Personally I don't restrict myself to code in solely Mootools or jQuery, because after all they are two frameworks not languages so it makes no sense to do that.

I would have coded in Mootools for the most part today, if it were not for the terrible mess with 1.5 being stuck on 1.1 and 1.2 breaking 1.1 scripts.

I disagree with the YOOtheme guys on some points though. It's not a matter of updating your scripts to Mootools 1.2, since as you say yourself it's not an difficult task at all. What is on the other hand is supporting both versions of Joomla during the time 1.5 are still being used by the majority of users. That's why we at NinjaForge came to conclusion on using jQuery at this time. While it's a lot of work converting your Mootools scripts to jQuery, it goes without saying maintaining duplicate scripts, one for each Moo, will bring you far more headaches. When thing the next version of Mootools comes out (don't recall if it's 1.3 or 2.0) and they don't do the same mess as 1.1 <-> 1.2, I think many developers, including me and the other ninjas, would start trusting the Mootools project again. And I sincerely hope we wont have to wait for Joomla 1.7 to arrive before can once again update our scripts so it complies with the latest version of Moo.

That's my final thoughts on the matter.

Regards,

Stian Didriksen

[Ron Severdia]

So that's a lot of talk. Who's going to write the jQuery plugin? :)

[Amy Stephen]

Steven -

I *loved* your list, dude, and completely agree with it, but, PLEASE take that poll down asking people what they want the project to do for 1.6. It's been said dozens of times now - we are two weeks from Alpha and there is no time to change our plans. Beat has made the point himself.

So, your poll is going to pit the voters against the project by asking them if they want something the project cannot give them. Not nice pitting a community against free software devs - esp when those devs have been working a long time on this release and are closing in on a release they are happy to share with their community.

Show good faith and take it down. If it stays up, I'm seriously done working with this. I will be no part of any group putting more pressure on this project.

What *we* can do as third party developers is create a plugin, template overrides, and documentation to share with one another and the community. Steven - if you create a Google Group for us as 3PDs to work together for that, drop the link in here. I'll be a part of helping with that.

Steven, said with respect.
Amy

[Antti Tuppurainen]

This is just example of "no hacks and overrides" in one of my latest templates:

I am using only two 3rd party modules/components:

TabsManager http://tools.gavick.com/demo/tabsmanager-gk3

 - sidenote: http://www.gavick.com/frequently-asked-questions/908-modules-faq/76-do-you-have-problem-with-scripts-of-our-modules-.html

Joomla Forms http://www.forms-for-joomla.com/ 

So examining the template output in frontpage:

Joomla Forms loads xajax to every page even there is no forms (Phil - why is this?)

TabsManager uses mootools and adds its scripts to top of the page

and then there is me that uses only jQuery with noConflict mode so I Load 

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>

<script type="text/javascript" src="/templates/fluidgrey/js/captify.js"></script>

<script type="text/javascript" src="/templates/fluidgrey/js/DD_roundies_0.0.2a-min.js"></script> This said: I think only Gavick is only who does thinks right? Or is this the reason of this discussion - we are not yet satisfied with the available options. There is lots of request to server as there is no global combiner and there is also a nice mixup of 3 different frameworks :) So the wish of me is 1) add a method to add somejavascript.library.js to combiner/minifier that is called after components, plugins and modules are loaded 2) add a method to add some functions to bottom of the page in "document.ready" 3) add a method to add somecss.css to combiner/minifier that is called after components, plugins and modules are loaded 4) add global configuration to switch of/on the need of some javascript library in template output 5) add options to load mootools/jquery from some CDN or from /media/js locally

--
Antti Tuppurainen
http://antti.tuppurainen.fi || http://www.mediawrox.com

[dukeofgaming]

GUYS!!, GUYS!!, I THINK I GOT IT!!...

BTW, nicely put Stian. Also I'd like to add that some conflicts can be avoided by using iframes.

!!!!!!!! Warning: This is going to get hardcore nerdy ;) !!!!!!!!!!!

More than a fallback it seems that you intend for the plugins to vote on the framework to use... more on, taking an objectual approach, sounds to me that this is the case (at least for the core implementations) for a singleton, and therefore a class... say JHTMLFramework?, then JHTMLBehavior and other implementations based on a javascript framework take from this abstract class, that has an abstract factory, that in the end calls for the chosen implementation.

Now, the key here is how JHTMLFramework works, and I think it should behave as a controller so we can "register" the JS implementations... so imagine we have these core classes:

           JMootools, JjQuery (heh), JExtCore, all extending JHTMLFramework

So when calling we can have something like this:

            $fw = &JHTMLFramework::getInstance();
            $fw->tooltip();

And these two lines are wrapped in the JHTMLBehavior->tooltip(); function, and then this behaves normally the same way when using JHTML::_('behavior.tooltip'); =)

Now, If I want to have my very own js framework implementations I extend these classes and register my own functions, and following Stian's idea, in prefixed files for each implementation:

//mootools.duke.js
class JDukeJS extends JMootools{
    public function __construct(){
        parent::__construct();
        $this->registerFunction('dukesSazzyFunction');
   }

   public function dukesSazzyFunction(){
       //Sazzy function here
   }
}


//jquery.duke.js
class JDukeJS extends JjQuery{
    public function __construct(){
        parent::__construct();
        $this->registerFunction('dukesSazzyFunction');
   }

   public function dukesSazzyFunction(){
       //Sazzy function here
   }
}



//extcore.duke.js
class JDukeJS extends JExtCore{
    public function __construct(){
        parent::__construct();
        $this->registerFunction('dukesSazzyFunction');
   }

   public function dukesSazzyFunction(){
       //Sazzy function here
   }
}


Finally, when I want to use my JS I do the same thing:

             $fw = &JHTMLFramework::getInstance();
             $fw->dukesSazzyFunction();

Ta-Da!, I just chose which js frameworks to support just by adding the files as Stian said, and there is no obligated framework to use. JHTMLFramework could add some exception handling so one can do this:

        try{
             $fw = &JHTMLFramework::getInstance();
             $fw->dukesSazzyFunction();
         }catch(Exception $e){
                JError::raiseWarning(0,JText::_('POOR_CHOICE_OF_FRAMEWORK_ERROR').$e->getMessage());
                //or a real solution to the framework's absence ;P
        }

The JHTMLFramework class would also deal with the component/module/plugin framework voting and therefore dynamically changing the JS implementation... using the strategy design pattern.

Finally, there is a risk having js dealt with this way, and its performance... sure we all add script declarations all the time, but it would be nice if we ALSO had some JS caching mechanism and/or minification... at least the way the solution is put it would be easy to handle.

What do u you think of this?

[G. D. Speer]

All good reasons to ALSO support jQuery in it's compatibility mode.

 

But this isn't either / or.  Mootools 1.2 is already in - the only question is to embrace jQuery for the front end as a co-loadable framework in a structured and organized manner or do nothing / leave it to each TPD to do this their own way.

 

I highly reccomend you take down the poll you put up - it would have been a great idea a few months ago but as written it now creates expectations that cannot necessarily be fulfilled.  I'm for having the jQuery option.  But the poll is asking for trouble / opening up to accusations that the community is being ignored.

 

 

 

----- Original Message -----

From: "Steven Pignataro" <spign...@gmail.com>

To: "Joomla! CMS Development" <joomla-...@googlegroups.com>

Sent: Wednesday, June 10, 2009 1:28 PM

Subject: Re: Joomla 1.6 going incompatible Mootools 1.2 ? or jumping onto jQuery 1.3 while it's anyways incompatible to joomla 1.5 mootools 1.1 ?

>

http://poll.fm/10cmp

No virus found in this incoming message.
Checked by AVG - www.avg.com

[Andrew Eddie]

2009/6/11 Steven Pignataro <spign...@gmail.com>:

>
> 7: What is the voice of the community? I have read many post on how
> people would rather see jQuery within the package rather then mootools
> or have problems with it. So my suggestion is  to ask the community.
> We have setup a poll for this type of discussion to determine what is
> the right route -> http://poll.fm/10cmp

Steven, with all due respect, forget about polls and channel your and
the community's effort into actually doing something productive.
Don't complain that it's not done. Just do it!

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Andrew Eddie]

@ALL

Can I suggest that the original question of Beat is now changing tack.
Would those interested in discussing an "other framework" solution
please do so with appropriately named topic threads (the title of this
one is far too long anyway, hehe).

I think we've really exhausted what we can achieve in this thread
without it becoming a further distraction to the main issue at hand
(1.6 Alpha). It's up to those wishing to see this happen put a few
hundred hours into actually seeing if it can work AND be beneficial to
the vanilla end user. Remember, Joomla's target audience is and has
always been the "end user" - they don't give a rip about whether your
extension uses Mootools, jQuery, whatever - ***just make sure it
doesn't break my site or other extensions***.

Good luck.

[dukeofgaming]

Ahem... can I get some feedback on my proposal or shall I start
another thread?

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

[Andrew Eddie]

Start another thread :)

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/6/11 dukeofgaming <dukeof...@gmail.com>:

[dukeofgaming]

This is done: http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/14d03121f36f9e4f

On Jun 10, 4:45 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> Start another thread :)
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>

> 2009/6/11 dukeofgaming <dukeofgam...@gmail.com>:

>
>
>
> > Ahem... can I get some feedback on my proposal or shall I start
> > another thread?
>
> > On Jun 10, 4:32 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> >> @ALL
>
> >> Can I suggest that the original question of Beat is now changing tack.
> >>  Would those interested in discussing an "other framework" solution
> >> please do so with appropriately named topic threads (the title of this
> >> one is far too long anyway, hehe).
>
> >> I think we've really exhausted what we can achieve in this thread
> >> without it becoming a further distraction to the main issue at hand
> >> (1.6 Alpha).  It's up to those wishing to see this happen put a few
> >> hundred hours into actually seeing if it can work AND be beneficial to
> >> the vanilla end user.  Remember, Joomla's target audience is and has
> >> always been the "end user" - they don't give a rip about whether your
> >> extension uses Mootools, jQuery, whatever - ***just make sure it
> >> doesn't break my site or other extensions***.
>
> >> Good luck.
>
> >> Regards,

> >> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer

[Valerio]

Hello,

I would like to cover up a few points that have appeared in this
discussion, and hopefully clear up some misconceptions.

1) MooTools 1.2.3 is coming next week (if there aren't any hiccups),
and it will no longer require noConflict mode to work with jQuery
(though any 3rd party plugins that use $ still will). We're basically
implementing our version of noConflict for MooTools. If MooTools
detects an already present function named $, it wont override it. If $
is overridden, MooTools will still properly function.

2) MooTools is not slower than jQuery; The current selector engine is
slightly slower than jQuery's by a marginal amount in some browsers.
If you are really interested in the various frameworks full DOM
performances, I suggest you to take a look at taskspeed.

3) MooTools and jQuery are essentially the same size (the full core of
MooTools is ~5k bigger), though MooTools provides way more
functionality. With MooTools you can do everything you can do with
jQuery, with jQuery you cannot possibly do all the things you can do
with MooTools. jQuery users will probably argue that they don't need
the extra functionalities, methods, or inheritance patterns. However,
that's how MooTools is built. With MooTools, if you personally don't
need one method, it doesn't mean you're not using it. Those MooTools
defined methods, classes and functions are used internally by every
other component, including the one that handles DOM stuff. This is
probably why MooTools provides way more methods and keeps a file size
that's very close to that of jQuery. To make a silly example of what I
mean, our Animation Classes are completely dom-independant. You can
either use those classes to animate dom elements (like 95% of the
users do) or you can extend / implement / use / whatever to animate
any other non-element item. Move the AIR Window. Animate a canvas
element. The fact that you do not need to move Adobe AIR windows or
animate a drawing pencil in canvas, doesnt mean you're not using those
portions of MooTools code that handle animations. To make another
example, you can get yourself a completely DOM-agnostic MooTools
build, therefore enabling its usage in Server-side environments, such
as Rhino/Spidermonkey. This is simply how we structure our code, with
a design pattern that favors flexibility and reusability. MooTools
choses to expose more functionalities for developers, while jQuery
keeps these mostly private. I'm not judging the design decisions, it's
just how things are. In the end, if you want to use MooTools as you
use jQuery ($ and dom methods) you definitely can, and you'll still be
using the majority of the MooTools codebase.

4) We are happy to address any issues the Joomla community encounters.
To that end, we're going to develop some tools that help plugin
developers identify deprecated MooTools methods and methodologies to
make upgrading code easier. Design decisions made for MooTools 1.2
precluded a 100% compatibility layer, however i can honestly say it
covers 95% of all the code. Some plugins may not require any changes
while others will. To help both types, we'll be authoring an upgrade
guide as well as a more developer-friendly 1.11 => 1.2x compatibility
layer that will log warnings to firebug when deprecated methods are
used. We'll work closely with the Joomla team to get this into the
community's hands as quickly as possible.

5) Future versions of MooTools will include a compatibility layer that
is 100% compatible with the documented features of previous versions.
It's worth noting that the upgrade path for 1.2.0 > 1.2.1 > 1.2.2 >
1.2.3 are all 100% compatible. This is a requirement going forward
that our compatibility layers provide coverage for all the documented
features of the library.

6) We greatly appreciate the support we've received from the Joomla
team and the Joomla community. Should you ever choose to go with
another framework (or none at all) we'll do what we can to support
your choice and community, just as we have thus far. We're not here
trying to sell anyone on using MooTools.


Valerio Proietti - MooTools lead developer

On Jun 11, 12:14 am, dukeofgaming <dukeofgam...@gmail.com> wrote:
> This is done:http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/14...

>
> On Jun 10, 4:45 pm, Andrew Eddie <mambob...@gmail.com> wrote:
>
>
>
> > Start another thread :)
>
> > Regards,

> > Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer
>
> > 2009/6/11 dukeofgaming <dukeofgam...@gmail.com>:
>
> > > Ahem... can I get some feedback on my proposal or shall I start
> > > another thread?
>
> > > On Jun 10, 4:32 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> > >> @ALL
>
> > >> Can I suggest that the original question of Beat is now changing tack.
> > >>  Would those interested in discussing an "other framework" solution
> > >> please do so with appropriately named topic threads (the title of this
> > >> one is far too long anyway, hehe).
>
> > >> I think we've really exhausted what we can achieve in this thread
> > >> without it becoming a further distraction to the main issue at hand
> > >> (1.6 Alpha).  It's up to those wishing to see this happen put a few
> > >> hundred hours into actually seeing if it can work AND be beneficial to
> > >> the vanilla end user.  Remember, Joomla's target audience is and has
> > >> always been the "end user" - they don't give a rip about whether your
> > >> extension uses Mootools, jQuery, whatever - ***just make sure it
> > >> doesn't break my site or other extensions***.
>
> > >> Good luck.
>
> > >> Regards,

> > >> Andrew Eddiehttp://www.theartofjoomla.com-theart of becoming a Joomla developer

[Andrew Eddie]

Hi Valerio.

Thanks so much for taking the time to respond. I really appreciated
and enjoyed your explanation :) Reminds me a lot of the thought
processes we go through with the PHP framework side of things.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/6/11 Valerio <kami...@gmail.com>:

[Beat]

Hi John,
Hi Rey,

Thanks for joining in this discussion, nice to see you here too :-) ,
and for your humble and generous offer to Joomla! , specially that
jQuery has gotten tremendous adoption and fame ;-)


Andrew,
Thanks for your call for contributions, my contribution proposal
(hands-on) is below: :-)


Andrew,
John,
Joomla! team,
all in here.

In Community Builder ( http://www.joomlapolis.com/ ) and core team CB
Plugins, we're using successfully jQuery and jQuery UI since CB 1.2
RC, and I can only confirm John's statements and recommend jQuery and
the jQuery team's dedication to stable APIs, while making jQuery
better and faster at each release. Our bug-reports have been handled
swiftly, and we could benefit from their regular releases at each new
CB release.

We have developed, debugged and refined for weeks a small PHP API for
non-conflicting, global JS name-space-neutral, and efficient use of
jQuery and jQuery plugins in CB using Joomla's headers generation
tool, and which to our totally amazed surprise, after an initial bug-
fix, generated *zero* conflicts (also with Mootools!) and zero bug
reports so far, despite being used on a very large number of different
sites.

Our API handles not only jQuery, but also any plugins, core and non-
core, as well as dependancies of plugins and associated CSS files
(templatable). We have also selected, tested and fixed (with reports
back to their author) 16 additional jQuery plugins that are also
included, in addition of jQuery UI. All those plugins are kept up to
date

Regarding extJS, it's an amazing system as well, which can run on top
of jQuery, and which, from what I saw, can be handled by the same CB
jQuery API.
We didn't use extJS yet, so can not comment on its API stability. The
extJS API is very different from jQuery.
However, jqueryUI has become quite mature and stable as well, is run
by the jQuery team, has a powerful jQuery-type of API and is way more
efficient than extJS for the tasks it can perform, so we preferred
using jqueryUI, which was fine for our needs. However extJS has more
and different functions.

That API is entirely written by CB Team and we would happily
contribute it to Joomla and to jQuery teams if there is interest, and
will continue maintaining it anyways for CB long term, as our APIs are
long-term backwards compatible.

This is in reply to Andrew's call for contributions. To be clear:
Joomla and jQuery are free to review, use, take, modify, adopt our
jQuery-CB/Joomla PHP API and concepts as needed, and we will try to
assist to our best. :-)

I will post this proposal into the new thread as well, as soon as time
permits:
http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/14d03121f36f9e4f?hl=en-GB

Best Regards,
Beat
CB development lead at http://www.joomlapolis.com/

[Beat]

Hi Valerio,

Great news indeed.

As a social-framework developer and as a Joomla! extensions developer,
my main concerns are:
- backwards and forward compatibility
- not conflicting with core Joomla and not conflicting with other
extensions residing on the main page.

So to read what you just wrote is indeed really good news.

If you remember, around 18 months back, I posted politely to your
forums regarding the fact that in CMSes like Joomla, javascript
libraries should be able to live together on the same page non-
conflicting, and that an extensions developer can't make choice by
himself of a single js-library, like a site designer can, as one of
your team members suggested to use a single-library in a thread.
Unfortunately, as my post got simply deleted 20 minutes later, I can
not give URL to it.

But that's old, now forgotten, story, and what counts is today: that
this problem gets well treated in Mootools too, and I'm really really
happy of what I read above (compatibility and no-conflict).

If you read my post which started this discussion, and the title of
this discussion, my only concern was lack of backwards-compatibility
to joomla 1.5 / mootools 1.1 (as jQuery already solved the conflct
issue) and thus the proposal to *keep* mootools 1.1 for joomla-1.5-
legacy support in Joomla 1.6.

So yes, your proposal to work further on the compatibility issues of
mootools 1.2, and to keep compatibility forward is really really great
news for the Joomla extensions developers. :)

Many thanks for your great work,

Best Regards,
Beat

[dukeofgaming]

Beat, could you please take a look to this thread?:

http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/14d03121f36f9e4f

Seems we might be pursuing the same goal: handling JS through a PHP API, although you already have some valuable experience with that.

[Stian Didriksen]

Hi Valerio,

With you guys changing stance like that, and even adding in a
noConflict for Mootools,
I gotta say that really changes things.

I feel I can finally trust Mootools again as a stable and safe choice
for writing my scripts.
Kudos for the people who made that possible, and respect!

Regards,
Stian Didriksen

[Israel Dacanay Canasa]

First, I'd like to state that I feel honored that the lead developers of both frameworks have joined this discussion and expressed their support for our community.

Valerio, adding an implementation noConflict reallly changes things. But I don't understand why Aaron Newton said Mootools can't do it inherently because of its design. http://twitter.com/anutron/status/2105801316. (Also, I'm sorry if I offended others by comparing mootools to a bully.)

The Mootools core devs are doing their part and that's great! Now what's lacking would be for Joomla to be truly JSFramework agnostic by allowing extensions using different JSFrameworks to work together seamlessly.

I think the best way to do this is to detach Mootools from the Core and just make it a CORE Plugin. This core plugin should be the basis of 3PD's who want to create a plugin for other JS Frameworks. I think the main problem right now is that there's no unified way to include jQuery or other frameworks. If CB uses jQuery, and my module would need jQuery, there's a possibility that jQuery will be loaded twice. It's difficult to check if jQuery and its plugins has already been loaded. It would be even better if Joomla can include 2 Core plugins for jQuery and Mootools.

I can think of a lot of benefits of this implementation but I hope you can already imagine them. 

But then again, we're off topic. let's move to a new thread for discussions about this.

Regards to everyone

_________________________________________
Israel Dacanay Canasa
Wiz Media, Inc
http://www.wizmediateam.com

[Amy Stephen]

Beat -

Would like to play around with that. How would I get a copy? If it's okay to share, please email me one.

Thanks!
Amy

On Thu, Jun 11, 2009 at 2:43 AM, Beat <bea...@gmail.com> wrote:

[Amy Stephen]

To echo what others are saying, it is an honor that you are visiting us.

For me, the challenge using Mootools has nothing to do with any of the issues you outlined. It's much simplier than that. I am not a Javascript developer. There are widgets and UI toolkits that I can use to build sites that help me meet the needs of today's social - content rich - dashboard environments. Unfortunately, I can't find those toolkits in Mootools.

Now, maybe we should work with the Mootools team on defining some of those objects that would be helpful and working together with you guys to learn how to build them and start developing your army of Mootools UI developers. The 3PD Mootools community is simply not well developed - or - they aren't sharing their work, not sure there.

I think one of causes of a lack of engaged community likely came from closing the Mootools forums. There just was no place for people to go to learn and collaborate and help you build up usage of your tool and craft these toolkits that other projects now have.

From my perspective, Mootools is now significantly behind other options and figuring out how to build your community and get these highly functional widgets and UI components in place should be your focus if you hope to recharge.

I think also the Joomla! community should have been more involved in building these widgets. Those who use these frameworks should be your developers, too, but there was no strategy to make that happen that I saw from either project.

I hope this doesn't sound harsh. I am trying to be very direct so that my feedback might be useful to the Mootools project. The truth is, I think Mootools has a serious challenge regaining lost ground. If you are serious about continuing as a major player, get a community manager involved in crafting a plan to build that army of developers and make helping others learn to use what you have your primary goal. Those plans should include engaging developers from projects, such as Joomla!, who use your tool, and providing a central repository for people to share work and a place for community to help one another.

With respect.
Amy

[Ian MacLennan]

For those looking for a toolkit, try http://jxlib.org/

Ian

[Amy Stephen]

That one is not too bad, it's not quite at the levels of the others, but I did review that.  That is the only Mootools one I saw. There are things like Mocha, but, it's pretty slim pickings compared to other environments.

[dukeofgaming]

My two main sources for this kind of stuff:

http://www.clientcide.com/wiki/cnet-libraries/09-forms/02-datepicker
http://digitarald.de/projects/

[Aaron Newton]

Hi all,

My name is Aaron. I work on MooTools and I blog a bit on JS oriented
stuff. I wrote that big jQuery vs. MooTools article.

I wanted to hop in and reply to a couple of these more recent comments
since Valerio's post. I'll first echo that I'm in agreement with all
of Valerio's comments of course. We greatly appreciate the support
your community has shown us and, to the extent we can be responsive
and helpful to help your community out in return we're quite happy to
do so.

Now, to reply to some of the above comments:

@Israel wrote:
Valerio, adding an implementation noConflict reallly changes things.
But I don't understand why Aaron Newton said Mootools can't do
it inherently because of its design. http://twitter.com/anutron/status/2105801316.
(Also, I'm sorry if I offended others by comparing mootools to a
bully.)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

What I mean is that part of MooTools' design to extend native
prototypes (like Element, String, Array). To an extent, this means
that its functionality can never be encapsulated in the same way that
jQuery's is. This is really only a problem for Prototype.js though.
I'll point out that jQuery's "noConflict" mode is really just removing
the $ alias. There's no real magic there. But because jQuery's
functionality is all contained on the jQuery object, that's the only
other item in the global namespace that they have to worry about
conflicts for. MooTools, however, touches many, many public objects
(prototypes of natives as well as classes like "Fx" which are not
currently namespaced). Even if we namespaced all the class names and
static methods, we'd have that problem with the prototypes. If we
removed the prototype extensions, you'd no longer have MooTools. This
is what I mean that fundamentally MooTools cannot exist in a
"noConflict" manner. It certainly can not conflict with jQuery though.
Our next version does just that.

@Amy wrote:
I think one of causes of a lack of engaged community likely came from
closing the Mootools forums. There just was no place for people to go
to learn and collaborate and help you build up usage of your tool and
craft these toolkits that other projects now have.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I hope I don't sound too frustrated here, but as we've said on many
previous occasions, we didn't close the forums! We simply moved to a
different platform. There is a (vibrant) Google Group for MooTools
Users - how is this any different than what we're doing right here for
Joomla? We simply chose to stop *hosting* the forums. Part of this was
because we felt that the forums in their previous form were very
unproductive. If anything, moving them to Google has required far less
administration and has created an environment that's far easier for us
to respond to. We love our users just as you love yours and we spend a
lot of energy helping them.

@Amy (also) wrote:
From my perspective, Mootools is now significantly behind other
options and
figuring out how to build your community and get these highly
functional
widgets and UI components in place should be your focus if you hope to
recharge.

I think also the Joomla! community should have been more involved in
building these widgets. Those who use these frameworks should be your
developers, too, but there was no strategy to make that happen that I
saw
from either project.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Being "behind" other frameworks implies that we are in some sort of
competition to "win" something and we do not see it that way. Just as
Joomla is not competing with Wordpress, we are not competing with
jQuery. If people choose jQuery over MooTools, that's ok with us. We
make MooTools so we can use it and we get a lot of value out of
sharing it for others to use, too. But we aren't an enterprise
software business or anything. If people don't use it, that's ok. We
LOVE that Joomla uses MooTools, but, as Valerio says, if you choose to
switch to another framework we'll wish you well. If someone were to
show up on your forums and say that they didn't like Joomla and they
were going to install Wordpress, you'd probably wish them well and
tell them they were welcome to come back if Wordpress didn't meet
their needs. It's like that. We do plan on having a UI framework (I'll
also point out http://mochaui.com/) but we don't feel we're "behind"
anyone else. We're where we are, and where we're going has more to do
with what we and our community wants than what other frameworks have
released.

I TOTALLY agree that Joomla developers who are writing functionality
with MooTools should be our developers, too. I'll confess that I
personally haven't been in contact with anyone on your team (though
Valerio has) but I'd love nothing better than to see some of your
developers join our development mailing list and pass us feedback
about the needs of your community.

Finally, I'll point out that we have a plugin forge in development
that is nearly ready for an alpha release. Sometime in the next month
or so we'll be inviting anyone with a MooTools plugin to submit it to
our catalog. I think that might have a profound impact on both our
communities.

Aaron

[Amy Stephen]

As an example of the diversity of objects one might want to find - and the difference in offerings between the two communities right now, I'd like to share this example that just came up in the meeting I got out of.

We need to traverse this Web site by org structure, both people and org units. And, we need to be able to automatically display an org chart, at varying levels.

So, Google search for JQuery Org Chart turns up many nice offerings on first page:

• http://apex.oracle.com/pls/otn/f?p=987654321:39:0:::RP,39
• http://kod34fr33.wordpress.com/2009/02/26/jquery-organization-chart-builder/

What is on page 1 of Google search results for Mootools Org Chart? Things that aren't Mootools Org Charts, or two requests for bids that went unanswered for a Mootools Org Chart, or the last example is the "Mootools Forums have been closed for over 1 1/2 years" message.

• http://www.mistersoft.org/freelancing/scriptlance/2009/02/Javascript-PHP-MySQL-Org-Chart-Javascript-Joomla-1234011553.html
• http://www.webdeveloper.com/forum/showthread.php?t=194774
• http://www.mistersoft.org/freelancing/scriptlance/2009/02/Ajax-Javascript-XHTML-CSS-Javascript-Mootools-Controls-1233602021.html
• http://forum.mootools.net/viewtopic.php?id=8765

Closing the forums might have shut down this community. And, until that development gets fired back up, one wonders what will be available in a year, or two.

I am about as Joomla! loyal as they come. I didn't get to this perspective without  struggle. My Google Search skills are pretty good, I think, and I am someone who tends to know who's who in our neighbor projects and I tend to stay in touch with what's going on.

Now, as we go through the design on this project, we will look at Mootools, too, and we will try to see if there are good choices there. We can share this type of feedback if it's helpful.

I don't want to belabor this point or offend our Mootools developers. I think we need to start documenting some of these resources in the Wiki and have others look into the topic and see if they draw different conclusions. I am eager to hear of a treasure trove I have overlooked but somewhat doubtful that's going to happen.

[Aaron Newton]

I think it's a fair point that the jQuery community has cranked out a
lot more widgets than MooTools has. I will say that, looking at each
of these plugins, they would be rather easy to convert to MooTools
quickly (the first one actually uses Google Charts to make the graph;
jQuery is just used to turn the json object into a table that Google
uses to render the image - if I'm reading it right).

My point is that yes, these things are out there. And it's a fair
point that jQuery has a more active plugin community. If that's the
key reason to choose jQuery for your work, then so be it.

As for your point about us "killing our community" I couldn't disagree
more. We left the forums up (read-only) for over a year. The threads
that were there (until about two weeks ago when we finally took them
down) were all about MooTools 1.11. I realize that Joomla still uses
1.11, but by and large our community is no longer using that library.
I'll also note that the wayback machine has the content cached if it's
really that important to anyone.

Our community is alive and well and we have a lot of activity on our
mailing list daily (again, it just *moved* - I don't see how shutting
down a hosted forum in favor of Google Groups is "killing" anything).
As a side note, I'll point out that jQuery doesn't even have an
official forum or user mailing list.

Regardless, I stand by what I said before. If MooTools continues to be
the choice that the Joomla community makes for it's development
environment, we'll do whatever we can to help support you. The
invitation for some of you to join our developer mailing list stands.

Aaron

On Jun 11, 3:46 pm, Amy Stephen <amystep...@gmail.com> wrote:
> As an example of the diversity of objects one might want to find - and the
> difference in offerings between the two communities right now, I'd like to
> share this example that just came up in the meeting I got out of.
>
> We need to traverse this Web site by org structure, both people and org
> units. And, we need to be able to automatically display an org chart, at
> varying levels.
>
> So, Google search for JQuery Org Chart turns up many nice offerings on first
> page:
>

>    -http://apex.oracle.com/pls/otn/f?p=987654321:39:0:::RP,39
>    -
>    http://kod34fr33.wordpress.com/2009/02/26/jquery-organization-chart-b...

>
> What is on page 1 of Google search results for Mootools Org Chart? Things
> that aren't Mootools Org Charts, or two requests for bids that went
> unanswered for a Mootools Org Chart, or the last example is the "Mootools
> Forums have been closed for over 1 1/2 years" message.
>

>    -
>    http://www.mistersoft.org/freelancing/scriptlance/2009/02/Javascript-...
>    -http://www.webdeveloper.com/forum/showthread.php?t=194774
>    -
>    http://www.mistersoft.org/freelancing/scriptlance/2009/02/Ajax-Javasc...
>    -http://forum.mootools.net/viewtopic.php?id=8765

>
> Closing the forums might have shut down this community. And, until that
> development gets fired back up, one wonders what will be available in a
> year, or two.
>

> I am about as *Joomla! loyal* as they come. I didn't get to this perspective

> without  struggle. My Google Search skills are pretty good, I think, and I
> am someone who tends to know who's who in our neighbor projects and I tend
> to stay in touch with what's going on.
>
> Now, as we go through the design on this project, we will look at Mootools,
> too, and we will try to see if there are good choices there. We can share
> this type of feedback if it's helpful.
>
> I don't want to belabor this point or offend our Mootools developers. I
> think we need to start documenting some of these resources in the Wiki and
> have others look into the topic and see if they draw different conclusions.
> I am eager to hear of a treasure trove I have overlooked but somewhat
> doubtful that's going to happen.
>

> On Thu, Jun 11, 2009 at 4:34 PM, dukeofgaming <dukeofgam...@gmail.com>wrote:
>
> > My two main sources for this kind of stuff:
>
> >http://www.clientcide.com/wiki/cnet-libraries/09-forms/02-datepicker
> >http://digitarald.de/projects/
>

> > On Thu, Jun 11, 2009 at 2:41 PM, Amy Stephen <amystep...@gmail.com> wrote:
>
> >> That one is not too bad, it's not quite at the levels of the others, but I
> >> did review that.  That is the only Mootools one I saw. There are things like
> >> Mocha, but, it's pretty slim pickings compared to other environments.
>

> >> On Thu, Jun 11, 2009 at 11:22 AM, Ian MacLennan <ianlen...@gmail.com>wrote:
>
> >>> For those looking for a toolkit, tryhttp://jxlib.org/
>
> >>> Ian

> ...
>
> read more »

[Amy Stephen]

Aaron -

Now, come on, I did not say "killing our community" :-P

All right, I am sorry for incorrectly linking the forum "shift" to a decline in throughput and active developer community. What do I know?

I am glad that you agree with my overall point, though, and that is that there are fewer offerings and a less active community of Mootools developers.

I am encouraged by that recognition because it says the Mootools project is aware of the issue and trying to revitalize.

It is good to hear that you are creating a central Plugin library for users. Good move. It should make it easier to find things that already exist and encourage other contributions.

I think it's important for the Mootools project to recognize that you have a virtual monopoly on what Javascript solutions most Joomla! developers are able to use by the simple fact that your framework goes out in each package of Joomla!.

I am certain you agree that such a priviledge comes with responsibility to help ensure our success with your tool. It's very nice to see the top levels of both projects are in close contact with one another and that questions are quickly answered at that level. That level of support and trust and knowledge needs to also help 3PDs to build skills and share new plugins with others.

You see, Aaron. My comment about "Mootools behind behind" had nothing to do with the Mootools team winning, at all, it's about those of us who use Mootools winning.

I look forward to watching the Mootools project revitalize to earlier forms of amazing.

Amy :)

[Ian MacLennan]

Thanks for joining the discussion Aaron, though I apologize that you entered into such a hot topic, but I suppose people are quite passionate about this issue and at times forget to be polite and civil.

I think Mootools and Joomla! have passed through some similar seasons of growing.  As we moved on from 1.0 to 1.5, we had no real choice but to drop a lot in terms of backwards compatibility.  Our shift was probably more significant in size that the Mootools shift from 1.1 to 1.2, but it is the same idea of cleaning out cruft so that we can move on to a brighter future.

It certainly took time for third party developers to make that shift along with us, but we have certainly seen them come around and now 1.5 is front and centre as the release to develop for.

I have seen a signifcant increase in the availability of documentation and resources for Mootools 1.2, and I am happy to see that.

I would welcome the opportunity to be able to participate on your lists over there as I am able.  I will certainly keep closer tabs on what is going on over there as I am able.

Ian

[Jennifer Marriott]

Hey all,

What an interesting discussion! All I have to add is that I am
thoroughly impressed that the both JS Teams have come into the
discussion. I have been using and loving JQuery for I think about 8
months now, and I am truly thankful for it. Also MooTools has been a
staple for many for quite a while, and while I am not as familiar with
it, I did just get Aaron's book as a gift, and I am looking forward to
learning more, especially now that J! is updating. Both projects have
great UI libraries - JxLib for MooTools http://jxlib.org and JQueryUI
for JQuery - http://jqueryui.com - it is a lot of fun and useful
stuff not only for using but for learning.

I find it really great that Joomla, JQuery and MooTools can all work
together harmoniously if you want them to. And if you have questions
or come up with a problem all three projects have avenues to ask
questions, get help and get involved.

All three projects make me stretch my creativity and evolve and for
that I am grateful, because it makes me better. In turn I hope to
turn the favor back by enriching back to each in my own ways.

Thanks MooTools and Jquery for doing what you do so well, and joining
in.

Jenny

On Jun 11, 9:33 pm, Amy Stephen <amystep...@gmail.com> wrote:
> Aaron -
>

> Now, come on, I did *not* say "killing our community" :-P

>
> All right, I am sorry for incorrectly linking the forum "shift" to a decline
> in throughput and active developer community. What do I know?
>
> I am glad that you agree with my overall point, though, and that is that
> there are fewer offerings and a less active community of Mootools
> developers.
>
> I am encouraged by that recognition because it says the Mootools project is
> aware of the issue and trying to revitalize.
>
> It is good to hear that you are creating a central Plugin library for users.
> Good move. It should make it easier to find things that already exist and
> encourage other contributions.
>
> I think it's important for the Mootools project to recognize that you have a
> virtual monopoly on what Javascript solutions most Joomla! developers are
> able to use by the simple fact that your framework goes out in each package
> of Joomla!.
>
> I am certain you agree that such a priviledge comes with responsibility to
> help ensure our success with your tool. It's very nice to see the top levels
> of both projects are in close contact with one another and that questions
> are quickly answered at that level. That level of support and trust and
> knowledge needs to also help 3PDs to build skills and share new plugins with
> others.
>
> You see, Aaron. My comment about "Mootools behind behind" had nothing to do

> with the Mootools team winning, at all, it's about *those of us who useMootools
> *winning.

[Aaron Newton]

Ian, I've sent you an invitation to our dev list.

Amy, Thanks for your thoughtful comments. We want to see Joomla be
successful, or at least ensure it's not limited by its choice of
JavaScript frameworks.

Jennifer, I'll plug (again) Mocha UI, which is really a nice MooTools-
built UI framework: http://mochaui.com/

[Amy Stephen]

I appreciate that, Aaron. I am absolutely certain the Mootools team
feels that way.

Ian's point is a good one. Andrew said the same thing, too. It
certainly did take a while following our the 1.5 release to build back
up extensions.

I will try to see what's available in Mootools and at least identify
what I see as missing as I go through this next project. Hopefully, I
can find time to learn Mootools and maybe contribute a plugin some
day. It will be good to see the Joomla! community contributing plugins
for Mootools.

Means a lot that you guys came to talk to us. Thank you for helping us
over the years.

[jiggliemon]

I'm petty sick of this debate.
It's not like mootools is using prototype.

And the syntax between moo and jquery is pretty damn close.

I saw the arguement "mootools breaks backwards compatability. Jquery
doesn't.". This comes at a cost of weight and architecture.

How bout. All you jquery fanboys. Learn how to write a javascript
class. And stop copy pasting. You'll be better human beings because of
it.


On 9 June, 15:45, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Stian and thanks for joining in.
>
> Everyone has biases ;)  This thread would not have started.
>
> Here's the argument.  Mootools is very good.  jQuery is very good.
> Both have good communities.  Joomla devs have a good relationship with
> Mootools developers, the chose JS framework for Joomla.  Mootools
> serves Joomla's needs well.  There is no *compelling* argument to
> change.
>
> I take issue with your comment about being afraid of loosing goodwill.
>  If you know your Joomla and Mambo history, we've had good
> relationships with a lot of 3rd party library providers, DOMIT and
> InputFilter to name a few.  I had good relationships personally with
> both those developers and they were thrilled to work in with us while
> they were active.  We regularly access the relationship with people
> (because, after all, communities are about relationships) and you'll
> know that we've sought other options when these developer's have moved
> on (as both have done).  Should Mootools become poorly supported, then
> I would be making a call on using a different framework for my own
> stuff and Joomla would be wise to make the same assessment.  Should
> jQuery fall in a heap, we are unaffected.  It's the circle of software
> life.  We work with people while they are active, and when they
> aren't, we find the best alternatives that meet the greater needs of
> the project.
>
> As I already stated, we will make an effort to allow people to use
> their JS framework of choice, but the bottom line is Joomla core will
> use Mootools when it needs it and 3rd parties will have to take that
> into account.
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/6/10 Stian Didriksen <st...@ninjatheme.com>:
>
>
>
> > Relationships between you and Mootools devs is completely irrelevant.
> > There are far too many developers using jQuery to ignore.
>
> > And if Joomla used jQuery, preventing Mootools based scripts from
> > breaking is as simple as writing your jQuery in noConflict() mode.
> > That would mean no 1.5 based mootools 1.1 scripts breaking.
>
> > Can we achieve the same by using Mootools?
>
> > I say core scripts should be coded like shadowbox, using adaptors that
> > is:http://www.shadowbox-js.com/support.html#adapters
>
> > Your relationship with Mootools wont help me in my next project, but
> > being able to code with whichever framework I need will.
>
> > I would like to see some hard facts on what goodwill Joomla as an
> > project get, that you are afraid of loosing?
> > That's the most personal and biased argument I've heard today.
>
> > Regards,
> > Stian Didriksen
>
> > Den 9. juni. 2009 kl. 23.17 skrev Andrew Eddie:
>
> >> With respect this is a bit like splitting hairs over the Drupal vs
> >> Joomla debate.  Both are stunning, both have supportive and different
> >> communities with strengths and weaknesses.
>
> >> We have had good connections with the Mootools creators and experts so
> >> far.  We don't have that relationship with the jQuery community (note
> >> the lowercase 'j'; JQuery is our new database query class <cough>) as
> >> far as I know.  I don't see any particularly good reasons to sever
> >> that goodwill where there is honestly no better argument than personal
> >> preference.  That might change in the future, but right now it does
> >> what it needs to in the backend and the frontend is being made as
> >> agnostic as possible.
>
> >> Regards,
> >> Andrew Eddie
> >>http://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> >> 2009/6/10 Amy Stephen <amystep...@gmail.com>:
> >>> This past few weeks, I have been looking for "easy to use" UI
> >>> widgets that I
> >>> need for a project a team of us are working on. It is Intranet
> >>> environment
> >>> with a lot of varied content, the need for groups, sophisticated
> >>> ACL, and a
> >>> high degree of interactivity.
>
> >>> Traditional page reloading after each minor task will not cut it.
> >>> These
> >>> people will be working all day with this tool, it has to be easy to
> >>> access
> >>> what they need, make changes, approve work, schedule meetings,
> >>> message one
> >>> another, etc.
>
> >>> To be perfectly honest, after reviewing options out there, there is
> >>> no
> >>> question in my mind about which JS Framework will enable me to
> >>> offer more
> >>> functionality, quickly today: JQuery. It is not even close for me.
>
> >>> From what I have read, most tend to agree Mootools is the "better"
> >>> solution
> >>> from an application infrastructure perspective. But, UI experts are
> >>> not
> >>> developers and JQuery is more geared towards those needs and skill
> >>> sets.
>
> >>> The size and engagement of a community does matter. We know this
> >>> because we,
> >>> the Joomla! community, are also a huge, active, powerful community.
> >>> When
> >>> people are comparing CMS's, one look at the Joomla! Extensions
> >>> Directory
> >>> says - this community will help you build cool Web sites. I get
> >>> that same
> >>> feeling about JQuery's community. They are active, creating, and
> >>> sharing a
> >>> lot of excellent UI options. They are growing. There are lots of
> >>> training
> >>> material, blogs, videos, and books.  As is the case with the Joomla!
> >>> community, they are putting solutions on the shelf on a regular
> >>> basis and
> >>> they don't appear to have hit full stride, yet, either.
>
> >>> The work that community produces enables someone like me, someone
> >>> without
> >>> strong Javascript skills (heck, someone without even weak Javascript
> >>> skills!), to be able to tackle a Web site like this.
>
> >>> To be honest, the fact that Joomla! has Mootools in core does not
> >>> cause me,
> >>> one tiny bit. I know how to remove it and I know how to replace it
> >>> with
> >>> JQuery and that is what I will do in order to provide this customer
> >>> the best
> >>> solution, possible.
>
> >>> I probably would not have raised this issue, because I know it's a
> >>> huge
> >>> challenge to make a change like this. We will not all agree on this
> >>> one and
> >>> there is no way to scientifically conclude, one way or the other. I
> >>> also
> >>> understand and *value* the freedom the GPL offers me and I will,
> >>> without
> >>> apology, exercise those rights. So, Joomla! is not stopping me.
>
> >>> But, after reading Beat's comment about how, since 1.2 is not
> >>> compatiable
> >>> with 1.1, anyway, that *now* is as likely the best opportunity we
> >>> will ever
> >>> have to consider a change to JQuery. I realized when I read that,
> >>> that he is
> >>> right and he is right to raise the issue and advocate for what he
> >>> sees as a
> >>> better path for our project. I would be wrong to just do my own thing
> >>> quietly without also letting it be know that I also believe JQuery
> >>> is best
> >>> for this project.
>
> >>> I also believe it would very wise for this project to get behind
> >>> Ajax and
> >>> share examples of how to use it with Joomla!. Like it, don't like it,
> >>> doesn't matter, it's a key building block for developers today and an
> >>> absolute requirement if you are heading into rich internet
> >>> applications. So,
> >>> framework decision aside, we should show how to use Ajax with that
> >>> framework
> >>> to create those types of Joomla! interfaces. (BTW: by "we should" I
> >>> mean all
> >>> of us posting in this thread, not the guys working too hard for us,
> >>> already.)
>
> >>> So, I agree, it is time to think about those things. It's that big
> >>> of a deal
> >>> that, we should at least pause for a moment, to think about which
> >>> direction
> >>> might offer the community the best options moving forward. We need
> >>> to bear
> >>> in mind that since this is one of those either/or kinds of deals,
> >>> some of us
> >>> aren't going to get our way. There is no reason for anyone to fall
> >>> into a
> >>> heap of tears when it is likely decided we will stay the course with
> >>> Mootools. Let's remember the GPL empowers us to modify this code
> >>> base and
> >>> crank it up in whatever way we find suitable for our needs. We are
> >>> all
> >>> empowered as we choose to be.
>
> >>> With respect to all of you,
> >>> Amy

[Andrew Eddie]

jiggliemon please be constructive. Comments like *that* are not welcome here.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/6/14 jiggliemon <ch...@agroism.com>: