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
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.
>
>
>
> 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
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
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.
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
--
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.
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...
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
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
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.
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 »
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
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 »
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 »
I can see it here whether connected or not.
> ...
>
> plus de détails »
> ...
>
> read more »
> ...
>
> read more »
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.
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 »