Loading Mootools

[Ercan Özkaya]

Hi,

As you may already know Mootools has now separated plugins and serving
them as "more". As of Mootools 1.2.2 compressed file sizes are 64kb
for core and 94kb for more which takes us to the question how to
include them in Joomla.

I think we can make JHTMLBehavior::mootools() default to core and make
loading of more an optional parameter.

Another thing we can do to save a few bytes is creating three files
for Mootools: moo-core, moo-more, moo-more-joomla. Last one would only
contain plugins from moo-more needed by Joomla. And here is what
should happen for different calls:

JHTML::_('behavior.mootools') ---> only moo-core loaded.
JHTML::_('behavior.mootools', 'more') ---> moo-core and moo-more
loaded.
JHTML::_('behavior.mootools', 'joomla') ---> moo-core loaded. if moo-
more is not loaded moo-more-joomla is loaded. This way we could avoid
loading everything in more library unnecessarily and make backend a
bit faster for people who have low bandwidth.

What do you think?

[G. D. Speer]

Good thoughts - I'm wondering whether the Joomla option should be a single
file that combines core with the relevant more in a single file / single
http request.

Should we be doing the same to provide devs/users the option to load an
instance
of jQuery with a scriptlet for compatibility mode?

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



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.287 / Virus Database: 270.12.20/2100 - Release Date: 05/06/09
06:04:00

[MarcoBarbosa]

What a great suggestion..

I would take both opinions from Ercan and Speer :

JHTML::_('behavior.mootools') ---> only moo-core loaded.
JHTML::_('behavior.mootools', 'more') ---> moo-core and moo-more
loaded.
JHTML::_('behavior.mootools', 'joomla') ---> moo-core loaded. if moo-
more is not loaded moo-more-joomla is loaded.

Only ONE JHTML behavior.mootools is instantiated. So only one of
those, instead of mootools + mootools more, for example.
That way we can make one single file to make it just a single http
request like Speer suggested.

[Cristiano Cucco]

Hi,

has a method been foreseen to allow easy loading of other javascript framework (JQuery would be a more popular choice with respect to Mootools) at least in Joomla frontend ?

Thanks,

Cristiano

2009/5/7 MarcoBarbosa <malu...@gmail.com>

[Schalk Versteeg]

+1 for easy Jquery Loading (especially front end)

JHTML::_('behavior.jquery') 

JHTML::_('behavior.jquery', 'more')

(Easy Extensibility in regards with above format for other frameworks.)

[Gergő Erdősi]

I would imagine a similar method like jimport, which allows you to
load individual JS files, or a predefined set of JS files. For example
JHTML::_('behavior.mootools') would load the mootools.js file,
JHTML::_('behavior.calendar') would load the calendar, and
JHTML::_('behavior.joomla') would load joomla.js, which would be a new
file and this file would load all other JS files which are necessary
for Joomla. This way developers could easily load individual (3rd
party) JS files and load/create sets of (3rd party) JS files. Actually
I didn't think it through, just popped to my mind...

--
Gergő Erdősi
http://www.joomline.hu - Joomla! fejlesztői oldal


2009/5/7 Schalk Versteeg <schalk....@gmail.com>:

[Amy Stephen]

Good stuff, Gergő! If it is possible to continue this strategic thinking into also enabling easy JQuery access, I think that would make Joomla! remarkably flexible and able to utilize another amazing set of solutions out there. Thanks for your work.

2009/5/7 Gergő Erdősi <gergo....@gmail.com>

[Schalk Versteeg]

@Gergő: I Prefer the JHTML::_('behavior.jquery', 'calender') and JHTML::_('behavior.mootools', 'calender') 

which could be two different calenders used by two extensions, where with JHTML::_('behavior.calendar') you have a clash. (Might be resolvable with JHTML::_('behavior.mootools.calender')

2009/5/7 Gergő Erdősi <gergo....@gmail.com>

[Louis Landry]

You guys know you can use JHtml::addIncludePath() to override the JHtmlBehavior class altogether just as you can add JParameter element paths and JModel paths and so on.  With that you can have a JHtmlBehavior that implements the same methods but loads JQuery as the framework and relevant analogs for the other behaviors provided by the library, right?

It would take a system plugin that is like 10 lines of code long to do that, the hard part is making sure that you have JQuery analogs to all of the behaviors provided by JHtmlBehavior.

Having syntax like JHtml::_('behavior.jquery, 'calendar'); not only would break the JHtml design goal of having individual methods per HTML related actions, but it would also break the construct of having the JHtml calls be as generic as possible so that you don't have to modify the actual calls in layouts.  If you take that approach then every time you want to swap out javascript frameworks you have to touch every single layout or view that might call those methods to adjust them.

To that end I think we should change JHtml::_('behavior.mootools'); or more specifically JHtmlBehavior::mootools(); to JHtmlBehavior::framework();

- Louis

2009/5/7 Schalk Versteeg <schalk....@gmail.com>

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

[Ernest]

Currently there are third-party extensions attempting to install
multiple versions of the same javascript extensions into the header,
and sometimes unnecessarily do so on all served pages. After 300KB of
uncompressed files accumulated in the front page header. Also, the
javascript libraries are being installed into the print preview
window, which causes errors. This became a bit of a problem which I
thought about a great amount this last month.

Perhaps a JDOC-style statement in the header could help manager header
insertions. However, the order of header elements is important and the
availability of a JDOC style statement in the header could lead to
malfunction due to misordered code, and header code is mystical at
best. For example, there is is an erroneous statement in the joomla
library files that META tags should be at the top of the header,
presumably right after BASE. But that stops favicon from working in
IE, which requires the LINK statement to be first in the header, or
the favicon is ignored.

Now I think a new a module would be the best option. Perhaps the
module could be installed multiple times for different Javascript
libraries, and a module implementation would allow selection and
observation of which pages include which libraries in their headers.
That way, a Mootools 1.1 could be resident in one area of a site, and
Mootools 1.2 in another. Otherwise, components will end up installing
both libraries on the same page. The same problem has already occurred
for Jquery and Overlib. There is going to a messy transition while
some components continue to use the old libraries, and a module would
allow site management of such problems.

Also, the module would provide a centralized location for minimized
and zipped versions. My hosting provider does not allow compression of
CSS and JS files on the fly, which is a pretty common problem. So
currently, I rename javascript and css files to have php extensions,
thus they are passed through PHP Gzip compression, and put a PHP
header in them with the right mime type so the client interprets them
correctly, like this:

<?php ob_start ("ob_gzhandler");
header("Content-type: text/javascript");
header("Cache-Control: max-age=2592000");
//header("Cache-Control: must-revalidate");
?> /* <script> */....

Which is useful when developing new scripts. When the script is done,
hosting providers may appreciate a facility in Joomla to store
precompressed versions with the correct header information inserted,
thus reducing cpu load.

Are these good thoughts do you think?

[Amy Stephen]

Good point. Doing this with JQuery does not sound feasible for 1.6.

On Thu, May 7, 2009 at 9:42 AM, Louis Landry <louis....@joomla.org> wrote:

 If you take that approach then every time you want to swap out javascript frameworks you have to touch every single layout or view that might call those methods to adjust them.

- Louis

[G. D. Speer]

I wasn't suggesting replacing moo, just aggregating the needs for all extensions on the page and serving up one minified file that meets the combined needs -

any request for joomla plugins replaces the core file with the 

any request for other plugins replaces the core+joomlamore file with the core+completemore file

any request for jquery serves up the same file from above plus the jquery file modified with the setting that makes it coexist with mootools.

I don't understand the inner workings at Louis' level.  I'm just thinking some http rquests could be eliminated by server side concatenation or selection logic to significantly improve 'time to first page'.

 

I really see this logic being valuable with concatenating css files other than IE exceptions (and perhaps do the same thing for the ie exceptions)  - instead of several linked stylesheets, one link/one http request is used and on the server side, the respective reset, layout, typography and color/style parameter driven files are concatenated and minified before being served.  (perhaps with a debug option in global parameters that concatenates the files to one request without minifying).

 

Duke

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

Version: 8.5.287 / Virus Database: 270.12.21/2102 - Release Date: 05/07/09 05:57:00

[Ian MacLennan]

On Thu, May 7, 2009 at 10:55 AM, Ernest <mille...@comcast.net> wrote:

Currently there are third-party extensions attempting to install
multiple versions of the same javascript extensions into the header,
and sometimes unnecessarily do so on all served pages. After 300KB of
uncompressed files accumulated in the front page header. Also, the
javascript libraries are being installed into the print preview
window, which causes errors. This became a bit of a problem which I
thought about a great amount this last month.

Perhaps a JDOC-style statement in the header could help manager header
insertions. However, the order of header elements is important and the
availability of a JDOC style statement in the header could lead to
malfunction due to misordered code, and header code is mystical at
best. For example, there is is an erroneous statement in the joomla
library files that META tags should be at the top of the header,
presumably right after BASE. But that stops favicon from working in
IE, which requires the LINK statement to be first in the header, or
the favicon is ignored.

I don't think this is true.  At least it wasn't the case when I just tested.  Further, if a browser is stumbling because of the order of tags in the header (aside from code dependencies and CSS ordering), then the browser is broken since AFAIK there is no such requirement in the DTD.
 

Now I think a new a module would be the best option. Perhaps the
module could be installed multiple times for different Javascript
libraries, and a module implementation would allow selection and
observation of which pages include which libraries in their headers.
That way, a Mootools 1.1 could be resident in one area of a site, and
Mootools 1.2 in another. Otherwise, components will end up installing
both libraries on the same page. The same problem has already occurred
for Jquery and Overlib. There is going to a messy transition while
some components continue to use the old libraries, and a module would
allow site management of such problems.

A module seems like a terrible way to manage this.  Does this mean that you have to fiddle with modules to make sure they are properly assigned to the correct pages?  It also does not give you granularity for many third party components that may not have menu items for each page of the component and may not need the javascript library for each page.

The reason that mootools was specified as the library for J!1.5 was so that everybody was using the same library and this wouldn't happen.  Now, it is fine to try and use other libraries, but you can expect things to conflict.  Louis' suggestion, IMO, was a good one, because then you can, as a site developer, install a plugin that will override the mootools library.

A plugin architecture is the better way to go to leverage the infrastructure in JHTML.  This is not a perfect solution, since the idea with this would then be that JS libraries are drag and drop replaceable, and stuff is often library specific.  IME, there is not a good way to have two different libraries on the same page.

By doing this, the JHtml class can automatically resolve its dependencies so that scripts get added in the right order as well.

Configuring by page seems to be an unnecesarilly cumbersome process for site designers and seems prone to errors and issues.
 

Also, the module would provide a centralized location for minimized
and zipped versions. My hosting provider does not allow compression of
CSS and JS files on the fly, which is a pretty common problem. So
currently, I rename javascript and css files to have php extensions,
thus they are passed through PHP Gzip compression, and put a PHP
header in them with the right mime type so the client interprets them
correctly, like this:

<?php ob_start ("ob_gzhandler");
header("Content-type: text/javascript");
header("Cache-Control: max-age=2592000");
//header("Cache-Control: must-revalidate");
?> /* <script> */....

Which is useful when developing new scripts. When the script is done,
hosting providers may appreciate a facility in Joomla to store
precompressed versions with the correct header information inserted,
thus reducing cpu load.

Are these good thoughts do you think?

I think this is best served by a third party extension that would work in similar fashion described by Louis.

I should also add that hopefully the version issue is more of a one time thing and won't constantly be an issue.  In my understanding, the 1.1 to 1.2 shift broke a lot of things due to restructuring, whereas future version transitions should be smoother, similar to the move from J!1.0 to J!1.5 which broke a lot because there was a lot of crap to fix, but 1.5 to 1.6 should be relatively painless.

Ian

Ian

[Ercan Özkaya]

I made the first commit on this. Here is what I have done so far:
* Upgraded Mootools to 1.2.2
* Separated Mootools core and more (joomla file is waiting for
discussion)
* Deprecated JHtmlBehavior::mootools() in favor of
JHtmlBehavior::framework(). (Old method is still there for
compatibility)

I think loading mootools-joomla in one piece rather than two is a
better idea than mine. But here is the somewhat related problem:
Suppose that core and joomla is loaded. If someone calls more we
should take joomla out. But it's already in JDocument so only solution
I could think of was removing it from JDocument but this seems really
hacky. Any ideas on that end?

By the way I agree with Louis that loading other frameworks should be
done via third party extensions but loading another framework instead
of Mootools should be done carefully as most devs assume that Moo is
there and write code according to that.

On May 7, 8:24 pm, Ian MacLennan <ianlen...@gmail.com> wrote:

[Antti Tuppurainen]

Lets face the truth that there are several javascript frameworks out there and people love one and hate the other.

Personally I like what Joomla administration has done with mootools, but like the discussion about "xHTML Principles for layout" http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/18eab5c729998350?hl=en-GB has discussed the output of the core should be as clean as possible.

Adding mootools to jDocument has created so many hacks and workarounds and none of them works actually as they should widely in templates

http://www.blog.highub.com/cms/joomla-cms/remove-mootools-from-joomla-header/
http://extensions.joomla.org/extensions/style-&-design/scripts/7873/details
http://extensions.joomla.org/extensions/style-&-design/scripts/6981/details
<- This is one option to take for advance: Could it be option in core too. Load mootools from google

But as they are all plugins they work basically only on com_content pages and they are registered as onPrepareContent (conten plugins) or onAfterInitialise (system plugins)

I would prefer that mootools is taken away from jDocument and it could be handled via system plugin that has several parameters setted

1) which version of mootols
 - extras?
2) use google.load or local version
3) remove mootools
4) add another framework


Not every template needs extra javascript framework (even though it helps a lot)

One solution leads to another and loading lots of css and javascript to joomla core output head (via modules, via components, via template, via plugins etc) makes lots of request to server too. Why not give the system plugins option to combine those all loaded scripts and gZip and cache them like:
http://extensions.joomla.org/extensions/site-management/cache/7183/details

my thoughts, what do you think?

--
Antti Tuppurainen
Twitter: http://www.twitter.com/wroxbox
MediaWrox - http://www.mediawrox.com || Blog: http://antti.tuppurainen.fi

[Louis Landry]

Mootools is added to the document object (JDocument) in teh frontend of com_content calling JHtml::_('behavior.caption'); within its views.  This is what allows for the nice little image captions to be created unobtrusively.  The caption behavior in its current form is written for and thus requires Mootools, therefore the call to load the caption behavior implicitly loads the Mootools framework.

It doesn't take much to either remove the Mootools requirement for the caption behavior or move its loading into the layout -- where it belongs.  As I stated before, it wouldn't take much for you to have a system plugin to achieve that even now.

"Why not give the system plugins option to combine those all loaded scripts and gZip and cache them"

System plugins *can* do that.  There is nothing stopping a system plugin from doing that.  I have seen several of them that do something like that.

Pretty much all of the things you are asking for can happen with a quick little system plugin that does something like, 

<?php

/**

* @version $Id$

* @package Joomla

* @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.

* @license GNU/GPL, see LICENSE.php

*/

// no direct access

defined('_JEXEC') or die('Restricted access');

jimport('joomla.plugin.plugin');

/**

 * Joomla! JavaScript Plugin

 *

 * @package Joomla

 * @subpackage System

 */

class  plgSystemJavascript extends JPlugin

{

/**

* Constructor

*

* @access protected

* @param object $subject The object to observe

* @param array   $config  An array that holds the plugin configuration

* @since 1.0

*/

function plgSystemCache(& $subject, $config)

{

parent::__construct($subject, $config);

}

/**

* Load the custom JHtml helpers folder.

* 

* @access public

* @return void

* @since 1.0

*/

function onAfterInitialise()

{

// Only work for site applications.

$application = & JFactory::getApplication();

if($application->isAdmin()) {

return;

}

// Import the JHtml library.

jimport('joomla.html.html');

// Load the custom JHtml helpers folder.

JHtml::addIncludePath(JPATH_ROOT.'/plugins/system/javascript/html');

}

}

From there all you have to do is have a new JHtmlBehavior in your path that implements the same interface, like:

class JHTMLBehavior

{

function mootools($debug = null)

{

// Do logic to load JQuery framework.

}

function caption() {

// Do logic to load JQuery version of the caption behavior.

}

function formvalidation() {

// Do logic to load JQuery version of the form validation behavior.

}

... etc

Then your behavior class will be called, not the core one.  As for using the google service... same rules apply.  That could easily be handled via a system plugin.

- Louis

[Amy Stephen]

Thanks, Louis :-)

[Ron Severdia]

Likewise, I'd suggest adding a way to prevent mootools from loading.
Like the opposite of JHTML::_('behavior.mootools');

[Ian]

On May 7, 4:34 pm, Louis Landry <louis.lan...@joomla.org> wrote:
> It doesn't take much to either remove the Mootools requirement for the
> caption behavior or move its loading into the layout -- where it belongs.

To this end, I have submit feature patch 16346 (http://joomlacode.org/
gf/project/joomla/tracker/?
action=TrackerItemEdit&tracker_item_id=16346) which moves the loading
of behavior.caption from the controller to the layout. This allows
template developers to override this or do whatever they want without
hacking the core or even worrying about writing a system plugin so
long as they don't need anything too complicated.

Ian

[pollen8]

On 10 May, 20:09, Ron Severdia <ron.sever...@community.joomla.org>
wrote:

> Likewise, I'd suggest adding a way to prevent mootools from loading.
> Like the opposite of JHTML::_('behavior.mootools');

Bad idea in my opinion - what happens if a component sets this, and
then a module needs mootools?

I also am rather against allowing the loading of other libraries other
than mootools (although I guess this isnt even going to be really
applicable) - However, it is a constant headache for third party
developers (e.g. me :)) as I spend a considerable amount of time
having to support users who have included 2 or more js libraries in
their sites which cause all kinds of chaos. For the life of me I don't
understand why 3PD even use other frameworks, mootools is a good
solution!

[Antti Tuppurainen]

So the best solution is to add a system plugin that tells exactly what version to include (or what framework) or none. ?

--
Antti Tuppurainen
Ruotsinsalmenpolku 2 F 33
20240 Turku
+358 (0)44 5280 412
http://antti.tuppurainen.fi

[Ernest]

No, that is definitely not the best solution. The best solution is a
module, because plugins load on all pages, and two components could
use different versions of the same library. Modules however permit
selection of the pages on which they are loaded.

Here is what must be, I think, the ideal solution.

* The installer XML file has a new 'libraries' container element with
contains 'library' elements declaring which libraries the component
needs.

* Modules of type 'library' insert javascript into content pages
heads. They keep a record of which components need which libraries in
a database table. When an installer needs a new library, the system
creates a new module for it. When an installer needs a library already
installed, it is added to the records for an existing module.

3. When users opens a library module, the module displays on which
pages a library is being inserted into a content page head. It also
displays the pages on which it thinks the library is required. The
user gets a warning dialog if trying to deactivate a library on a page
which the system thinks the library is needed.

That way, legacy components can coexist with new components and not
have library conflicts.

[Rob Schley]

The whole point of including a JavaScript framework in the core was to avoid these problems. There are already a thousand variables that have to be considered when building 3rd party extensions, why are you guys so set on making it even more complicated? If everyone were to just stick with the core provided JavaScript, MooTools, we wouldn't have to worry about conflicts, multiple versions, etc. You would load one framework and everything would just work. That sounds like the ideal solution.

If you're going to hijack the JHtml loader, you are going to cause countless other problems with other extensions. You might support all JQuery but some other modules on the page might support all MooTools. Okay, well, who's problem is that? Yours? The other developers? The users? You're creating a headache for everyone involved when it is unnecessary.

If you really like something that was released for JQuery, chances are it is available for MooTools or it could be ported without too much fuss. Have you guys seen the new MooTools More? http://mootools.net/blog/2009/03/09/more-to-love/#more-155

I am in favor of the solution that causes the least amount of headaches all the way around. Use MooTools.

Rob

[Louis Landry]

Rob is absolutely correct regarding the rationale behind choosing and including a JavaScript framework in the core.  Third party developers should be building everything to work with the core JavaScript framework.  Thats what it means to actually build a Joomla Native extension, to build something that is native to the Joomla APIs and systems.  That includes the JavaScript framework that ships with the core.

The rationale for hijacking the JHtml loader is an extreme case and would require that whomever is doing the hijacking not only knows what they are doing, but also that they know the JavaScript requirements for the site in question.  This is something that someone building a site should look into assuming their requirements aren't met by MooTools, not by third party extension developers just for the sake of doing it.

Ultimately people should be using the core framework, but as I illustrated earlier... for site implementors there is capacity for not having to "hack" the core to achieve your goals.

- Louis

[Schalk Versteeg]

Hi,

I was one of the people who would've loved seeing jquery in joomla, I would've loved being able to use jquery rather than mootools in joomla (the J of jquery also sounded like a better fit) but I am also a big fan of stability and maintainability. If maintainability means I need to learn a new framework (mootools) let it be. If it means porting a jquery plugin to mootools, let it be. I will be the richer for knowing two frameworks. 

Now please point me to good tutorials for learning mootools, also ajax via mootools. 

Also let's hear from the other jquery fans what they need in mootools and see if we can assist them in finding it.

ns. Please don't try to convert me into mootools only but for  Joomla it will be mootools for now.

[Ernest]

On 14 May, 16:13, Louis Landry <louis.lan...@joomla.org> wrote:
> Rob is absolutely correct regarding the rationale behind choosing and
> including a JavaScript framework in the core.  Third party developers

> shouldbe building everything to work with the core JavaScript
> framework.

If that's the intent, then the MooTools version should never change.
In the ideal world, it would be an instantaneous fix to change a
library, but in reality it takes work which developers won't all do at
once, and they may have stopped updating some extensions which means
they will be loading the old library. Once you add a library to a
framework, this is the kind of problem you have to take into account.

In the ideal world, bandwitdh would be unlimited. I didn't know
Mootools was added to Joomla when I first upgraded to Joomla 1.5, and
some of my customers who are on modems experienced delays of >40
seconds on accessing the site while the libraries loaded. That was not
acceptable to them and I lost quite a bit of business. That's why I
asked to be able to contribute to the 1.6 release, to speak for people
like those on slow modems who now wish me to stop using Joomla
altogether. So I need to be able to disable Mootools at least on my
home page. Are you intending that people like me stop using Joomla?

[Amy Stephen]

On Thu, May 14, 2009 at 6:13 PM, Louis Landry <louis....@joomla.org> wrote:

Ultimately people should be using the core framework, but as I illustrated earlier... for site implementors there is capacity for not having to "hack" the core to achieve your goals.

- Louis

This is ideal and it's great that Joomla! is flexible.

Joomla! offers a powerful JS framework with Mootools that is available and recommended for our use.

Those who need to use JQuery can do so without hacking core.

Perfect.

[Amy Stephen]

On Fri, May 15, 2009 at 7:26 AM, Ernest <mille...@comcast.net> wrote:

Are you intending that people like me stop using Joomla?

Absolutely not! Lots of hard work is going into Joomla! to make the best solution possible for as many people as possible.  It looks like you should also be able to achieve your goals if those goals include JQuery.

[Ernest]

> Lots of hard work is going into Joomla! to make the best
> solution possible for as many people as possible.  It looks like you should
> also be able to achieve your goals if those goals include JQuery.

Well I'm glad to hear that and appreciate the hard work. I also would
like Joomla to succeed. But there is no way to enforce standardization
on one library. Here are two cases:

* Fireboard/Junena is the only forum which is fully integrated with
the Joomla user system. It is VERY difficult to upgrade Fireboard and
Junena installations. Legacy forum installations will inevitably
continue to use legacy Jquery libraries.

* Community Builder is one of the most popular CMS extensions on the
Web. It runs on multiple types of CMS . It could be very difficult for
Community Builder to support a different library on different systems.
Also site managers may be reluctant to change their installations and
risk corrupt their data.

So the fact is, there will many administrators needing to use
different libraries. And MooTools could change again and get better
again in the future. Standardizing on one library without giving
administrator access to its loading on different pages freezes out
developers who want to take advantage of new libraries.

A header directive of the form <Jdoc include="headers"> which merges
all header includes from header modules would let the core control the
order of library loading in the header, and remove the loading of the
same library at different paths. Also it would provide administrators
with the ability to set whether libraries are compressed or minimized.
Some extensions don't work well with minimized libraries, and some
hosting providers have special needs for compressing javascript and
css files.

Such a header module could also configure the inclusion of different
CSS files. To improve load time, I merge all CSS files into one file
and compress it in advance. But to do so, I have to go through each
extension, find their header include directives, and comment them out
manually. It would make alot more sense to extend the 'header module'
include to support CSS files also. That would enable administrators to
select which CSS files get loaded from the standard Joomla interface,
and if they customize CSS files, easily stop the third-party CSS files
from loading. Currently, there is no standard way to support that in
Joomla, and extensions needing CSS files all manage them in different
ways. So, can you see why a header module would be much better way to
do things, and how it would help people manage different libraries in
their systems?

Personally, I would like very much to have a fast loading Joomla like
version 1.0 was, which users liked very much.

[Ernest]

The other problem I intended to indicate was the loading of libraries
into windows which shouldn't get them. These include RSS and print
preview windows.

A <Jdoc:include> directive in the header, which integrates the header
includes and inserts them in the right order, could also be excluded
from component templates for RSS and print preview. So for example the
header could look like this:

<jdoc:include type="modules" name="header" style="XHTML"/>
<jdoc:include type="modules" name="header" style="HTML4"/>
<jdoc:include type="modules" name="header" style="Print"/>
<jdoc:include type="modules" name="header" style="RSS"/>

Thus permitting the loading of different header files depending on the
DTD and window type, while still letting administrators manage which
libraries and CSS files are loaded, and still letting the core manage
the library loading order. What could be better?

[Amy Stephen]

Ernest -

I am wondering - do you know how to prevent Mootools from loading? We can (even now) add these statements within our Template - right at the top - and Mootools will not load:

<?php
$headerScripts = $this->getHeadData();
$headerScripts ['scripts'] = array();
$this->setHeadData($headerScripts);
?>

Also, I have a JS and CSS Minifier that I released for testing -- if you want, I'd appreciate if you checked it out and see if it helps with the load time issues (without manual intervention):

http://tamka.org/amystephen/tamka-css-and-js-minifier

I think those two things might be helpful to you.

Kind regards,
Amy :)

[Amy Stephen]

I love all of these ideas. It might make sense to start another thread for non-Mootools discussions, though. It does get difficult to follow when too many topics are presented.

Thanks Ernest!
Amy :)

[dukeofgaming]

To Schalk and others who wish to try to get into the mootools framework, the right direction used to be the demos and documentation itself, but when mootools 1.2 came, IMHO, the documentation's quality and usability decreased.

The right direction right now would be the Mootools Essentials book by Aaron Newton (there is another book coming), along with that and the official documentation I'd suggest to look at the mootorial, the clientcide mootools plugins demos, digitarald's projects and playground, and finally check out the code of a very cool project called MochaUI.

To Ernest, have you looked at the JFusion project?, I run a community of 2000+ users and I quickly discarded Fireboard as a solution since the first time I tried it, used it for other small projects though, but now with JFusion I'm already migrating those solutions.

I personally loved mootools at first sight for its simplicity and elegance since a long time ago, however I'm sure at some point I'll need to use other libraries and will need to move mootools aside for a while; I don't really think Joomla should force mootools, but encourage its use with some sort of standard.

I really like the module solution btw.

On Fri, May 15, 2009 at 8:15 AM, Ernest <mille...@comcast.net> wrote:

[Ernest]

> I am wondering - do you know how to prevent Mootools from loading? We can
> (even now) add these statements within our Template - right at the top - and
> Mootools will not load:

....

> Also, I have a JS and CSS Minifier that I released for testing -- if you
> want, I'd appreciate if you checked it out and see if it helps with the load
> time issues (without manual intervention):
>

Thank you very much. Sadly I already lost two weeks rewriting core and
extension PHP code so it would work somewhat. I'm still having a few
problems with print preview and RSS publishing. For compressin, there
is a very easy way to do it on many systems, by saving the .JS and CSS
files as PHP files and adding the following to the top of the file:

<?php ob_start ("ob_gzhandler");
header("Content-type: text/javascript");

header("Cache-Control: max-age=25920");

//header("Cache-Control: must-revalidate");?>

or

<?php ob_start ("ob_gzhandler");

header("Content-type: text/css");
header("Cache-Control: max-age=25920");

//header("Cache-Control: must-revalidate");?>

I'm told some libraries use indexing into file position in which case
minification doesn't work for them, but the above technique still
does, and generally gets better 20-30% better compression on an
uniminifed file than minification without compression. Of course the
ideal case is both miniification and compression. There are issues
with compression too: it affects load order, as compressed files are
deferred in load order, so sometimes calls to uncompressed files need
to have their include directive modified to include a defer attribute:

$myUrl=$mainframe->getCfg('live_site') .'/templates/' . $this-
>template ;
php echo '= '<script src="'.$myUrl.'/mootools.js"
language="javascript" type="text/javascript" defer="defer"></script>';

Do you think it would be possible to make these options in a header
module, as to whether the file is minimized or compressed, in a module
interface, so administrators could configure them for their particular
environments and extensions?

[Schalk Versteeg]

Thanks @dukeo for the info on learning mootools.

I also like the module solution, as also like jquery a lot.

[Ian MacLennan]

Well, the issue with that is that currently com_content loads behavior.caption in the controller.  This is the wrong place, IMO, and I submitted a patch above that would push this out into the layouts.

IMO, as long as there is an extension on the page that needs mootools, then mootools should be loaded.

If the site administrator needs an extension that uses some javascript that conflicts with the mootools library, then they are free to use that extension, but then they should make sure that only components and modules that do not need mootools get loaded on that page.

mootools is not loaded on every page view in Joomla!, but only on pages where some extension needs it.

Thus, I think it is incumbent on site administrators who absolutely need to use extensions that conflict with mootools to do their research and to not mix these extensions on pages.

Ian

[Ernest]

> Thus, I think it is incumbent on site administrators who absolutely need to
> use extensions that conflict with mootools to do their research and to not
> mix these extensions on pages.
> Ian
>

I appreciate the sentiment, Ian, but I cannot be so lordly as to
dictate what other developers must do with their software. Sometimes
Joomla decides to load Mootools when it's not wanted, the only way to
stop it at the moment is to add conditional directives in PHPor hack
the core.

Amy wrote:
> am wondering - do you know how to prevent Mootools from loading? We can
> (even now) add these statements within our Template - right at the top - and

> Mootools will not load: <?php

> $headerScripts = $this->getHeadData();
> $headerScripts ['scripts'] = array();
> $this->setHeadData($headerScripts);
> ?>

Yes, but it doesn't work very well. The best I found was a plugin
someone wrote to stop mootools from loading, and also select the
library. It was a big help to me, but I had to rewrite it a little so
mootools would still load for the admin interface in the backend:

<?php
// More info at http://www.kinesphere.fr

defined( '_JEXEC' ) or die( 'Restricted access' );

class plgSystemki_mootools_control extends JPlugin{
function plgSystemki_mootools_control( &$subject ){
parent::__construct( $subject );
// load plugin parameters
$this->_plugin = JPluginHelper::getPlugin( 'system',
'ki_mootools_control' );
$this->_params = new JParameter( $this->_plugin->params );
}
function onPrepareContent(&$row, &$params, $limitstart) {
global $mainframe;
$plugin =& JPluginHelper::getPlugin('system',
'ki_mootools_control');
$pluginParams = new JParameter( $plugin->params );
$mosConfig_absolute_path = JPATH_SITE;
$mosConfig_live_site = $mainframe->isAdmin() ? $mainframe-
>getSiteURL() : JURI::base();
if(substr($mosConfig_live_site, -1)=="/") $mosConfig_live_site =
substr($mosConfig_live_site, 0, -1);
$dossier = $pluginParams->get('ki_mootools_control_ch_mootools',
'media/mootools-MOO.js');
$no_mootools = $pluginParams->get('ki_mootools_control_mootools',
'1');
$no_caption = $pluginParams->get('ki_mootools_control_caption',
'1');
$new_mootools = $pluginParams->get('ki_mootools_control_remp',
'1');
// on vérifie un peu l'adresse du dossier
if (!preg_match("#.js$#", $dossier)) $dossier_ok = 0;
else $dossier_ok = 1;
if (preg_match("#^/#", $dossier)) $dossier = preg_replace('#^/(.+)
#i', '$1', $dossier);
// Ajout du CSS & du JS
_______________________________________________________________________
$user = &JFactory::getUser ();

if ($user->get( 'usertype') != "Super Administrator") {
// if ($user->get( 'guest') == 1) {
$moo = "";
$cap = "";

if ($no_mootools == 1 || $no_caption == 1) {
$doc =& JFactory::getDocument();
$headerstuff = $doc->getHeadData();
foreach ($headerstuff['scripts'] as $adresse => $type) {
if (preg_match("#mootools.js#s", $adresse)) $moo = $adresse;
if (preg_match("#caption.js#s", $adresse)) $cap = $adresse;
}
if ($no_caption == 1 && $no_mootools == 1) {
unset($headerstuff['scripts'][$cap]);
unset($headerstuff['scripts'][$moo]);
}
elseif ($no_caption == 1) unset($headerstuff['scripts'][$cap]);
else unset($headerstuff['scripts'][$moo]);
$doc->setHeadData($headerstuff);
}
}
if ( $new_mootools == 1 && $dossier_ok == 1) {
$doc =&JFactory::getDocument();
$headerstuff = $doc->getHeadData();
reset($headerstuff['scripts']);
$moo = key($headerstuff['scripts']);
unset($headerstuff['scripts'][$moo]);
$headerstuff['scripts'][JURI::base( true )."/".$dossier] = "text/
javascript";
$doc->setHeadData($headerstuff);
}
}
}
?>

[Ian MacLennan]

On Fri, May 15, 2009 at 10:18 AM, Ernest <mille...@comcast.net> wrote:

I appreciate the sentiment, Ian, but I cannot be so lordly as to
dictate what other developers must do with their software. Sometimes
Joomla decides to load Mootools when it's not wanted, the only way to
stop it at the moment is to add conditional directives in PHPor hack
the core.

Which circumstances are these?  Mootools is only loaded on the frontend when an extension requires it.

Ian

[pollen8]

Google? :)
http://mootorial.com/wiki/

[Ernest]

ok, here's an example. say a plugin is loaded on onpreparecontent()
which has lightbox for any images on the page (this is something that
multithumb is struggling with at the moment, you can see here:

http://www.kreacom.dk/mambots/multithumb-for-joomla-15.html

Multithumb looks for any images in articles, caches thumbnails of
them, and adds a lightbox to them: it's pretty neat! it is by far the
best program I have fouhnd for managing content images. But my site
only had one part of it that needed lightbox, which only a subset of
my customers wanted to see. The developer is trying to rewrite it for
1.5, but it's very difficult. Meanwhile. there is a 1.0 version which
runs in legacy mode. However, Lightbox conflicts with MooTools.

If users are on cable connections, I still would like MooTools on
provide popups for captions and links, on hte pages where Multithumb
is not loading. But if there are any captions or links on the page,
MooTools loads automatically and causes a . Obviously, the images
which Multithumb processes has captions, but there is no way to
control MooTools loading selectively on some pages without writing
extensive conditional PHP directives, which is beyond the ability of
most administrators, and time consuming for me.

If users are on modems, I'd like to give them an option in Community
Builder to disable MooTools and get no popups. In fact, I'd rather
have MooTools disabled by default and let users *enable* it with
Community Builder, because people browsing to my site have to wait so
long for it to load, they think that it's gone away and leave. If
there was a core API for conditional loading of libraries, I could
make a CB plugin for that.

But at the more abstract level, don't you agree it would be good to
provide administrators with a UI which allowed observation and control
of which libraries are loaded on which pages? This technique of making
a module can be generalized to all libraries and stylesheets, and the
CMS could provide alerts to administrators that components or plugins
require particular libraries if the user attempts to disable them in
places where they could provide useful enhancement to the user
experience.

[Ernest]

To summarize some of the responses I have been given to my problems:

* Use another forum instead of Kunena/Fireboard (two weeks work).

* Mandate all developers rewrite their code to use the libraries you
have decided they must use.Don't use plugins that don't work because
they haven't been rewritten (another month's work).

* Entirely ignore the fact that libraries are loaded into RSS feeds
and Print preview windows, which causes problems in RSS readers and
printers (printing and RSS feeds are now disabled).

* Tell my customers on modems to get a faster connection if they want
to use my website. Ignore the 300KB of different libraries and >30
different CSS files my site now needs to load because there is no
unified way to manage it.

Anything else you want to tell us old Joomla folks we are doing wrong?
Seems like we're not really wanted and should use another CMS
instead.

[Stian Didriksen]

We need to think what's better for everyone.
This is a huge overkill compared to the real benefit.

The decision on wether or not to load Mootools, or any other framework
for that matter, is not a decision made for the webmaster to take.
The framework does nothing if not used, nor load if not called.
So if it loads, its NEEDED.
You don't disable something that's not even enabled unless its
actually IN USE.

If the extension loads something you don't want, don't use the
extension. If you consider people still on modem as important,
Mootools is not your problem.
The extension using it is. What you want is an option that let users
disable or enable plugins depending on a cb setting.
I really don't see where Joomla and Mootools comes into the picture.

You want an conditional for loading Mootools or not in the plugin, not
core.
I don't really see any benefit at all by adding the API you describe.
Reason why I don't, is that as a developer I can't see any reason why
I would ever want to disable Mootools for extensions that needs it.
The right thing to do, is to allow users to disable/enable specific
features that require mootools (or javascript in general) on an
extension level, not system level.

Regards,
Stian

[Ian MacLennan]

See comments inline...

On Fri, May 15, 2009 at 11:15 AM, Ernest <mille...@comcast.net> wrote:

To summarize some of the responses I have been given to my problems:

* Use another forum instead of Kunena/Fireboard (two weeks work).

I don't have any experience with that, so I can't comment.
 

* Mandate all developers rewrite their code to use the libraries you
have decided they must use.Don't use plugins that don't work because
they haven't been rewritten (another month's work).

Well, we have recognized the fact that most of the time if you get enough different javascript libraries loading on one page, problems are likely to occur.  As a result, we have made the statement that the standard library for Joomla! extensions in mootools.  This is in the hope of defining a library that extension libraries can count on being able to use and if they do so, it will make the job of the site administrator much easier because they don't have to worry about deciding which extensions to use based on whether or not they have incompatible libraries.

* Entirely ignore the fact that libraries are loaded into RSS feeds
and Print preview windows, which causes problems in RSS readers and
printers (printing and RSS feeds are now disabled).

In my experience, this is just not true.  libraries are certainly not included in RSS feeds because this would mean that the feeds would not validate, and we put a great deal of effort into making sure that feeds do validate.

Further, I've never seen evidence of the javascript libraries causing problems for printers.
 

* Tell my customers on modems to get a faster connection if they want
to use my website. Ignore the 300KB of different libraries and >30
different CSS files my site now needs to load because there is no
unified way to manage it.

No, that was not what was said.  Louis explained a method of preventing mootools from being loaded by inserting a new behavior.php file into the JHTML load chain.  By doing so, you could quite easily replace the code that loads the mootools library with code that does nothing.  If somebody chooses to do this, it is their responibility to be aware of the consequences.

Further, Louis mentioned moving the behavior.mootools and behavior.caption calls into the layout.  This would have the benefit of template developers being able to override parts of extensions that use things like javascript calendars etc so that they can make a lighter weight template.  You could currently do this for com_content by creating a controller override as suggested in an article by Anthony Ferrara on, I believe, community.joomla.org.

As to your comments about wanting options in extensions to make it possible to have mootools free output, that I would think would be something you would do at the extension level.  I would suggest contacting the extension developer to suggest such a feature, as it may be helpful for others too.  I would also ask them to make sure they load their libraries from their layouts so that template developers can override them if they really feel the need.

Ian

[Louis Landry]

Ernest,

No one is telling you what to do with your problems, this is not a support forum.  What we are discussing is the core CMS development.  You seem exceedingly frustrated and angry that not everyone is agreeing with you, but that is just the way things go.

MooTools was chosen as the JavaScript framework for Joomla a long time ago... years ago.  Kunena does use JQuery, and yes I believe they should be using MooTools.  I also believe there is a good chance they will do just that as time goes on.

We don't mandate use of our libraries, but I do differentiate between something actually written for Joomla as a native extension and something that hasn't.  One of the major advantages of choosing Joomla native extensions that do use the libraries we provide is that you have a high probability of them all working together nicely.  That is why we do provide a standard and why we made a choice to begin with, again years ago.

What you describe with feeds and print screens could be described as a bug and you should report it as such on the bug tracker if that is in fact the case.  Certainly loading for the feeds.  I can tell you that for my sites the behavior you describe for at least feeds doesn't exist.  I actually wonder if that might be a byproduct of a workaround plugin you are using.

http://www.joomla.org/announcements.html

http://www.joomla.org/announcements.feed

I don't see how any JavaScript is being loaded for the feeds, and there is nothing fancy about those pages on that site.

You also talk about 300k of libraries and CSS, the MooTools that ships with Joomla 1.5 is 73k.  Certainly we would like that to be smaller, but its not.  It is also cached after the first request in modern browsers so that you aren't transferring it over and over again.

If you are just looking to consolidate all of those things into a singular request for JavaScript and a singular one for CSS which is compressed, there may be a plugin out there for that -- I don't know, though I think that is what Amy was talking about -- and that would be something interesting worth exploring for the core.  That has nothing to do with JavaScript conflicts though, or extension developers choosing to use things other than the core libraries.

I imagine there are a lot of "old Joomla folks" doing a lot of things wrong... I suspect I am even one of them from time to time... disagreement doesn't necessarily mean unwelcomeness though.

- Louis

[Stian Didriksen]

Speaking as a developer, I can see many places where Joomla could be
improved, when we're talking about Mootools. I for one would like to
see a little more flexibility.
Like Ians patch, where the JHTML call is moved from the controller to
the view. Most of the issues described in this thread are not about
Joomla at all.
Problems regarding javascript conflicts are not a matter for the core
developers to handle.
I'm a jQuery lover, and I use jQuery for projects where Mootools isn't
fit for the job (like when event delegations come in handy, which is
better done by jQuery as it don't require another plugin for that.)
But jQuery provide several solutions to prevent conflicts with other
libraries. So if there's a conflict on your site, the developer on the
module that use jQuery haven't done his job.

Load times are not an issue either. The site still works, even if it
takes longer to load. Adding options to disable scripts on a user
level is an feature, not a bugfix.

I say we must focus first and foremost on features and improvements
that is beneficial to the larger crowd. And some needs to stop trying
to create problems out of features missing.

If you got customers on a modem, you should invest in a template done
for them. If they don't bring you enough income to support it, I don't
see why others should invest more from their time for features that is
silly in my opinion.
If you want to disable a specific feature or function, need I tell you
no to enable it in the first place?

[Ernest]

I can't speak for 1.6, but on Joomla 1.5 MooTools loads on all pages,
including print preview and RSS feed windows. This causes JavaScript
errors when other scripts have properly been removed from such pages.

Of course, we can agree to disagree. I only speak for the several
hundred developers and >1 million websites on servers which are having
performance problems and content conflicts with the current
implementation and policy. You are free to decide we are all wrong.

[Stian Didriksen]

I would like to see those hundred of developers that think Joomla is
wrong for choosing Mootools.
I think jQuery is best most of the time for my projects. But back in
the days when the core devs took their decision, there really was no
better alternate to Mootools.
And it would be a huge mistake to change the core framework in a patch
as it would require everyone to recode their javascript to remain
compatible with the core.
And the performance issues and conflicts you describe rely solely on
you and whichever extensions you may choose to load on your sites.
I don't see any performance problems and certainly not js conflicts on
a clean Joomla install with no 3rd party extensions on it.

And since that's the status, whichever problems you get from a 3rd
party extension is your and the 3rd party developers problem.
I can't understand why you think this is the core developers problem.
And why you consider this a matter of right and wrong.
You are free to modify Joomla to whatever you want. That's one of the
benefits with GPL. If you want scripts removed, remove them.
So why should thousands of developers have increased workload to adapt
to your requests, just so you wont have to do it yourself?

[Amy Stephen]

On Fri, May 15, 2009 at 11:07 AM, Ernest <mille...@comcast.net> wrote:

Of course, we can agree to disagree. I only speak for the several
hundred developers and >1 million websites on servers which are having
performance problems and content conflicts with the current
implementation and policy. You are free to decide we are all wrong.

Ernest -

We each speak only for ourselves. You do not speak for anyone else, let alone "hundreds of developers" and it is not appreciated that this important discussion be derailed into a battle.

You were provided a CSS / JS minifier - personally, I do not recommend you hack core to get that effect, but you are free to do so if you choose!

You were given at least two ways to not load Mootools. You are recommended to use Mootools, but you don't have to do so. You can use JQuery without hacking core.

I am honestly not at all certain what you see as a problem.

Take some time to think this through, please. Then, if you still see a problem, please articulate that problem without the "fighting words." We are much more likely to be able to help you find a satisfactory solution -- and we *want* to help. Give it a couple of days, though, I think.

With respect,
Amy :)
 

[G. D. Speer]

I am missing the assumptions -

What part of Joomla core actually uses mootools?  Captions and what else?

For each,

Is that a dependancy or if Behavior Mootools is not called, does it degrade to a non-mootool equivalent?

Does it require the moo more plugins or just the core mootools?  If so, which more plugins?

Thanks for clarifying.

 

---

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.325 / Virus Database: 270.12.30/2115 - Release Date: 05/14/09 17:54:00

[Ian MacLennan]

On Fri, May 15, 2009 at 12:07 PM, Ernest <mille...@comcast.net> wrote:

I can't speak for 1.6, but on Joomla 1.5 MooTools loads on all pages,
including print preview and RSS feed windows. This causes JavaScript
errors when other scripts have properly been removed from such pages.

If it is the case that Mootools is loading in RSS feeds, then please submit a bug report and I'll have our people at JBS take a look at it.  I've certainly never seen this happen and based on my knowledge of the Joomla! framework and architecture.  It certainly does not happen on www.joomla.org, toronto.joomla.org (http://www.joomla.org/announcements.feed, toronto.joomla.ca/index.php?format=feed&amp;type=rss) or in any of the feeds that have been submitted at connect.joomla.org: http://www.phoca.cz/news?format=feed&type=rss, http://feeds2.feedburner.com/ayudajoomla, http://feeds.joomlacommunity.eu/joomlacommunity).

If you can provide a link to a feed generated by Joomla! that does exhibit this problem, please submit a bug at joomlacode.org and we'll get it fixed up in the next release.

As for print preview, I would assume that if somebody wants to print a page then they would want to print the captions as well.  In that case, mootools is required.

I don't really see the problem with loading mootools for print preview, because I've never seen an issue with it (and if it does create a problem, please submit a description of the problem on the tracker and we will investigate it and deal with it accordingly).  This certainly shouldn't hurt load time, because one would assume if somebody is doing a print preview they have already viewed the article and thus mootools is already in their browser's cache.

Ian

 

[Ernest]

I formally propose a new module of type HEADER. This module would
provide observation and control of javascript libraries and CSS files
in the HTML and HTTP header. It would provide notification to the core
that an extension has a possible library conflict and allow the core
to manage the order of elements inserted into the header. It would be
inserted into templates.

Templates include all modules of type HEADER with a single JDOC
directive with the following alternate forms:

<jdoc:include type="headers" style="xhtml"/>
<jdoc:include type="headers" style="html4"/>
<jdoc:include type="headers" style="print"/>
<jdoc:include type="headers" style="rss"/>

The 1.6 installation would provide a preinstalled header module for
mootools v1.2, published at ACL public for all pages.

OPTIONS

The Header Module would provide the following options by default:

Compression:
* Precompressed
* Compressed (as php)
* Uncompressed

Minification:
* Unminified
* Minified

Caching:
* On (max-age: 1 week)
* On (max-age: 1 month)
* Must Revalidate
* Off
* Other ___________

Deferred (JavaScript modules only):
* immediate
* deferred execution (adds 'defer="defer" attribute)
* other: ____________

Media (for CSS only):
* All
* CSS
* Print
* Other _____________


The module could be included automatically on new installs via a new
XML <headers> container in the installer, with indicated default
attributes:

<headers>
<header type="javascript" [compressed="yes"] [minified="yes"]
[defer='defer"] [cached="no"] >file.js</header>
<header type="css" [compressed="yes"] [minified="yes"] [cached=yes]
[style="all"]> file.css</header>
</headers>

Calls to AddCustomHead() would be routed through the core module
code.

Administrators would be able to install and uninstall additional
header modules, and receive alerts when conflicts occur between
libraries. They would have the option to override defaults, with the
following exceptions:

* 1.2 Mootools module cannot be uninstalled
* 1.2 Mootools must be enabled for users with back-end access.

{end}

[Ernest]

And now I am sorry, but I have lost several thousand dollars from lost
customers and the time taken to upgrade to Joomla 1.5, so I won't be
able to put very much more time into this discussion, but I will try
to contribute what I can.

[Amy Stephen]

Ernest -

As a gentle reminder about process. If we have features requests, we are asked to submit those ideas to the Whitepaper forums. http://forum.joomla.org/viewforum.php?f=500

There are a number of code implications with the ideas you presented. It is more likely that our ideas will be considered if we submit a feature patch that has provided for those implications. We have been provided instructions for how we can submit feature patches, too. http://developer.joomla.org/policies/feature-patches.html

Please consider doing that as I think some of your ideas have merit. One of the benefits to opening up development is that we can each help direct Joomla! in ways that are important to us -- provided we are also willing to help action those ideas into code and learn to work together, as a community.

There is a tradeoff to contributing that does sometimes have a financial cost with it. We need to remember, though, that no one knows that cost better than the developers who have been coding for us at no charge for years.

Have a great weekend, Ernest, thanks for getting involved!
Amy :)

[Ernest]

Hey, someone asked where would be the best place to put mootools, and
I answered the question. I don't have any incentive to mandate that
only one library be formally supported in Joomla. As an open-source
initiative it is strange to me that some developers are implementing a
new version which only supports one library, especially since there
are many reasonable alternatives which will suffer as a result. The
statement that it is to every one's benefit to use the preselected
library is in my opinion, shotsighted. Third-party developers have no
reason to agree with the choice, and the chosen architecture will
present further problems the next time Joomla wants to change its core
library. The argument that standardization on one library benefits
people in the end is not sufficient, in my opinion, to warrant a
closed architecture that locks out alternatives, imposes difficulties
on upgrading, makes it difficult for developers to transition to the
new system, makes Joomla unnecessarily slower, and require core
customization to affect proper handling of header files.

A module approach would let developers switch to the recommended
library and test it simply by publishing and unpublishing a module for
the content pages in transition. It would place observability and
control in the hands of the administrator. I presented many other
benefits for the module approach, and illustrated how a header module
could provide standardized access and easier integration for CSS files
too.

It's going to be some time before I have the experience in Joomla APIs
to write an efficient impleemntation myself. I only starrted on the
transition to Joomla six weeks ago, and I only have about 600 total
hours experience with the new APIs.
Hopefully I will be able to gain more experience in the APIs and
contribute white papers and core source worthy of sharing under
employment of an independent third party that places the future
wellbeing of the CMS above any particular implementation choice.

And I totally open to any suggestions as to how the module API and
administraiotn interface would make the CMS more open, more
extensible, and easier for administrators to deploy with whatever
third-party extensions they choose.

[dukeofgaming]

<somewhat-off-topic>

Hi, this just popped into my Twitter and I thought immediately of the JQuery folk around here  wanting to get into mootools: http://jqueryvsmootools.com/

</somewhat-off-topic>

[Adrian Rosian]

Hello, Schalk
I am not a very advanced JavascriptDeveloper, but I found these links
to be very useful. You will certainly love mooTools for the simplicity
and flexibility.

http://demos111.mootools.net/Drag.Absolutely
http://mootorial.com/
http://walkthrough.ifupdown.com/walkthrough-1.2/start

I do agree too with Rob, keep things simple, this is what ensures
stability.

Adrian
http://www.treidorinte.ro


On May 15, 10:13 am, Schalk Versteeg <schalk.verst...@gmail.com>
wrote:
> Hi,I was one of the people who would've loved seeing jquery in joomla, I
> would've loved being able to use jquery rather than mootools in joomla (the
> J of jquery also sounded like a better fit) but I am also a big fan of
> stability and maintainability. If maintainability means I need to learn a
> new framework (mootools) let it be. If it means porting a jquery plugin to
> mootools, let it be. I will be the richer for knowing two frameworks.

>
> Now please point me to good tutorials for learning mootools, also ajax via
> mootools.
>

> Also let's hear from the other jquery fans what they need in mootools and
> see if we can assist them in finding it.
> ns. Please don't try to convert me into mootools only but for  Joomla it
> will be mootools for now.
>
> On Fri, May 15, 2009 at 1:13 AM, Louis Landry <louis.lan...@joomla.org>wrote:
>
> > Rob is absolutely correct regarding the rationale behind choosing and
> > including a JavaScript framework in the core.  Third party developers
> > should be building everything to work with the core JavaScript framework.
> >  Thats what it means to actually build a Joomla Native extension, to build
> > something that is native to the Joomla APIs and systems.  That includes the
> > JavaScript framework that ships with the core.
> > The rationale for hijacking the JHtml loader is an extreme case and would
> > require that whomever is doing the hijacking not only knows what they are
> > doing, but also that they know the JavaScript requirements for the site in
> > question.  This is something that someone building a site should look into
> > assuming their requirements aren't met by MooTools, not by third party
> > extension developers just for the sake of doing it.
>
> > Ultimately people should be using the core framework, but as I illustrated
> > earlier... for site implementors there is capacity for not having to "hack"
> > the core to achieve your goals.
>
> > - Louis
>
> > On Thu, May 14, 2009 at 5:12 PM, Rob Schley <
> > rob.sch...@community.joomla.org> wrote:
>
> >> The whole point of including a JavaScript framework in the core was to
> >> avoid these problems. There are already a thousand variables that have to be
> >> considered when building 3rd party extensions, why are you guys so set on
> >> making it even more complicated? If everyone were to just stick with the
> >> core provided JavaScript, MooTools, we wouldn't have to worry about
> >> conflicts, multiple versions, etc. You would load one framework and
> >> everything would just work. That sounds like the ideal solution.
> >> If you're going to hijack the JHtml loader, you are going to cause
> >> countless other problems with other extensions. You might support all JQuery
> >> but some other modules on the page might support all MooTools. Okay, well,
> >> who's problem is that? Yours? The other developers? The users? You're
> >> creating a headache for everyone involved when it is unnecessary.
> >> If you really like something that was released for JQuery, chances are it
> >> is available for MooTools or it could be ported without too much fuss. Have
> >> you guys seen the new MooTools More?
> >>http://mootools.net/blog/2009/03/09/more-to-love/#more-155
>
> >> I am in favor of the solution that causes the least amount of headaches
> >> all the way around. Use MooTools.
>
> >> Rob
>
> >> On Thu, May 14, 2009 at 3:31 PM, Ernest <millebi...@comcast.net> wrote:
>
> >>> No, that is definitely not the best solution. The best solution is a
> >>> module, because plugins load on all pages, and two components could
> >>> use different versions of the same library. Modules however permit
> >>> selection of the pages on which they are loaded.
>
> >>> Here is what must be, I think, the ideal solution.
>
> >>> * The installer XML file has a new 'libraries' container element with
> >>> contains 'library'  elements declaring which libraries the component
> >>> needs.
>
> >>> * Modules of type 'library' insert javascript into content pages
> >>> heads. They keep a record of which components need which libraries in
> >>> a database table. When an installer needs a new library, the system
> >>> creates a new module for it. When an installer needs a library already
> >>> installed, it is added to the records for an existing module.
>
> >>> 3. When users opens a library module, the module displays on which
> >>> pages a library is being inserted into a content page head. It also
> >>> displays the pages on which it thinks the library is required. The
> >>> user gets a warning dialog if trying to deactivate a library on a page
> >>> which the system thinks the library is needed.
>
> >>> That way, legacy components can coexist with new components and not
> >>> have library conflicts.

[Rob Schley]

This might also be of interest to somebody. Mooj gives you JQuery like syntax in MooTools. It seems pretty comprehensive although there are 2 or 3 notes about things that are not implemented or not completed.  http://github.com/cheeaun/mooj/tree/master

Best,

Rob

[pollen8]

Ernst

Sorry but I'm having a HUGE problem seeing where you are coming from.
People in this post have been patiently kind with you in explaining
the reasons why mootools is included, and when it is included.

Iain went as far as to checking on several sites as to whether the RSS
feed includes the Javascript files, I myself have checked the feed
document code in J1.5 and there is no way that any script added to the
head in the correct manner (e.g. $document->addScript() or $document-
>addScriptDeclaration() or JHTML::script()) would add anything to the
rendered RSS file.

As a 3rd party developer I LOVE the fact Joomla uses mootools, and am
glad that the team try to encourage other 3rd party developers to use
this library.
Often there are conflicts between various JS libraries, which are a
total nightmare to debug and support Often on my support forum I get
complaints about fabrik not working and this is often due to some JS
compatibility issue, and in J1.0.x this was a massive issue (before
any recommended library was used), reducing development time due to
higher support times, and generally frustrating the end users.

Also with including other libraries there is a bloat where your site
starts loading mootools, jquery, rico scriptaculous and prototype and
god know what other library. Whilst there are some edge cases where
one library might be better than another they are all solid and fast
and do the job.

Your argument about giving 3rd party devs a choice is strange as well.
Perhaps we should demand that Joomla be rewritten in Java, as that
would give developers further 'choice' - or perhaps we should demand
that we have a procedural version of Joomla for those of us who are
more used to how Drupal is coded.
In the end decisions have to be made about what technology to use, and
how to implement that technology. If you don't agree with those
decisions there are plenty of other projects who have made other
decisions which might fit in better with your preferred methods.

You say that there is no reason for 3rd party developers to use
mootools, well I can think of two already:

1) Its already in Joomla, so its likely that the users browser has
already cached the file, loading another library will only slow down
the site further
2) Its going to make your code more likely to play nicely with other
components and modules, as they are more likely to use mootools as
well

For me those were the 2 compelling reasons why I changed from
prototype to mootools.

I'd also argue that the "transition" from one JS lib to another is
minor for any developer worth his salt. I converted Fabrik from
prototype to mootools in a day or so of coding, and Fabrik has a heck
of a lot of Js. Equally though I'm not a JQuery users I have been able
to pickup how they do things and convert various libraries to mootools
without any headache.

Could you explain what you meant when saying "[mootools] imposes
difficulties on upgrading"?

"It would place observability and control in the hands of the

administrator" - I'd tend to argue that a large majority of
administrators are not technically savvy enough to understand issues
of loading different libraries and that it should be the 3rd party
developers who do this correctly for their own code.

Rob

[Ernest]

I'll write it again. I installed Joomla 1.5 and new customers stopped
appearing. It took me several weeks to work out why my customers were
going away--it was because they got bored waiting for Mootools to
load. It then took several days to work out how to stop my site from
loading unnecessary javasscript library files. Now my customers are
coming back. I lost several thousand dollars.

This is an open-source project so, when someone asked where is the
best place to put Mootools. I answered the question. Obviously, the
best way to include it is in a module so it can easily be disabled on
pages where it isn't needed, or would cause conflicts with other
packages.

Inexperienced users can just accept defaults.

It can take a long time to transition a site to a new software base,
and not all packages are immediately available with new libraries. As
I wrote before, some never get updated.

That's where I'm coming from. Would you like to tell me some more why
I am wrong now?

[Ernest]

oh, with regard to RSS and print windows: different extensiosn were
loading a dozen internal scripts, linked scripts, and CSS files into
the header. I hadn't worked out which were due to third-party tools
and which were due to the core. Some of the inline scripts were
accessing Mootools, causing jscript errors in RSS and print windows,
because I had disabled Mootools except for superadministrators. The
Mootools caption processor I disabled entirely because it conflicted
with a better caption handler which I had already adpated for my site
in another extension.

Because there is no formal way to manage script and CSS addition for
components, the additions were being inserted in all different ways
and I had to modify the source of third-party components directly for
uniform behavior in header manipulation. So I generalized the concept
to a header module which could manage not only scripts but also CSS
files. If any developers would like to join me in submitting a white
paper for its addition, I would be glad to participate in a
collaborative effort.

[Ernest]

With respect to convergence on a shared library, over time I'd hope
that developers would choose to converge. Certainly from a maintenance
stance, and an abstract idealism, this is very desirable too. However,
technical or time resource issues may delay that from happening, or it
may never happen, and an open-source platform has no control of that.

Modern Web designers create sites with multiple 'landing pages' which
is where external links for different user categories point. The ideal
site loads landing pages very quickly. Then browsers want to register,
download files, participate in a forum, leave a comment, or engage in
other more complex content interactivity. By that time, visitors are
willing to accept some delay in page load, because they are already on
the site. The reason a module implementation helps is that it makes it
easy to disable unnecessary header files from loading and minimizing
load time for any number of landing pages, resulting in maximum
visitor retention. Subsequently, more sophisticated functions can be
made available when the visitor wants them, after the visitor is
willing to accept latency because the content is known to be desired.
Different visitors usually want to access different functions, at
different times, at which points in time, additional latency for file
load is more acceptable to each user. Of course, in the ideal world,
standard libraries would be installed as plugins in the Web browser
(as in Java), but JavaScript has not reached that level of evolution
yet. I'd be delighted if Mootools achieved that. Apologies for not
stating that more clearly before.