The MooTools Upgrade Helper

[Aaron Newton]

Greetings all,

Forgive me if this is the wrong list to post this; a search of google
groups for "joomla" brings back numerous results. My objective here is
to reach the Joomla Dev team and then let you guys communicate with
your community rather than blast this out to all your developers.

When I went to your NYC conference I promised that we'd have a
compatibility beta in your hands by the end of the year. Well, we cut
it pretty close, but here it is:

http://mootools.net/blog/2009/12/31/mootools-1-1-upgrade-layer-beta/

There are numerous threads about MooTools and Joomla and the various
upgrade woes such as this one:

http://groups.google.com/group/joomla-wg-production/browse_thread/thread/891cdaa811c85858

That I'd like to respond to with this information, but I don't have
permission to post there. I'm also wary of communicating this in a
manner that may not be productive for your dev team.

What we'd like to do now is to work with you and members of your
community to test this script, to get feedback and help you address
any issues that come up. Members of our team have offered to help
upgrade tricky stuff and popular plugins and whatnot. Hopefully this
script will make moving to 1.2 and beyond much easier.

Our sincere apologies that it took this long to get it to you.

Happy New Year and all that.
Aaron

[Andrew Eddie]

Hi Aaron.

Just confirming that this place is the right place to post :)

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

2010/1/1 Aaron Newton <anu...@gmail.com>:

> --
>
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an 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.
>
>
>

[Ian MacLennan]

Oh yes, and to follow up, I'm working on a plugin for our users to give things a test spin.  Should have something to release fairly soon.  Just waiting for the other dev coords to return :)

Ian

[Aaron Newton]

Thanks Andrew, Ian.

Just let us know if we can do anything to help. We're excited to see the results.

[Ian MacLennan]

Okay, apologies folks for the delay.  Was stuck on an issue with Tooltips and speaking with Darren Waddell finally got me straightened out.

So, I have attached to this post a plugin that will swap out the existing Mootools for Mootools 1.2.  So, some notes on usage:

1. Installation
Install using the extension installer.

2. Usage
Go to the plugin manager and find the System - Mootools12 plugin.  Enable this plugin.

3. Implementation Notes
For those of you who have been following Mootools development for 1.6, you will have seen that the method behavior.mootools has been deprecated in favour of the more generic behavior.framework.  The plan is to leverage this fact for the implementation of Mootools 1.2 in Joomla! 1.5.  If your extension invokes JHTML::_('behavior.framework'), the framework will load the Mootools 1.2 file.  If your extension invokes JHTML::_('behavior.mootools'), the framework will load the Mootools 1.2 file *and* the compatibility layer.  This way, for the most part, we only load the compatibility layer when we need it.

So, the long and the short of it is, if your script requires Mootools 1.2, use behavior.framework.  If your script requires Mootools 1.1, use behavior.mootools.

Now, you may have noticed I said 'for the most part' above.  This is because of the method JHTMLScript.  The third parameter to this is whether or not to load Mootools.  Since we cannot change the behaviour of this method, we have to have this method load the compatibility layer if the third parameter is true (the default).

I have backported most of the behaviours from 1.6 into this plugin.  Thus, for the most part this plugin replaces the 1.1 code with 1.2 code.  There are a few things that I haven't finished yet, so they still use the regular 1.5 stuff with 1.1 code.  If/when we release 1.5 with the compatibility layer, we intend to use all 1.2 code.

So, in my testing so far, things were pretty smooth.  There may be things I missed though, so feel free to contribute improvements, suggestions or ideas.

If you find issues with the compatibility layer, please post them here and I will make sure that the folks over at Mootools are notified and can take care of things.  I'm really appreciative of their willingness to help and support this effort.  It is great to see developers standing behind their code!

For those that are interested, the code for this plugin can be found in the mootools12 branch.

Cheers!
Ian

[infograf768]

Some issues with the new caption.js, Ian.
It breaks image and caption alignment as we patched them in 1.5.15.
I have hacked it a bit, and get better results on Mac/FF.
But not perfect.

> On Mon, Jan 4, 2010 at 12:00 AM, Aaron Newton <anut...@gmail.com> wrote:
> > Thanks Andrew, Ian.
>
> > Just let us know if we can do anything to help. We're excited to see the
> > results.
>

> > On Sun, Jan 3, 2010 at 8:54 PM, Ian MacLennan <ian.maclen...@joomla.org>wrote:
>
> >> Oh yes, and to follow up, I'm working on a plugin for our users to give
> >> things a test spin.  Should have something to release fairly soon.  Just
> >> waiting for the other dev coords to return :)
>
> >> Ian
>

> >> On Sun, Jan 3, 2010 at 11:46 PM, Andrew Eddie <mambob...@gmail.com>wrote:
>
> >>> Hi Aaron.
>
> >>> Just confirming that this place is the right place to post :)
>
> >>> Regards,
> >>> Andrew Eddie

> >>>http://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> >>> 2010/1/1 Aaron Newton <anut...@gmail.com>:

> >>> > Greetings all,
>
> >>> > Forgive me if this is the wrong list to post this; a search of google
> >>> > groups for "joomla" brings back numerous results. My objective here is
> >>> > to reach the Joomla Dev team and then let you guys communicate with
> >>> > your community rather than blast this out to all your developers.
>
> >>> > When I went to your NYC conference I promised that we'd have a
> >>> > compatibility beta in your hands by the end of the year. Well, we cut
> >>> > it pretty close, but here it is:
>
> >>> >http://mootools.net/blog/2009/12/31/mootools-1-1-upgrade-layer-beta/
>
> >>> > There are numerous threads about MooTools and Joomla and the various
> >>> > upgrade woes such as this one:
>

> >>>http://groups.google.com/group/joomla-wg-production/browse_thread/thr...

>
> >>> > That I'd like to respond to with this information, but I don't have
> >>> > permission to post there. I'm also wary of communicating this in a
> >>> > manner that may not be productive for your dev team.
>
> >>> > What we'd like to do now is to work with you and members of your
> >>> > community to test this script, to get feedback and help you address
> >>> > any issues that come up. Members of our team have offered to help
> >>> > upgrade tricky stuff and popular plugins and whatnot. Hopefully this
> >>> > script will make moving to 1.2 and beyond much easier.
>
> >>> > Our sincere apologies that it took this long to get it to you.
>
> >>> > Happy New Year and all that.
> >>> > Aaron
>
> >>> > --
>
> >>> > You received this message because you are subscribed to the Google
> >>> Groups "Joomla! CMS Development" group.
> >>> > To post to this group, send an email to
> >>> joomla-...@googlegroups.com.
> >>> > To unsubscribe from this group, send email to

> >>> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsu...@googlegroups.com>

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

> >>> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsu...@googlegroups.com>

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

> >> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsu...@googlegroups.com>

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

> > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>
>

>  mootools12.zip
> 198KViewDownload

[dukeofgaming]

Hi Ian,

I am removing Dwight Jack's hack from a big project I am developing
under Joomla (both backend & frontend with mootools 1.2). For the
moment I'd just like to point out that the mootools core & more is
incomplete. The Spinner class was not there and don't really know what
else, I have updated locally with the full thing and some stuff from
my side was corrected.

Also, I'm working with the Clientcide plugin library (http://
www.clientcide.com/js/), and for some reason just including this
breaks the joomla administrator menu (turns the list from horizontal
to vertical, dropdowns still work). I am looking into this right now.
I think this library is worth mentioning since some stuff tends to be
eventually included in Mootools, as it is developed by Aaron Newton. I
am looking into this issue right now.

What will be the future of this plugin when its mature?, will it be
included and enabled in future J 1.5 releases?.

Regards,

David

> > On Sun, Jan 3, 2010 at 8:54 PM, Ian MacLennan <ian.maclen...@joomla.org>wrote:
>
> >> Oh yes, and to follow up, I'm working on a plugin for our users to give
> >> things a test spin.  Should have something to release fairly soon.  Just
> >> waiting for the other dev coords to return :)
>
> >> Ian
>

> >> On Sun, Jan 3, 2010 at 11:46 PM, Andrew Eddie <mambob...@gmail.com>wrote:
>
> >>> Hi Aaron.
>
> >>> Just confirming that this place is the right place to post :)
>
> >>> Regards,
> >>> Andrew Eddie

> >>>http://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> >>> 2010/1/1 Aaron Newton <anut...@gmail.com>:

> >>> > Greetings all,
>
> >>> > Forgive me if this is the wrong list to post this; a search of google
> >>> > groups for "joomla" brings back numerous results. My objective here is
> >>> > to reach the Joomla Dev team and then let you guys communicate with
> >>> > your community rather than blast this out to all your developers.
>
> >>> > When I went to your NYC conference I promised that we'd have a
> >>> > compatibility beta in your hands by the end of the year. Well, we cut
> >>> > it pretty close, but here it is:
>
> >>> >http://mootools.net/blog/2009/12/31/mootools-1-1-upgrade-layer-beta/
>
> >>> > There are numerous threads about MooTools and Joomla and the various
> >>> > upgrade woes such as this one:
>

> >>>http://groups.google.com/group/joomla-wg-production/browse_thread/thr...

>
> >>> > That I'd like to respond to with this information, but I don't have
> >>> > permission to post there. I'm also wary of communicating this in a
> >>> > manner that may not be productive for your dev team.
>
> >>> > What we'd like to do now is to work with you and members of your
> >>> > community to test this script, to get feedback and help you address
> >>> > any issues that come up. Members of our team have offered to help
> >>> > upgrade tricky stuff and popular plugins and whatnot. Hopefully this
> >>> > script will make moving to 1.2 and beyond much easier.
>
> >>> > Our sincere apologies that it took this long to get it to you.
>
> >>> > Happy New Year and all that.
> >>> > Aaron
>
> >>> > --
>
> >>> > You received this message because you are subscribed to the Google
> >>> Groups "Joomla! CMS Development" group.
> >>> > To post to this group, send an email to
> >>> joomla-...@googlegroups.com.
> >>> > To unsubscribe from this group, send email to

> >>> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>

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

> >>> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>

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

> >> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>

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

> > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>
>

>  mootools12.zip
> 198KViewDownload

[Aaron Newton]

Hi all,

For the moment I'd just like to point out that the mootools core & more is
incomplete. The Spinner class was not there and don't really know what
else, I have updated locally with the full thing and some stuff from
my side was corrected.

The version of 1.2 built for this compatibility / upgrade helper only includes the functionality from 1.1, so it includes Drag, because Drag was in 1.1. But Spinner wasn't. So if you want Spinner, you should add that to your environment separately.

 

Also, I'm working with the Clientcide plugin library (http://
www.clientcide.com/js/), and for some reason just including this
breaks the joomla administrator menu (turns the list from horizontal
to vertical, dropdowns still work). I am looking into this right now.
I think this library is worth mentioning since some stuff tends to be
eventually included in Mootools, as it is developed by Aaron Newton. I
am looking into this issue right now.

Most of the stuff from Clientcide that was going to make it into -more is there now. The remaining stuff will eventually make its way into the plugin forge on mootools.net. In general, it's less supported than -more is because I use it less and less (as most of the functionality is now in -more). That said, it shouldn't be breaking things. Feel free to submit tickets on the clientcide repo on github (or, better yet, to fork it and work on a fix). I'm generally less responsive on it as -more takes more of my time...

[dukeofgaming]

Hi Aaron, thanks for the answer.

I have isolated the issue: DollarE.Compat. However, not having this
part of the Clientcide library causes no problem or conflict or
incompatibility with Joomla... at all, so I guess its a no-problem.

The concrete problem was that for some reason a style of "width:
234px;" was being injected into the #menu element and its child #node
elements at the DOM level. I couldn't locate the code, but my best
guess is that $E is still being used somehow... even though I couldn't
find it at all in the rendered Joomla output source.

Regards,

David

[Aaron Newton]

I define $E in Clientcide, but the upgrade helper also defines it - they do the same thing though, so it's odd that it would create a conflict...

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.

To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

[dukeofgaming]

Just to report I found a bug with the module position combobox, I get
this from firebug:

Window.onDomReady is not a function
combobox.js()combobox.js (line 113)

$("combobox-position-select") is null
index....cid[]=1 (line 227)

On Dec 31 2009, 3:35 pm, Aaron Newton <anut...@gmail.com> wrote:
> Greetings all,
>
> Forgive me if this is the wrong list to post this; a search of google
> groups for "joomla" brings back numerous results. My objective here is
> to reach the Joomla Dev team and then let you guys communicate with
> your community rather than blast this out to all your developers.
>
> When I went to your NYC conference I promised that we'd have a
> compatibility beta in your hands by the end of the year. Well, we cut
> it pretty close, but here it is:
>
> http://mootools.net/blog/2009/12/31/mootools-1-1-upgrade-layer-beta/
>

> There are numerous threads aboutMooToolsand Joomla and the various

> upgrade woes such as this one:
>

> http://groups.google.com/group/joomla-wg-production/browse_thread/thr...

[fxstein]

Ian,

We have been running your plugin for the past several weeks as part of
us converting Kunena 1.6 to mootools 1.2

We are basically done with the conversion and on the front end this
are looking great. The behavior.framework is hopefully becoming a
standard amongst many components & plugins and will avoid the double
loading of the same libraries that everybody has implemented, given
the lack of 1.2 support in Joomla.

One issue we just ran into is related to the more libraries. I am
writing an new multi file attachment option into the new bbcode editor
based on fancy upload 3.0 and the attach class. Since it is using the
langauage functions from more, the Joomla mootool12 libraries no
longer include everything we need. I realize that we can just add our
own more js file(s) to our distribution but I wonder if it would be
better if your mootool12 plugin (and later Joomla itself) should
include the more files, even if it does not get loaded by default. A
behavior.framework.more could do so.

That way we don't create a similar problem where developers are forced
to load their own libraries and then run into conflicts with other
extensions.

Other than that, I really like the plugin. There are a few minor issue
as reported before, but we only see them in the backend. All our new
Kunena code works great thanks to Louis getting us started down that
path.

Hope this helps!

Oliver
fxstein

> > On Sun, Jan 3, 2010 at 8:54 PM, Ian MacLennan <ian.maclen...@joomla.org>wrote:
>
> >> Oh yes, and to follow up, I'm working on a plugin for our users to give
> >> things a test spin.  Should have something to release fairly soon.  Just
> >> waiting for the other dev coords to return :)
>
> >> Ian
>

> >> On Sun, Jan 3, 2010 at 11:46 PM, Andrew Eddie <mambob...@gmail.com>wrote:
>
> >>> Hi Aaron.
>
> >>> Just confirming that this place is the right place to post :)
>
> >>> Regards,
> >>> Andrew Eddie

> >>>http://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> >>> 2010/1/1 Aaron Newton <anut...@gmail.com>:

> >>> > Greetings all,
>
> >>> > Forgive me if this is the wrong list to post this; a search of google
> >>> > groups for "joomla" brings back numerous results. My objective here is
> >>> > to reach the Joomla Dev team and then let you guys communicate with
> >>> > your community rather than blast this out to all your developers.
>
> >>> > When I went to your NYC conference I promised that we'd have a
> >>> > compatibility beta in your hands by the end of the year. Well, we cut
> >>> > it pretty close, but here it is:
>
> >>> >http://mootools.net/blog/2009/12/31/mootools-1-1-upgrade-layer-beta/
>
> >>> > There are numerous threads about MooTools and Joomla and the various
> >>> > upgrade woes such as this one:
>

> >>>http://groups.google.com/group/joomla-wg-production/browse_thread/thr...

>
> >>> > That I'd like to respond to with this information, but I don't have
> >>> > permission to post there. I'm also wary of communicating this in a
> >>> > manner that may not be productive for your dev team.
>
> >>> > What we'd like to do now is to work with you and members of your
> >>> > community to test this script, to get feedback and help you address
> >>> > any issues that come up. Members of our team have offered to help
> >>> > upgrade tricky stuff and popular plugins and whatnot. Hopefully this
> >>> > script will make moving to 1.2 and beyond much easier.
>
> >>> > Our sincere apologies that it took this long to get it to you.
>
> >>> > Happy New Year and all that.
> >>> > Aaron
>
> >>> > --
>
> >>> > You received this message because you are subscribed to the Google
> >>> Groups "Joomla! CMS Development" group.
> >>> > To post to this group, send an email to
> >>> joomla-...@googlegroups.com.
> >>> > To unsubscribe from this group, send email to

> >>> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>

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

> >>> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>

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

> >> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>

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

> > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>
>

>  mootools12.zip
> 198KViewDownload

[Matt Thomson]

I've tested the upgrade helper on my gallery extension that uses
mootools 1.11.

The gallery uses about 1000 lines of mootools 1.11 code, and its
working with the upgrade helper apart from the 'mootools more' problem
mentioned above.

My code uses the Asset.Images class which is in mootools 1.11 but not
mootools 1.2 core. As soon as I downloaded the extra bit from Mootools
More, and included it, the error went away.

All of Mootools 1.2 more is about 120KB when compressed, so I can see
why it is not included. With this filesize it might also be
problamatic to do a
JHTML::_('behavior.mootools.more').

Ideally I think it would be best to have something like:
JHTML::_('behavior.mootools.more.forms')
JHTML::_('behavior.mootools.more.utilities')
JHTML::_('behavior.mootools.more.interface') etc etc.

That way only the 'more' part that is needed will get called up,
instead of a 120kb script.

I think if developers need to include the more bits themelves things
will still work, as my understanding is that if a file gets included
twice it will just override the first one (is this correct?).

Even if that is the case, it would be much cleaner and easier for the
end user if the correct javascript files were included once, rather
than a mess of 'more' files form 3 different extensions in different
directories, and would make things a bit easier for developers.

If others think this is the way to go, I can modilfy the plugin and
reupload it here.

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

[Oliver Ratzesberger]

Matt,

You are absolutely right about the more part. I would include it just like you say below. That way an extension can pick what it needs, instead of carrying tons of extra weight.

Thx!

Oliver

> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

[Aaron Newton]

Hi all, just chiming in a bit here.

MooTools More is not meant to be included wholesale (as you point out) but rather as individual plugins for only the stuff you need. Not everyone needs Date enhancements or Form Validators or Fx.Sort. There's been some talk of including the Depender app in joomla, which may make some sense (it calculates dependencies on the fly and compresses output). It depends on how performant you need your app to be; it hasn't been stress tested for extremely busy sites.

But including chunks of it as folders (all of Forms/ or all of Fx/ for example) likely won't work either, as if you included Forms/ without including the things that all the Forms scripts depend on (which include files in Element/, Native/, Class/, Core/, and more) it wouldn't work. Go try the more builder and see what I mean:

http://mootools.net/more

Check all the Forms/ elements and see what else you'd need.

I'm not sure what the right solution is for Joomla, but if we can help, let us know.

[Matt Thomson]

I can see what you mean, including form.request means including
something from most of the sections, which means splitting it up into
sections isn't so useful.

I'm not sure what the best solution is, but I have had a lot of
experience with developers including their own libraries, and it can
lead to quite frustrating situations.

Sometimes my extension will clash with some template, where the
developer has added in their own chunk of mootools (that I can't
verify as 1.11 or 1.2 but "just what the template needs") and if
developers are encouraged to do the library part themselves, these
types of clashes are likely to increase.

Ideally if we can get all of mootools core and more into the plugin
(and eventually 1.5.16), and the plugin will only include the files
once, at least the guideline can be "use JHTML for the library, and
add your scripts that call the library". It might not get followed all
the time, but I think it is much better than the guideline being "just
add in the library bits you need yourself".

Maybe the rest of the 'more' can be put into one file, and there could
just be JHTML::_('behavior.mootools') which works the way it currently
does in the plugin, and JHTML::_('behavior.mootools.more') which does
all the extra 'more' stuff. There is a bit of a hit here in filesize,
but often the solution is a choice of ugly compromises, and I would
rather have an extra 50KB in the download (all the 'more' stuff not
already in the plugin), rather than nasty library conflicts. With
internet speeds going up and up I think the extra filesize is
bearable.

> > >>>>>>http://www.theartofjoomla.com-theart of becoming a Joomla

> ...
>
> read more »

[Oliver Ratzesberger]

Interesting problem about the more dependencies - was not aware of that.

I would second Matt's point of view.

We learned the hard way with Kunena when we used JQuery. So many conflicts and clashes with other components, plugins and modules - no fun to support.

In fact the double loading of libraries from different paths quickly adds up to more than the extra 50kB from the combined more libraries. Joomla is very different in that regard to many other websites: It encourages plugins and extension - the great thing about Joomla - but as such we always have to design for the combination of many different components and plugins. We need to be able to encourage developers to rely on the Joomla core as much as possible and not force them to add their own.
There will still be components with jQuery out there, but in many cases developers pick because there is no standard. While a standard does not have to be enforced, the fact that it exits and makes it easy to use, will create followers.

Just like ourselves. We just rewrote Kunena 1.6 to use mootools for that very specific reason: not to include one-off js libraries. That way we hope that in the future, we will have better integrated websites and less conflicts.

Oliver

[Aaron Newton]

Go here:

http://github.com/anutron/mootools-depender#readme

and here:

http://github.com/anutron/mootools-depender/blob/master/client/Docs/Depender.Client.md

[Matt Thomson]

I think the Depender looks like a great script, but I'm not sure it
would be right for Joomla.

Because Joomla has only one entry point, the request would have to
bootstrap a whole instance of Joomla just to get the js, and it looks
like half the 'more' is already in the script in Ian's plugin.

Because the rest of the more would only be about 50KB - I'm estimating
that as ticking all the more, and compressed, leads to about 100kb,
and the plugin already has:

More, Fx.Elements, Fx.Accordion, Fx.Scroll, Fx.Slide, Fx.SmoothScroll,
Drag, Drag.Move, Class.Binds, Element.Measure, Slider,
Sortables, Color, Group, Hash.Cookie, Scroller, Tips .

It seems it would be better where a developer needs 'more' (which
won't be on every page), that they just grab the 50KB file, rather
than start up another instance of Joomla, to get a js script that is
20-40KB smaller than a direct request to the rest of the 'more'.

On Feb 3, 6:39 pm, Aaron Newton <anut...@gmail.com> wrote:
> Go here:
>
> http://github.com/anutron/mootools-depender#readme
>
> and here:
>

> http://github.com/anutron/mootools-depender/blob/master/client/Docs/D...

> ...
>
> read more »

[Matt Thomson]

I browse and post to this group using the website:

http://groups.google.com/group/joomla-dev-cms

It seems this topic I am currently posting in (The MooTools Upgrade
Helper - http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/49240aaf4464b513/c1c56fa69577e927)
not visible anymore.

Is this correct? Is there some reason for this?

I think it's a really important topic, the javascript library
situation for 3pd devs in 1.5 is a complete mess at the moment (with
mootools 1.11, 1.2 and jquery all being used), and some more
discussion here might save a lot of problems later.

> ...
>
> read more »

[infograf768]

On 4 fév, 02:32, Matt Thomson <mthomso...@gmail.com> wrote:
> I browse and post to this group using the website:
>
> http://groups.google.com/group/joomla-dev-cms
>
> It seems this topic I am currently posting in (The MooTools Upgrade

> Helper -http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/49...)

> not visible anymore.
>
> Is this correct? Is there some reason for this?

I can see it here whether connected or not.

> ...
>
> plus de détails »

[Matt Thomson]

Once I made my latest post to this topic it reappeared for me, but to
find the topic, I had to search the group, as it wasn't in the past
week of topics.

> ...
>
> read more »

[Ian MacLennan]

The  idea I was working with in my head (and which I'm not sold on and haven't tried out in practice) was to generate a JS file at the end of the page load which would generate a javascript file based on the given dependencies and store it in a directory somewhere to be served up by apache.  Basically, you would create a method that would accept as an argument the dependencies that are needed.  It would collect these into an array.  At the very end of the request we would sort the array and hash it.  We would perhaps use the hash as the filename of the js file.  We would then use depender to generate that javascript file.

My suspicion would be that we would end up with a lot of the same files for most pages.  How well this would work would depend on how many difference combinations you get in a site.

Thoughts?

> ...
>
> read more »

[pollen8]

Fabrik takes a similar approach where we have a class that deals with
combining each requested file into one large file. There's a small hit
when you create the file for the first time, but afterwards its a
large speed improvement re-requesting that one file rather than
calling each file individually.
It also attempts to do some compression on the js as well which may or
may not be a wise thing

here's the class:

<?php
// Written by Ed Eliot (www.ejeliot.com) - provided as-is, use at your
own risk
// Check to ensure this file is within the rest of the framework
defined('JPATH_BASE') or die();

class combineJS {

var $aFiles = array();

function __construct( $editor = 'none' )
{
/****************** start of config ******************/
define('CACHE_LENGTH', 31356000); // length of time to cache output
file, default approx 1 year
define('ARCHIVE_FOLDER', 'js'.DS.'archive'); // location to store
archive, don't add starting or trailing slashes
}

function addFile( $f )
{
// $$$ hugh - defensive coding
// http://fabrikar.com/forums/showthread.php?p=53599#post53599
if (!empty($f) && !in_array( $f, $this->aFiles )) {
$this->aFiles[] = $f;
}
}

function getCacheFile()
{
$cachename = '';
foreach ($this->aFiles as $f) {
$f = basename($f);
$f2 = substr($f, 1, 1);
$f2 .= substr($f, 3, 1);
$f2 .= substr($f, -1, 1);
$cachename .= str_replace( '.js', '', $f2 );
}
$cachename .= '.cache';
return $cachename;
}

function outputFolder()
{
return COM_FABRIK_FRONTEND.DS.ARCHIVE_FOLDER;
}

function output()
{
jimport( 'joomla.filesystem.file' );
jimport( 'joomla.filesystem.folder' );
$app =& JFactory::getApplication();
//make a unique key out of the files added:
$cachename = $this->getCacheFile();
/****************** end of config ********************/

$folder = $this->outputFolder();
// create a directory for storing current and archive versions
if (!JFolder::exists( $folder )) {
JFolder::create( $folder );
}
// get code from archive folder if it exists, otherwise grab latest
files, merge and save in archive folder
//if in admin always refresh the script as the file name is the same
for more than one page
if (JFile::exists($folder.DS.$cachename) && $app->getName() !=
'administrator') {
//if the cache is out of date
if (filemtime( $folder.DS.$cachename) < time() - CACHE_LENGTH ) {
$this->write( $cachename, $folder );
}
} else {
//cache file not found so write it out
$this->write( $cachename, $folder );
}
//test
//$this->write( $cachename, $folder );
}

/**
* write the combined file into the archive folder
* @param string cachefilename
* @param string cache foldername
*/

function write( $cachename, $folder )
{
// get and merge code
$sCode = '';

foreach ($this->aFiles as $sFile) {
// $$$ hugh - check it exists first, to avoid PHP notices
if (JFile::exists(COM_FABRIK_BASE.DS.$sFile)) {
$sCode .= file_get_contents( COM_FABRIK_BASE.DS.$sFile );
}
}
//$sCode = preg_replace("/\/\*(.*?)\/\*/", '', $sCode);
//try to remove block comments
//$sCode = preg_replace("/\/\*(.*?)\*\//", '', $sCode);
//remove tabs
//$sCode = preg_replace( "/\t/", '', $sCode );
//try to get rid of one line conmments but doesnt work:
//$sCode = preg_replace("/\/\/(.*?)\n/", ' ', $sCode);
$fbConfig =& JComponentHelper::getParams( 'com_fabrik' );
$lib = $fbConfig->get( 'compress_js', 'none' );

if ($lib == 'none') {
JFile::write( $folder.DS.$cachename, $sCode );
} else {

///compress it! - test php5 only

$src = $folder.DS.$cachename;
$out = $folder.DS.$cachename;

//$t1 = microtime(true);
switch ($lib){
case "jsmin":
$lib = 'jsmin'.DS.'jsmin-1.1.1.php';

require_once( COM_FABRIK_FRONTEND.DS.'libs'.DS.'compression'.DS.'jsmin'.DS.'jsmin-1.1.1.php' );
file_put_contents($out, JSMin::minify($sCode));
break;
case "packer":
default:

require_once( COM_FABRIK_FRONTEND.DS.'libs'.DS.'compression'.DS.'packer1.1'.DS.'class.JavaScriptPacker.php' );
$encoding = 'Normal'; //0,10,62,95
$encoding = 0;
$packer = new JavaScriptPacker($sCode, $encoding, true, false);
$packed = $packer->pack();
file_put_contents($out, $packed);
break;
}
//$t2 = microtime(true);
//$time = sprintf('%.4f', ($t2 - $t1) );
//echo 'script ', $src, ' packed in ' , $out, ', in ', $time, '
s.', "\n";
}
}
}
?>

usage is

$combine = new combineJS();
$combine->addFile( $path.$filename );

then at the end of the components render we do

$file = $combine->getCacheFile();
$combine->output();
$p = FabrikString::ltrimword( str_replace( "\\", "/",
str_replace( COM_FABRIK_BASE, '', $combine->outputFolder() ) ),
"/" ) . "/";
JHTML::script( $file, $p );

We do get a lot of different combined scripts with this method mainly
because we have one script per field type that occurs on the form.

[Oliver Ratzesberger]

Ian,

This could work - really need to try it out. It is important however that the js files generated, get minified and compressed. Maybe the separate piece are already, minified - otherwise the server load would become too high.

I assume every combination would get a unique file name so caching will work.

If its all in one file, the first page of every new combination will have to download the entire js. If you do incremental files, the mootools.js would be the same for all pages.

I'd be happy to test and compare.

Oliver

[Aaron Newton]

You guys are describing much of what the Depender App does. You tell it what you need, it builds the file and caches the results. The Django app is more performant (as it caches to memory), but the PHP version could get there with a little help.

Rather than see you guys put a lot of effort into writing another application, why not pull Depender on github and iterate there?

Also note that the dependency system is changing in MooTools; part of the point of the Depender app is to consolidate the places where we parse and map these dependencies so we can maintain them all in the same place. If you build your own solution, we won't be able to help you maintain it...

[Matt Thomson]

I think its also good to keep in mind the simple solution, and measure
the practical spped differences between the simple solution and the
dependcies one above.

A simple solution would be to have the core and the most used 'more'
in one file called by JHTML::_('behavior.mootools'), so for example it
could have something similar to what the plugin has already:

Core, More, Fx.Elements, Fx.Accordion, Fx.Scroll, Fx.Slide,

Fx.SmoothScroll,
Drag, Drag.Move, Class.Binds, Element.Measure, Slider,
Sortables, Color, Group, Hash.Cookie, Scroller, Tips

This file might be about 70Kb compressed, but it would only be
downloaded once, and what get cached across any page for at least the
next hour or so.

On the minority of cases where some different 'more' things are
needed, JHTML::_('behavior.mootools.more') could be called, and the
rest of more, probably 60 or so KB, would be downloaded once, and
cached.

My thoughts are, a dependecies system would both:
have smaller files
have more files

I'm not sure if the files would be that smaller, given the way a lot
of the core is needed to do a few things, and the way some 'more'
functions load a large part of the more library.
Also, whatever smaller filesizes might get eaten up by having one 40KB
file for page A, one 40KB one for page B, a 50KB one for page C, and a
50KB file for page D (which could have been done with the two files in
my above method).

I think the problem we are trying to solve here is how to have the
whole library available, but not in a 150KB file. I think its
important tobe scientific and measure the filesizes of each method, as
it may be the case the simple solution ends up being similar to any
other one, and even if it does require an extra 30KB of files, the
simplicity of the system might outweigh the cost of an extra 30KB.

On Feb 5, 5:01 am, Oliver Ratzesberger <oliver.ratzesber...@gmail.com>
wrote:

> Ian,
>
> This could work - really need to try it out. It is important however that the js files generated, get minified and compressed. Maybe the separate piece are already, minified - otherwise the server load would become too high.
>
> I assume every combination would get a unique file name so caching will work.
>
> If its all in one file, the first page of every new combination will have to download the entire js. If you do incremental files, the mootools.js would be the same for all pages.
>
> I'd be happy to test and compare.
>
> Oliver
>
> On Feb 4, 2010, at 1:04 AM, Ian MacLennan wrote:
>
> > The  idea I was working with in my head (and which I'm not sold on and haven't tried out in practice) was to generate a JS file at the end of the page load which would generate a javascript file based on the given dependencies and store it in a directory somewhere to be served up by apache.  Basically, you would create a method that would accept as an argument the dependencies that are needed.  It would collect these into an array.  At the very end of the request we would sort the array and hash it.  We would perhaps use the hash as the filename of the js file.  We would then use depender to generate that javascript file.
>
> > My suspicion would be that we would end up with a lot of the same files for most pages.  How well this would work would depend on how many difference combinations you get in a site.
>
> > Thoughts?
>

> ...
>
> read more »

[Ian MacLennan]

That was my intention.  I believe we discussed depender (or at least I spoke with somebody about it) a while ago.

Ian

[Aaron Newton]

Thanks. In the mean time, you can just hide them - just select them and hide them

$$('.validation-advice').hide() 

should do it.

[Aaron Newton]

woops. totally the wrong email. please ignore!

[Oliver Ratzesberger]

Any updates on the Mootools 1.2 plugin and when it will make it into Joomla 1.5.x?

Also - starting to look at squeezebox for the front end, Are there any inter dependencies between the new mootools 1.2 plugin and squeezebox (that comes with J1.5)?

I'd really like to avoid having us ship Kunena 1.6 with a custom set of mootools 1.2.x libraries. 

Thx!

Oliver

[Oliver Ratzesberger]

Ian,

Great to see the news about mootools making it into Joomla 1.5 as well in July!

We have been using the plugin for Kunena 1.6 since Jan/Feb this year with good success.

There is one thing I'd like to suggest for the final implementation:

Please run all of the js through the YUICompressor and include the -min files in the plugin. In normal non-debug mode load the -min files and when Joomla is in debug mode, load the non-minified js files. (Although firebug will display them both the same way, so debugging minimized css and js is really not a big deal).

minify:

[yui-compressor] [81%] moocompat.js [20421] ---> moocompat-min.js [16566]

[yui-compressor] [63%] mootools12.js [155924] ---> mootools12-min.js [98362]

If it is of any help: We have and ANT builder for Kunena that includes the YUICompressor tasks. Its a few lines of ANT code to make that happen automagically for every build.

Thx!

Oliver

On Feb 4, 2010, at 7:08 PM, Ian MacLennan wrote: