Universal JS Framework integration

[dukeofgaming]

So, following the ideas that came from the jQuery framework request,
specially the ones from Stian and Russel, I've come up with a possible
solution to enable the integration of any javascript framework to the
Joomla! core framework.

<copy_pasta="http://groups.google.com/group/joomla-dev-cms/
browse_thread/thread/ab0b723b5830a70e/6ab6752e25c8ad3c">

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

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

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

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

So when calling we can have something like this:

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

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

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

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

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

}

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

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

}

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

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

}

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

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

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

try{
$fw = &JHTMLFramework::getInstance();
$fw->dukesSazzyFunction();
}catch(Exception $e){

JError::raiseWarning(0,JText::_('POOR_CHOICE_OF_FRAMEWORK_ERROR').$e-
>getMessage());
//or a real solution to the framework's absence ;P
}

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

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

</copy_pasta>

This will allow the Joomla! core devs to open up for any
implementation and they can just keep supporting mootools while others
contribute parallel implementations. Also, it is a more ordered and
reusable way IMHO than just adding script declarations everywhere.

The JHTMLFramework class can also add further optimizations to the
javascript handling in the whole framework, so maybe there is a better
name for the class... although JJS looks weird and like a typo =P
.
What do you think?

[dukeofgaming]

Oh and I forgot to remark, this solution is also backwards compatible
with the current implementation of all behaviors.

[Niels Braczek]

dukeofgaming schrieb:

> So when calling we can have something like this:
>
> $fw = &JHTMLFramework::getInstance();
> $fw->tooltip();

That's the way, I like it! How and by whom will the JS framework be
chosen? Like the database (mysql/mysqli) on installation level/global
configuration (sounds most reasonable to me)?
BTW: correct naming would be JHtmlFramework; the & is not needed in
PHP5, but that's an other story.

> The JHTMLFramework class can also add further optimizations to the
> javascript handling in the whole framework, so maybe there is a better
> name for the class... although JJS looks weird and like a typo =P

I'd call it JScript.

Regards,
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[dukeofgaming]

Haha.. of course *facepalm*. JScript is an excelent name.

About the decission of the framework to use, it is essentially as I said at the previous post: "The JHTMLFramework class would also deal with the component/module/ plugin framework voting and therefore dynamically changing the JS implementation... ". But I guess this could be overriden by choice in the global configuration.

Let me highlight some parts of the previous conversations:

>On Wed, Jun 10, 2009 at 11:11 AM, dukeofgaming <dukeof...@gmail.com> wrote:
>The second is by using the strategy design pattern, quoting wikipedia:

>In computer programming, the strategy pattern (also known as the policy pattern) is a particular software design pattern, whereby >algorithms can be selected at runtime.

>The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy
>pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable.
>The strategy pattern lets the algorithms vary independently from clients that use them.

>This second solution would allow working with more than one framework at a time (although most probable not in a concurrent fashion), and NOT
>simply by selecting one framework of choice in Joomla's control panel. In this case its not as straight forward as just applying the pattern, but
>requires further implementation and design work (for example, "automatic" decission of what library to use), not really that much hard.


On Wed, Jun 10, 2009 at 3:13 PM, Stian Didriksen <st...@ninjatheme.com> wrote:
>This might be a crazy idea, but we could take an approach on it the is similar to how localization works.

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

>only Mootools related scripts would load. 

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

>

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

>

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

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

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

>

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

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

>

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

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

>

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

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

>

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

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

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

>

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

>

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

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

>

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

>

>That's my final thoughts on the matter.

>

>Regards,

>Stian Didriksen

About the "&" matter, you are right... it was just the habit =P. PHP5 uses copy-on-write when assigning variables, so unless we wanted to make some changes to the instance it is not necessary.

Also, I guess it should now be:

     $fw = JScript::getFramework();

And the extended classes would be JScriptMootools, JScriptJQuery, JScriptExtCore, etc. And we could also have the following:

     $fw = &JScript::getFramework();
     $fw->minify(true);
     $fw->cache(false);

And finally we could have a way to tackle this issue (http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/7d2489ad79cd720a) in a very elegant way with magic functions only in the JScriptMootools class:

class JScriptMootools extends JScript{
   private $_declarations = array();
   public function __call($func,$params){
       $ret = call_user_func_array($this->$func,$array);
        return  $this->_declarations[] = $ret;
   }
   public function __toString(){
       return "window.addEvent('domready',function(){".implode("\n",$this->_declarations)."});";
   }
}

:)

[dukeofgaming]

Err, sorry, I meant this:

class JScriptMootools extends JScript{
private $_declarations = array();
public function __call($func,$params){
$ret = call_user_func_array($this->$func,$array);

$this->_declarations[] = $ret;
return $ret;

}
public function __toString(){
return
"window.addEvent('domready',function(){".implode("\n",$this-
>_declarations)."});";
}

}

On Jun 10, 7:20 pm, dukeofgaming <dukeofgam...@gmail.com> wrote:
> Haha.. of course *facepalm*. JScript is an excelent name.
>
> About the decission of the framework to use, it is essentially as I said at
> the previous post: "The JHTMLFramework class would also deal with the
> component/module/ plugin framework voting and therefore dynamically changing
> the JS implementation... ". But I guess this could be overriden by choice in
> the global configuration.
>
> Let me highlight some parts of the previous conversations:
>

> >On Wed, Jun 10, 2009 at 11:11 AM, dukeofgaming <dukeofgam...@gmail.com>wrote:
> >The second is by using the strategy design pattern, quoting wikipedia:
>

> *>In computer programming, the strategy pattern (also known as the policy

> pattern) is a particular software design pattern, whereby >algorithms can be
> selected at runtime.
>
> >The strategy pattern is useful for situations where it is necessary to
>
> dynamically swap the algorithms used in an application. The strategy>pattern is intended to provide a means to define a family of algorithms,
>
> encapsulate each one as an object, and make them interchangeable.>The strategy pattern lets the algorithms vary independently from clients
>

> that use them.*

> And finally we could have a way to tackle this issue (http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/7d...)

> in a very elegant way with magic functions only in the JScriptMootools
> class:
>
> class JScriptMootools extends JScript{
>    private $_declarations = array();
>    public function __call($func,$params){
>        $ret = call_user_func_array($this->$func,$array);
>         return  $this->_declarations[] = $ret;
>    }
>    public function __toString(){
>        return
> "window.addEvent('domready',function(){".implode("\n",$this->_declarations)."});";
>    }
>
> }
>
> :)
>

[Stian Didriksen]

Hi all,

dukeofgaming asked me to post some suggestions I sent him, in here. So
here goes:

I suggest a dot notation syntax for the classes when you call the
framework. Instead of JMootools, I would use
JHTML::_('framework.jquery'); to initiate the framework class and set
a static with the framework you prefer.
Doing that will allow us to write code more independently from what
the exact methods and other apis the framework calls.
And if we are to convince the core devs to add this in, we need it to
work as simple as JHTML::_('behavior.mootools') does today.
So by moving all the logic into the class, we can make it possible
with a simple call like that.

I suggest then that we overload the behavior class like this:
The mootools behavior will be reduced to a simple
JHTML::_('framework.mootools') call so the new API get full control.
All the other methods in the behavior class will have Mootools as
their default codebase. If something call an behavior, and got another
framework than mootools called the framework class would then check if
the extension provide an alternate script running on the current
framework. If not then all behavior apis will fall back to mootools,
as a "plan B" or "safe mode" function to ensure nothing breaks.

I then recommend all scripts written for something other than mootools
are coded in a way that wont break Moo scripts if both are loaded. So
that will make it possible to load just one framework in optimal
situations, and still ensure compatiblity and that everything still
"just works" even if more than one framework are loaded.

Best regards,
Stian Didriksen
Developer and Designer at NinjaForge.com

[G. D. Speer]

Seems like a good approach to me. Amy?

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



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.61/2167 - Release Date: 06/10/09
05:52:00

[Amy Stephen]

I've been watching you guys -- and my brain is spinning :-P

Let me see if I am understanding the basics:

• This is a 3PD System Plugin that could be used to configure a JS Framework of your choosing.
• Beyond that, there is a very clever mapping of UI objects, like Accordions, Tabs, etc., that could ease the pain of moving to a non-Moo Framework

If that is the case, it is quite remarkable. Seriously. This is a "Linux-like" approach made possible by an excellent Joomla! architecture and motivated people who want to expose a choice. I love it.

Now, how does this handle those situations where  non-geeky community members (apparently, we have some of those) stand at the great candy counter of JED, and pick a super shiny Gallery Module and this radical News Rotator, one created in jQuery and the other in Mootools?

Does your design cover that? I think it's going to have to do that. Maybe set a preferred for core UI - then enable libraries so they get loaded, if necessary.

I took a look at JED earlier, it's already filling up with jQuery options. http://extensions.joomla.org/extensions/search/1/jQuery/

++++

Also, CorePHP folks have deep experience with Ext JS - which is really nice - especially for data grids - and I finally realized we have had eXtplorer for awhile.

I'd love to see a post 1.6 UI for the Administrator made available using Ext JS. I

http://extensions.joomla.org/extensions/core-enhancements/file-management/2630/details

++++

What all do we need to do?

• This plugin
• Template Overrides
• Instruction and Advice for Users
  
• Instruction and Advice for Developers

Would love to see us start sharing examples of how to use these tools, too. Maybe we could have a section of the Wiki.

End of incoherent ramblings for the day ;)

Thanks you guys - you know what - it's been a long time since so many developers came together at J! and said there piece. And then, to have you guys working on a solution. Pretty special.

Amy :)

[Niels Braczek]

Stian Didriksen schrieb:

> I suggest a dot notation syntax for the classes when you call the
> framework. Instead of JMootools, I would use
> JHTML::_('framework.jquery'); to initiate the framework class and set
> a static with the framework you prefer.

I prefer

$script = JFactory::getScript();

All components, modules and plugins should use only methods defined by
the JScript interface. Thus, the template(s) can define, which framework
is needed, and the admin is responsible to provide the proper
configuration. The template(s) may then contain JS code specific to one
framework.

At least for the frontend, a non-JS variant (eg. JScriptNoscript) should
be provided (may be 3rd party), that provides functionality as close to
the JS solution as possible. That way, CMPs can make use of all the
pretty effects, but the admin can decide to turn them off without
breaking the site.

[G. D. Speer]

AFAIK, only jQuery "plays nicely with others" with compatibility mode.

A few of the other frameworks might not overlap in namespaces so they may not have issues, but those more experienced with them need to weigh in on this.

 

The larger issue is the suggestion made earlier - to have the JED indicate the JS framework compatibility of extensions so 'mere users' are sensitized to the issues raised by selecting extensions that might trigger 2, 3 or 4 different frameworks to load.

 

Not having a stake in the ground about Mootools being technically preferred (or moo plus jquery together) results in a proliferation of non-mootools extensions which risks an increase in conflict support issues / bad experiences.

If, following the suggestion we can get to true front-end agnostic, great, but I'm not sure the development team will embrace all the 'what-if's' represented by Prototype, jsExt and others.

 

I think the proposal is a way to set a pattern for extending to as many options as we might ultimately want to support, with jQuery being the first.  And that support by itself will tend to put a box around mootools and jQuery as the options 3PDs should aim for.

 

 

 

 

[dukeofgaming]

Amy, I'd like to think this could be more than just a plugin but a somewhat "formal" proposal to the Joomla! framework since this could be a way of making Joomla! javascript framework agnostic... or more like polytheist =P.

Why should this be added to the Joomla! Framework, and not just be done as a plugn that overrides some JHTMLBehaviors and other stuff?. Well, because it opens the architecture of Joomla! so anyone coud just come and focus on the frameworks they want to support... and not just having a big-bad slimy JS multiframework plugin with big scary tentacles.

Think of this as the next JText =), i.e., core developers only focus on maintaining mainly the en-GB language and others come and contribute their own translations. It is the very same thing here!, core devs can focus on maintaining just the Mootools imlpementations where as the community can come and bring up their own "translations" of core javascript functions...

If this were to be just a simple plugin development it would be so more difficult to coordinate the effort of adding X framework implementations, and I'm sure there could be parts where one could just not have JS framework overrides.

So, here's the thing, for non-geeky community members, I'll try to drop an analogy with internationalization here (where russian is extcore and enlgish is mootools):

1. If they wanted to add a component/module/plugin that uses ExtCore, it would be like if you spoke russian and wanted to download an english-only extension. Ok, so regardless, they do download and install it.
   
2. The next thing you know is that when enabling such "russian" extension you would get some "translation not available" for other plugins, so you get a standard Joomla message saying that you cannot have 2 "languages" at the same time, say english and russian as if they were mootools and extcore respectively. So you now need to download the extcore translation... so, you go to JED and you do.
3. So maybe you now you just wanted to have some "russian" pages... you also want to have some "english" pages... so the basic rule here is saying which you want to have here as the default language (i.e. js framework, by default mootools) and if a "russian" extension is found to be trying to load in a page, Joomla tries to render the other extensions in "russian".
4. Finally, imagine you have the option of telling the extension directly which JS Framework to use through the backend, depending if the developer chose to support it, and this is exactly the same way it is already being done with some templates and their drop-down menu implementations.

So yes, the design pretty much covers it =)

Now, from the developer's standpoint one could one of these two:

• Handle a JScript exception directly in the code and deal with the framework's absence if you really must, or just issue the "I need framework X" notice so the webmaster can take action on getting the corresponding framework translation.
• Or you can support multiple framework implementations through inheritance with the JScriptFrameworkX object... and there needs to be conventios here.

So again and remarking the last point... there are some conventions that need to be put in place, and this kind of presence cannot be achieved that much easily by a plugin.

Furthermore, this could open the possibility of using more than one JS framework to the core devs and take advantage of this the way you say: having ExtJS grids in the backend.

Also, Valerio (one of the mootools core devs) just dropped in the other thread and says that there is some new compatibility candy for Mootools 1.2.3 (http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/ab0b723b5830a70e/15191ff589cdd766), so more thought could be put on this to add concurrent framework support.

Finally, we could even have a JScriptNative class to work out the unworkable between frameworks... native js does not conflict with anything =P. This might look like adding some complexity to JS handling but I think it is quite the opposite... doing an analigy with SQL, it is like having plain SQL queries everywhere vs. doing it through a class... say, JQuery? <cough>.

So, to add this official multi-framework support is just like adding internationalization to joomla, it is more than just a plugin IMHO. So summarizing here's what I think we need:

  - To work out the design and conding implications framework-wide, this includes:
    - Coding conventions
    - Class designs
    - Interface (not GUI) designs too, maybe, I mean, we are already in PHP5 =)
    - Inheritance model
    - File structure and manifest additions
    - Exception handling
  - We also need to work out the "voting" functionality to the JScript class, so it can decide which framework to use at a given moment
  - Caching, minification and further optimizations in JS handling through this class
  - Decouple mootools implementations to this new structure
  - Define the use cases for the backend and refactor it accordingly

I think all this could be analized and even worked out and implemented during the J! 1.6 alpha stage... but this should not be left to the J! core team alone as they already have too much important work to do!, therefore I formally propose assembling a team of a minimum of 5 people that can commit to this task and work along the core team to redesign and refactor the framework, since this is a clean objectual approach it shouldn't be so hard. I'd be happy to join this team to join this team and make this possible, hopefully, at some point of J! 1.6.x

I'd really love to see the core team's opinion on this =)

[Stian Didriksen]

Hi Amy,

On top of my head Joomla can not only supports installable libraries that add new APIs to the core, but allow you to extend the current ones, right?

Coding this as a framework and getting it stable and as easy to use as the APIs we already use should make the core devs at least consider including it to the core.

It's already a fact today that many 3rd parties choose a different js framework than the core,

and because we got no core API, standards or even a set of guidelines for it everyone seems to go their own way.

This results in multiple loading of jQuery on the same page since the JDoc::addScript api don't filter by filename, but path.

That's at least how it goes in 1.5, I don't know 1.6 very well yet.

What we are trying to do is creating everything that needs to be created so it's something developers can start to use today,

so core devs can see it working, and see the advantages of it.

Essentially this API we're making wont do anything new to the core scripts, but will let those developers who wish to use another framework,

do so without disadvantages to the end user.

Those disadvantages are usually:

- More than one library loading resulting in slower response times due to increased HTTP requests

- Slower site load due to extra file size

- Slower performing scripts since extra frameworks may load multiple times if extensions from different developers are present on the same page.

Developers often got some kind of solution to prevent duplicate scripts internally, but we don't have a united method like we got for Mootools.

If anyone remember how it was for Joomla 1.0, this problem occurred for Mootools as well, but the APIs introduced in 1.5 not only prevent duplicates by default,

but most importantly gave us an standard.

I know that if we take that one step further, we would achieve the same for other scripts as well, 

and put an end to those issues.

Your point about the JED is exactly why we eventually would either get this included in the core, or it would all be a waste.

By making into a standard, we would ensure developers got the tools needed to guarantee compatibility with Joomla, and make it possible to use another framework in Joomla in a clean way.

IMO this shouldn't be something an admin could control, as some people have suggested here and multiple times in the past. There is no reason whatsoever for anyone to turn of scripts, or choose the framework of choice in the backend as a global setting.

If something is calling a script in the frontend that the admin don't want, then don't use the extension that call it. If you still need to use the extension, but don't need a specific feature that calls the scripts, like the tooltips com_content got, then turn of that specific feature. Turning of the script by itself is not the way to go.

If we want the user to be able to use PDF or not (deprecated in 1.6 if I recall right btw) we don't tell the user to go and turn of loading the php library that create the PDFs, do we?

The preferred framework are determined where it's needed and in use, in the extension that is.

This will work as a new API built on top of what we already have, and refines what we already use to make it simpler, easier and safer to use a different framework with some optional functions.

For example, if something for some reason trigger the Mootools fallback (most of the time this will happen if a script not available in your selected framework loads) will load the mootools version of your script, if you have a mootools prefixed version of your js file in the same directory. You would of course be able to set you own fallback path and filename as you see fit.

Reason for why that is upmost useful is that while no conflicts and compatibility is good, being able to provide scripts that supports more than one framework will let those who go the extra mile ensure two frameworks never load at once. And that everything perform at its best in almost any situation or configuration.

This can easily be done internally or as a plugin, but as I said earlier a lot of people, including us when we where known as Ninjoomla, built our own scripts that tried to stop duplicate scriptloading,

but all in all it was one huge mess since we didn't have a standard. Everyone had their scripts located all over the place,

and even named the files differently.

This is what we are trying to stop here :)

Instead of everyone doing it their on way we want to end up with an solution so easy, 3rd parties would end up with no better alternate for using stuff like ExtJS or jQuery.

Regards,

Stian Didriksen

[Israel Dacanay Canasa]

I'm glad that we're keeping the discussions going and brainstorming the best way for Joomla to include other JS Frameworks.

In a perfect world, I'd imagine that Joomla 1.7 would go back to the white paper and consider creating this new way of including JS Frameworks. It's too late for 1.6 because as you can see, our Core Devs are very very comfortable already with how things are.

So let's just say that we're now talking about Joomla 1.7 and we're proposing our ideas.

Like I said in the parent discussion, the best way for Joomla to be JS Framework (heretofore JSF) agnostic is to detach Mootools from the Core and just make it a Core Plugin. Maybe not just a simple plugin belonging to the "system" group, but a new group of plugin, "js" or "jsframework".

I think extending JHTMLBehavior or creating a new JHTMLFramework is not future proof. From what I can surmise, the only problem we have right now with the many different JSF around and with many 3PDs around having different preferences, is that there is a possibility that the JSFs could be loaded multiple times. 

So the solution would be to create Core Plugins for the major JSFs Mootools and jQuery. Using those JSFs could be as simple as this.

$jsf =& JFactory::getJSFramework('mootools');

$jsf->loadPlugin( 'calendar', array('option1'=>'value'));

The getJSFramework() factory method would then check if the JSF has already been loaded, and if not, create a new instance, and include it in the html head.

The loadPlugin() method will just look for a file named 'pluginname.frameworkname.js' in the /plugins/jsframeworks/frameworkname/plugins and include it. Or if the "JSF Joomla Plugin" doesn't include a particular "JSF Plugin"(note the difference), the loadPlugin() can accept a third parameter as the path of the js plugin file. (This would also deal with double loading issues since the 'calendar' namespace has already been taken with a corresponding path, loading the same plugin from a different path would be ignored).

Now, other JSFs could just make these 2 core plugins as examples if they want to create a UNIFIED way to include their JSF for Joomla.

I think it's just as simple as that. I know there are many other things to consider, but I think this is just a rough idea on how things can work.

What do you guys think?

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

[Niels Braczek]

Israel Dacanay Canasa schrieb:

> It's too late for 1.6 because as you can see, our Core Devs are very very
> comfortable already with how things are.

If it is too late, it is not because of the reason, you see. It is
because the desired solution is a bigger mouthfull, and most likely can
not be brought to reasonable stable reality within the given timeline.

> $jsf =& JFactory::getJSFramework('mootools');
> $jsf->loadPlugin( 'calendar', array('option1'=>'value'));

The calendar is an example of stuff, that should be in the interface
definition, so that *any* ClientScript framework *must* implement it.
Thus there is no need to specify a framework here.
So your example would read

$jsf = JFactory::getScript();
$calendar = $jsf->calendar( 'value' );
$calendar->init();
...
<... onclick="<?php echo $calendar->open(...); ?>" ... />

[dukeofgaming]

Hi Israel. Yeah, perhaps this is a big change for J! 1.6 initial release but J!1.7 might be too far... I don't know, I don't think it would take that much to get this done but I don't know the protocol, so I guess you could be right.

I concur with Niels, the approach you suggest is way too lax and would not allow for dynamic implementation handling. We are at PHP5 now so it is safe to use stuff like interfaces.

Now, we could need interfaces for the backend part, since it is critical that all core functions and behaviors are implemented here, but when developing a custom extension I believe we could use the registerFunction approach. Furthermore, it allows to have stubs to at least say the function is not supported and throw an exception.

Parametrization is an issue here, if you take a look at the mootools implementations these are parameters that are passed directly to the javascript prototipical object of something like the tooltip. So it is an additional issue to handle.

Israel also mentions the use of a factory method, but as Niels points out, using an abstract factory avoids having to specify a specific JS framework.

I'd like to add that since the JScript name is used, I think pertinent to take advantage of the impression the name gives and add here some javascript handling functionality.

And just making clear here that it is not as easy as just cramming your javascript functions in different prefixed files. Extending a JScriptMootools or JScriptExtCore is necessary... and would also keep allowing us to overload stuff the way Stian does it with JHTMLBehavior. Summarizing this:

1. JHTMLBehavior calls for JFactory::getScript()->tooltip();
2. JScript has an interface that defines at least the following functions: tooltip, calendar, modal, etc. (the ones in JHTMLBehavior)
3. JScriptMootools has the current implementations of tooltip, calendar, modal, etc., only decoupled
4. If you don't like the current JScriptMootools->calendar() function for your own extension you could overload it with, say, this (http://www.clientcide.com/wiki/cnet-libraries/09-forms/02-datepicker).
   
   Or if this shouldn't be allowed we can just define all these functions as final in the interface so they cannot be overriden.
5. Finally I think that if JScriptExtCore is being called for the non-existent calendar() function it should use the __call magic function to have this checked and throw an exception so fallback to another implementation an be handled automatically by the JScript class.
   

So a JScript class is definetly futureproof, since it is WAY WAY more than just trying to have a nice helper class.

JScript would also need to have a template method for getting the path to the library IMHO.

BTW, I like the idea of an additional plugin group... there are so many players in the JS world, and very good ones, have you taken a look at AmpleSDK (http://www.amplesdk.com/) ?, we really need to open up the doors for everyone but at the same time keep it manageable for our core devs; they already like using mootools, so why should we make them use/support ANY other framework themselves?.

One more perk about using the JScript class would be that if I just want to add JScriptFrameworkXYZ for one single fancy feature and no other JScript framework implementation is compatible in any way at all, maybe we could have a JScriptNative class to solve this as a worst scenario fallback object.

[dukeofgaming]

Putting some second thoughts on this, I think the extra plugin group
is unnecessary, there are already different type of plugins... like
the authentification plugins or the webservice plugins that target a
specific aspect of the framework.

>    1. JHTMLBehavior calls for JFactory::getScript()->tooltip();
>    2. JScript has an interface that defines at least the following

>    functions: tooltip, calendar, modal, etc. (the ones in JHTMLBehavior)

>    3. JScriptMootools has the current implementations of tooltip, calendar,
>    modal, etc., only decoupled
>    4. If you don't like the current JScriptMootools->calendar() function for

>    your own extension you could overload it with, say, this (
>    http://www.clientcide.com/wiki/cnet-libraries/09-forms/02-datepicker).
>
>    Or if this shouldn't be allowed we can just define all these functions as
>    final in the interface so they cannot be overriden.

>    5. Finally I think that if JScriptExtCore is being called for the

>    non-existent calendar() function it should use the __call magic function to
>    have this checked and throw an exception so fallback to another
>    implementation an be handled automatically by the JScript class.
>
> So a JScript class is definetly futureproof, since it is WAY WAY more than
> just trying to have a nice helper class.
>
> JScript would also need to have a template method for getting the path to
> the library IMHO.
>
> BTW, I like the idea of an additional plugin group... there are so many
> players in the JS world, and very good ones, have you taken a look at
> AmpleSDK (http://www.amplesdk.com/) ?, we really need to open up the doors
> for everyone but at the same time keep it manageable for our core devs; they
> already like using mootools, so why should we make them use/support ANY
> other framework themselves?.
>
> One more perk about using the JScript class would be that if I just want to
> add JScriptFrameworkXYZ for one single fancy feature and no other JScript
> framework implementation is compatible in any way at all, maybe we could
> have a JScriptNative class to solve this as a worst scenario fallback
> object.
>

[Amy Stephen]

On Thu, Jun 11, 2009 at 3:17 AM, dukeofgaming <dukeof...@gmail.com> wrote:

Amy, I'd like to think this could be more than just a plugin but a somewhat "formal" proposal to the Joomla! framework since this could be a way of making Joomla! javascript framework agnostic... or more like polytheist =P.

First of all, I get why you want to do this. And, in time, those very ideas - and code concepts - may be the direction things head. But, today, we aren't there and my experience with the project is that the developers have solid reasons for their viewpoints. Sometimes, it takes me time to reach a level of understanding that I get their perspective. But, I have not found a situation where I felt like they were completely misinformed on strategy. Never.

We have our 1.6 answer. There is not time to make that type of architectural change with two weeks before Alpha. We know that we can work around this and that's worth us exploring.

Incremental improvements work in free software communities. So, let's start with the plugin approach. Let's give Mootools time to recharge and hope cool things come there. Let's see what the community finds exploring jQuery. Let's allow time for these experiences and I guarantee you that as we learn to adapt and work together, keeping options open, but not jumping right into core changes, we will develop consenses on directions.

Plugin. Let us focus on Plugin. :)

I am flat out this morning, so, I'll come back and read more. Your mind is in this, awesome!
 

[Amy Stephen]

I will be back to read this later, Stian. Thanks for responding on this. Busy this AM, is all.

[Amy Stephen]

Israel - briefly - before we start 1.7 discussions - let's focus on a plugin for 1.6 and a strategy for exploring jQuery, at minimum?

I think it's really important that we focus on what *we* have control on for now and table discussion on what can happen in the core to make it do what we need.

We are not stopped by core. So, let's work with what we have and be clever, here.

Let's get our proof of concept in place. Let's get people using both. Let's demonstrate why we see jQuery or other options as important. Let's give the community time to produce - then see if the core should change.

Incremental improvements.

[Amy Stephen]

OK - yup - everyone seems focused on changing core, still. Straight up - you are wasting time, here. The project cannot allow special interests, like us, to force architectural change.

The monkey is on our back to prove our point. We need to present evidence of community using jQuery in ways that are innovative and evident of a direction the project should head. That means we need a plugin, training, documentation, support in place to provide resources community needs to get rolling on building that case.

During that time, it will be good to see if Mootools is able to recharge and provide the community with toolkits and widgets that we *very well may want to use!*

So, let's remove roadblocks to working with jQuery and take incremental steps forward.

Assume core cannot change. Now what? Let's be clever and have fun.

Eager to see what we come up with!

Amy :)

[Israel Dacanay Canasa]

Thank you for your guidance Amy.

But I'd also like to point out that the reason we're discussing Core modifications is because what we have in mind is to make Joomla JSF Agnostic. What I'm pushing forward is the idea that Joomla should not "officially include" a JS Framework. It should detach itself from Mootools, although it can include Mootools as a Core Plugin as an example on how to make JS Frameworks plugin. It's not about trying to evolve the community into accepting jQuery. It's about trying to make Joomla friendly to any JS Framework. 

I think taking the plugin approach as what Joomla is right now, would not solve the problem. Say we all of us here, who's aware of this discussion, has agreed to use Only One jQuery Plugin for Joomla when working with Extensions. But what about other developers who doesn't even know this discussion exists? In short, we can't standardize jQuery as a plugin, if Joomla doesn't take a stand.

If Joomla doesn't provide a way for JS Frameworks to avoid conflicts and multiple loading, the Plugin approach is also a waste of time.

What I'm hoping for right now, is that the Core would consider this issue, and at least make a way for Joomla to be truly JSF agnostic for 1.6. Because yes, 1.7 is so far away. Joomla can't be agnostic if Mootools is in the Core.

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

[Amy Stephen]

For now, we don't have to solve that problem, we only have to take an incremental step forward and clear a path for people to use another option. I suggest we focus exclusively on jQuery for now. Getting people involved and trained and creating and sharing Widgets is of equal importance.

Let's be realistic here. Putting a framework in core doesn't mean that framework will work for the community. We've seen that, from my perspective.

It takes a well considered approach for the success of people using technology.

• Availability of the solution (in this case, a plugin)
• Instructions to use it
• FAQ on issues that tend to arise
  
• Examples of how to develop in it - specific to Joomla!
• Place for people to collaborate, learn, develop
• Time for experience
  

Those things will make this successful or not successful. Let's not lose sight of what is important by becoming overly consumed by one point (that being, the availability of the solution) and assume that where the code resides is critical (meaning, it must be in core). In the end, putting this solution in core is a minor issue on whether the concept is going to work for the community. If you don't believe that - why do you think some of us are struggling to use Mootools as a solution. It's in core. Make sense?

Let's instead focus on the big picture. The whole experience from a community standpoint. As we do this big picture, we also need to try to help the Mootools devs recharge. As a community, we let them down, too, by not building up that tool. If they want to try to make a run at it, then, we should also try to support them, if possible.

Community needs some time here. So, let's buy it. Get the plugin ready and let's get these options into people's hands and start collaborating. Then, I guarantee you, if we back off this core thing, we will all start building concensus on 1.7. But for now, let's zone in on the plugin.

[dukeofgaming]

Fair enough Amy, this is a plugin matter at this stage and the intent to add this to the core should be acted upon protocol towards J! 1.7. However, I'd reaaaaaally like to know (and I think others would like this too) what the core devs have to say about everything we've come up so far:

Not to get high expectations...
Nor to have them promise us something...
Nor to try to impose upon Joomla's architectural strategy...

We just wan't to know if we are following the right path of reasoning or if we are just being delusional development wackos.

I have to remark that I have no personal interest on supporting jQuery or any other framework at the moment... I'm a mootools developer and I'm very happy on how things are, but I also know that this can really strengthen my favourite open source project (apart from second to linux though =P): Joomla, and this is why I am here, not jQuery, ExtCore or FrameworkXYZ. So I'd be a little down if this was not being taken serious given the sentiment of needing Joomla! to play cool with any framework.

Having an agnostic Joomla opens it up to developer diversity... for some of us (development wackos) coding tools are like a philosophy current, or even a religion, so I bet the jQuery dudes felt like Joomla is the Church of the Holy Cow trying to evangelize them... I recall someone saying "shoving down my throat" regarding the mootools decision.

[Amy Stephen]

You know what - the fact that you are a Mootools dev makes you a *more perfect* participant in this - you can help try to fire up that type of development collaboration.

I can't speak for the devs, I would GUESS that they are very focused on the event to come in two weeks and less focused on experimental, research like thinking right now. So, patience on these concepts.

I am so impressed with your architectural thinking. Everyone in this thread is very strategic.

[dukeofgaming]

Thanks for your comments Amy =), and here is the first incremental step: the development spaces are up.

I have started a space at BitBucket.org over here: http://bitbucket.org/dukeofgaming/jscript/overview/. I have also applied for the project with the same description at JoomlaCode.

<offtopic>
BTW I have to confess I hate subversion for code collaboration, and I hate it even more for an open source project for the very same reasons Linus does (http://www.youtube.com/watch?v=4XpnKHJAok8)... therefore I use Mercurial, that is easier than git... but if anyone feels like using git I'll be open to it too.

Fun fact: Google Code is supporting Mercurial, but it is now at closed beta stage.

The JoomlaCode space was applied to with subversion, regardless ;).
</offtopic>

Before we continue, I'd like to know what Beat thinks about all these, since I think he has something similar already... we should start working considering the learning and experience he had with their solution, IMHO.

[Amy Stephen]

Good point - get Beat in here! I'd like to also see what he has with the API approach he mentioned earlier.

lol! I saw this in your description "core extension to Joomla!" and - just to keep everyone's expectations inline with reality - it won't be core - it will be 3PD.

<community involvement advertisement>
You know - for those who want to get their hands on some core code - dudes - the dev team needs help! Get your hands in the air and volunteer to help w 1.6!
</ community involvement advertisement>

[dukeofgaming]

Sorry!, I meant "enhancement", haha, meaning it will be somewhere here
(http://extensions.joomla.org/extensions/core-enhancements) I guess.

On Jun 11, 10:30 am, Amy Stephen <amystep...@gmail.com> wrote:
> Good point - get Beat in here! I'd like to also see what he has with the API
> approach he mentioned earlier.
>
> lol! I saw this in your description "core extension to Joomla!" and - just
> to keep everyone's expectations inline with reality - it won't be core - it
> will be 3PD.
>
> <community involvement advertisement>
> You know - for those who want to get their hands on some core code - dudes -
> the dev team needs help! Get your hands in the air and volunteer to help w
> 1.6!
> </ community involvement advertisement>
>

> On Thu, Jun 11, 2009 at 10:23 AM, dukeofgaming <dukeofgam...@gmail.com>wrote:
>
> > Thanks for your comments Amy =), and here is the first incremental step:
> > the development spaces are up.
>
> > I have started a space at BitBucket.org over here:
> >http://bitbucket.org/dukeofgaming/jscript/overview/. I have also applied
> > for the project with the same description at JoomlaCode.
>
> > <offtopic>
> > BTW I have to confess I hate subversion for code collaboration, and I hate
> > it even more for an open source project for the very same reasons Linus does

> > (http://www.youtube.com/watch?v=4XpnKHJAok8).<http://www.youtube.com/watch?v=4XpnKHJAok8%29.>..

> > therefore I use Mercurial, that is easier than git... but if anyone feels
> > like using git I'll be open to it too.
>
> > Fun fact: Google Code is supporting Mercurial, but it is now at closed beta
> > stage.
>
> > The JoomlaCode space was applied to with subversion, regardless ;).
> > </offtopic>
>
> > Before we continue, I'd like to know what Beat thinks about all these,
> > since I think he has something similar already... we should start working
> > considering the learning and experience he had with their solution, IMHO.
>

> > On Thu, Jun 11, 2009 at 10:05 AM, Amy Stephen <amystep...@gmail.com>wrote:
>
> >> You know what - the fact that you are a Mootools dev makes you a *more
> >> perfect* participant in this - you can help try to fire up that type of
> >> development collaboration.
>
> >> I can't speak for the devs, I would GUESS that they are very focused on
> >> the event to come in two weeks and less focused on experimental, research
> >> like thinking right now. So, patience on these concepts.
>
> >> I am so impressed with your architectural thinking. Everyone in this
> >> thread is very strategic.
>

> >> On Thu, Jun 11, 2009 at 9:57 AM, dukeofgaming <dukeofgam...@gmail.com>wrote:
>
> >>> Fair enough Amy, this is a plugin matter at this stage and the intent to
> >>> add this to the core should be acted upon protocol towards J! 1.7. However,
> >>> I'd reaaaaaally like to know (and I think others would like this too) what
> >>> the core devs have to say about everything we've come up so far:
>
> >>> Not to get high expectations...
> >>> Nor to have them promise us something...
> >>> Nor to try to impose upon Joomla's architectural strategy...
>
> >>> We just wan't to know if we are following the right path of reasoning or
> >>> if we are just being delusional development wackos.
>
> >>> I have to remark that I have no personal interest on supporting jQuery or
> >>> any other framework at the moment... I'm a mootools developer and I'm very
> >>> happy on how things are, but I also know that this can really strengthen my
> >>> favourite open source project (apart from second to linux though =P):
> >>> Joomla, and this is why I am here, not jQuery, ExtCore or FrameworkXYZ. So
> >>> I'd be a little down if this was not being taken serious given the sentiment
> >>> of needing Joomla! to play cool with any framework.
>
> >>> Having an agnostic Joomla opens it up to developer diversity... for some
> >>> of us (development wackos) coding tools are like a philosophy current, or
> >>> even a religion, so I bet the jQuery dudes felt like Joomla is the Church of
> >>> the Holy Cow trying to evangelize them... I recall someone saying "shoving
> >>> down my throat" regarding the mootools decision.
>

> >>> On Thu, Jun 11, 2009 at 9:17 AM, Amy Stephen <amystep...@gmail.com>wrote:
>
> >>>> OK - yup - everyone seems focused on changing core, still. Straight up -
> >>>> you are wasting time, here. The project cannot allow special interests, like
> >>>> us, to force architectural change.
>
> >>>> The monkey is on our back to prove our point. We need to present
> >>>> evidence of community using jQuery in ways that are innovative and evident
> >>>> of a direction the project should head. That means we need a plugin,
> >>>> training, documentation, support in place to provide resources community
> >>>> needs to get rolling on building that case.
>
> >>>> During that time, it will be good to see if Mootools is able to recharge
> >>>> and provide the community with toolkits and widgets that we *very well may
> >>>> want to use!*
>
> >>>> So, let's remove roadblocks to working with jQuery and take incremental
> >>>> steps forward.
>
> >>>> Assume core cannot change. Now what? Let's be clever and have fun.
>
> >>>> Eager to see what we come up with!
>
> >>>> Amy :)
>

> >>>>>> On Thu, Jun 11, 2009 at 6:13 AM, dukeofgaming <dukeofgam...@gmail.com

> >>>>>> > wrote:
>
> >>>>>>> So, following the ideas that came from the jQuery framework request,
> >>>>>>> specially the ones from Stian and Russel, I've come up with a
> >>>>>>> possible
> >>>>>>> solution to enable the integration of any javascript framework to the
> >>>>>>> Joomla! core framework.
>
> >>>>>>> <copy_pasta="http://groups.google.com/group/joomla-dev-cms/

> >>>>>>> browse_thread/thread/ab0b723b5830a70e/6ab6752e25c8ad3c<http://groups.google.com/group/joomla-dev-cms/%0Abrowse_thread/thread...>

[G. D. Speer]

> In short, we can't standardize jQuery as a plugin, if Joomla doesn't take a stand.

 

I totally agree with this statement, but for me, it leads to a different result.

 

Joomla core has standardized on the mootools framework and for 1.6 - that's a 'given' that will not change at this late date.  That is 'taking a stand'.  Becoming JSF agnostic is not taking a stand to support dual frameworks, that's withdrawing the previous stand and implied assurance that if you develop using mootools and designers select extensions accordingly, everything should play well together.  Mootools is currently and for 1.6 will continue to be the 'safe harbor'.  Going agnostic only removes that one safe harbor, it doesn't create any new ones.

 

I also agree with Amy - until there is momentum in the community and increasing utilization of other frameworks, core isn't very motivated to solve what many perceive to be a largely theoretical problem.

 

I think the goal at this point is to have a unified solution for 3PDs that will be upgrading jQuery-based extensions.  If we can come up with a toolset and a clear roadmap for how to redeploy the 1.6 version of their products in a way that will manage the multiple instances per page issue in a way that's easy for them to just pick up and use, and make using that toolkit part of the rules of engagement to be considered a 1.6 native extension, we have a short term community standards solution without having to change core - just supplement it.  Once that process has traction and critical mass, you can bet that whatever is in the toolkit will become core in the next round.

 

Let's ignore what's done and work on a simple elegant solution to a reliable jQuery supplement that everyone can adopt before they each start building their own / finding their own path - that's the stand I believe we should hustle to take.   As Amy said, let get creative!

 

 

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

From: Israel Dacanay Canasa

To: joomla-...@googlegroups.com

Sent: Thursday, June 11, 2009 8:37 AM

Subject: Re: Universal JS Framework integration

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

Version: 8.5.339 / Virus Database: 270.12.62/2168 - Release Date: 06/10/09 18:30:00

[dukeofgaming]

<offtopic>
The project has been approved at JoomlaCode: http://joomlacode.org/gf/project/jscript/
</offtopic>

Well, I beg to differ, since as Amy pointed out, there are already jQuery and ExtJS extensions at JED, and surely there are Prototype ones, and AmpleSDK ones to come, so I do think it creates new ones, whichever are supported externally (no limit here), starting with the already supported Mootools that is going nowhere far from Joomla!, so neither removes a "safe harbor".

Agnosticity comes as a byproduct of clean design.

All these existing javascript multiflavored extensions are doing their best putting mootools aside... what happens when someone stands at JED and cherrypicks their extensions is that they might get to see some of them collide, and do not know what happened?, as Stian said, the admin should not have to worry about this.

As Stian also pointed out, there is no standardized way of dealing with javascript, moreover, when we pull this off and we reach v1.0, developers will have doubts if they should make their new and shiny extension dependant on some plugin, since this will come along with coding standards, file structures and class dependencies and will also require the end user to get the plugins:

Stian remarks:

  "Your point about the JED is exactly why we eventually would either get  
  this included in the core, or it would all be a waste.
  By making into a standard, we would ensure developers got the tools  
  needed to guarantee compatibility with Joomla, and make it possible to  
  use another framework in Joomla in a clean way. "

And he has a really strong point here, we are doing this with the sole intention of bettering the framework by covering up something that by experience we see as a hole, and inherently adding a big feature that comes by a good and simple design IMHO, since we are not breaking any implementations at all. The most powerful part of this proposal, I think, are the coding standards and styles to come.

BUT

I do see and understand you point. Regardless of how good an addition to the framework could be, if you accepted this kind of stuff this easily you would end up with a bloated framework full of features that not everybody uses, making Joomla! development harder to understand. So what better way to validate this than with the very power of the community.

BUT

...then again, we don't want to waste good effort on something (since we all are technically confident about the solution) that might get lost as an excentric extension in the depths of JED, moreover, if we want this to be adopted on a massive scale we need time and effort (that I'm not sure we all have) to market the idea, the need and the tool.

I think we have a solid enough case to be considered seriously, or so the voices tell me.

I say the last thing because since its very start (here I go again), I've been following JFusion's development at early 2008... yeah, this is not as big as that, but there are many factors to consider to make this work at a massive scale without SOME KIND of official support, starting with some advice on the development on this thing so we can follow Joomla's way of doing things the best we can, since again, this is framework material.

Standards are not worth much if they are not supported, methinks, when looking at stuff like RDF.

So at least I think we could use really use some feedback from the core devs before we embark on this programatic venture, really, please.

[Amy Stephen]

Guys - We have to stop this discussion here. I did not realize before it was pointed out to me, but we are in the Joomla! Dev CMS email list.

Here is the purpose of that list:

Joomla CMS development (new). This list handles the development of the Joomla content management. We focus on the core development here, specific questions about extension development should go into general development. This list can be found at http://groups.google.com/group/joomla-dev-cms.

From http://community.joomla.org/blogs/leadership/724-development-coordinator-summit-summary.html

The core developers are trying to get to Joomla! 1.6 Alpha out the door *shortly* and this discussion is a distraction. We must quit asking them for feedback. They gave us their feedback.

There is a lot of work to finish for the community. It is unfair to keep pulling those who are focused on that commitment to set aside progress on the community's next release to give this discussion more time. There is not enough time to address this in 1.6. Raising discussion on 1.7 at this point is inappropriate.

There is work that we can do to help with 1.6. Does anyone want to help with the xHTML layout effort? Semantic HTML output for 1.6 - should be very nice for the community. I'll hook you up and that we *can* discuss here! :)

If this discussion is going to continue, though, find another location, perhaps the forums in the jQuery Joomlacode respository and post that link in here for others who want to continue.

Then, let's show proper respect and make certian any discussion in this mailing list focuses on 1.6 CMS development.

Amy

[Stian Didriksen]

I got a custom JParameter class with semantic xhtml strict valid output.

I don't know what the status of JParameter is, or if it's deprecated in favor of the new JForms api, but thought I'd mention.

[Amy Stephen]

New location, please! We need to move this discussion.

[pollen8]

Have to completely agree with what G. D. Speer said, J1.6 does have a
standard of using mootools, and if 3rd parties decide to implement
another JS library then they ARE asking for compatibility issues
(prototype and mootools for example are incompatible I believe) - in
fact any library that extends JS native objects is likely to produce
potential clashes. Changing the core stance on which lib to use (or
saying that you can use any) is a big decision

There is really very little reason (again imho) to choose one JS lib
over another, I see the growth in JQuery based Joomla components as
more of a reflection that the jQuery community has done a better job
at promoting itself and possibly its coding style is more suited to
simple DOM manipulations than mootools (whereas mootools has a cleaner
method of doing class based coding - see
http://www.clientcide.com/3rd-party-libraries/jquery-vs-mootools-mootools-vs-jquery/
for a great summary of the two libs)

I have had years of doing day in day out support on Fabrik users
sites, I can't count the number of times that a reported 'bug' in my
code was in fact some weird issue to do with conflicting JS libs,
that's why I was stoked in J1.6 about mootools being declared the JS
lib of choice. Previously I had a tonne of issues with Rockettheme
templates conflicting with mootools code, but since they now use
mootools those days are now over.

Now perhaps what's being proposed here might help with these
conflicts, however, I have a feeling it could simply open a bigger can
of worms for those of us who have to support components, and the
benefits stated seem more targeted at developers than end users. I
can already see users outcrys about "Joomla loads too slow - its
loading 5 javascript libraries" (easily done if you components/plugins/
modules all try to load different libraries) - there's already an over
proportionate (imho) outcry about mootools being loaded for J content
captions.

[Amy Stephen]

Thanks Rob - unfortunately, the original post, that you are responding
too, really should have been made in the Joomla! General Development
list. We are continuing that discussion there rather than disrupt 1.6
progress.

Let's use this thread here ->
http://groups.google.com/group/joomla-dev-general/browse_thread/thread/882bb589b298091b?hl=en-GB

Thanks all!

On 13 June, 07:40, pollen8 <r...@pollen-8.co.uk> wrote:
> Have to completely agree with what G. D. Speer said, J1.6 does have a
> standard of using mootools, and if 3rd parties decide to implement
> another JS library then they ARE asking for compatibility issues
> (prototype and mootools for example are incompatible I believe) - in
> fact any library that extends JS native objects is likely to produce
> potential clashes. Changing the core stance on which lib to use (or
> saying that you can use any) is a big decision
>
> There is really very little reason (again imho) to choose one JS lib
> over another, I see the growth in JQuery based Joomla components as
> more of a reflection that the jQuery community has done a better job
> at promoting itself and possibly its coding style is more suited to
> simple DOM manipulations than mootools (whereas mootools has a cleaner

> method of doing class based coding - seehttp://www.clientcide.com/3rd-party-libraries/jquery-vs-mootools-moot...