Joomla! Clientcide plugin, is there any?

7 views
Skip to first unread message

Daniel Peraza

unread,
May 2, 2011, 1:53:15 PM5/2/11
to Clientcide
Hi, I wonder if anybody has worked on a Clientcide plugin for Joomla!,
or if at least there's anybody willing to. I think I might contribute
a bit.

Aaron Newton

unread,
May 2, 2011, 1:56:15 PM5/2/11
to clien...@googlegroups.com
What would that entail? I don't use Joomla personally, so I don't know what it would take...


--
You received this message because you are subscribed to the Google Groups "Clientcide" group.
To post to this group, send email to clien...@googlegroups.com.
To unsubscribe from this group, send email to clientside+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clientside?hl=en.


Daniel Antonio Peraza Cedrez

unread,
May 2, 2011, 2:22:15 PM5/2/11
to clien...@googlegroups.com

El 02/05/2011, a las 13:26, Aaron Newton escribió:

> What would that entail? I don't use Joomla personally, so I don't know what it would take...

Joomla! includes Mootools Core by default. Latest 1.6 version include Mootools 1.3. Older versions used to include mootools 1.1, but from Joomla! 1.20+ there is a plugin called mtupgrade, which allows us to use Mootools 1.2 instead (which in turn, with few changes would allow to use Mootools 1.3).

I think that as first try, a Clientcide plugin would allow to include the whole Clientcide library from a local file, either compressed or not, jut by calling JHTML::_('behavior.clientcide') from within PHP, just the same way Mootools is loaded: JHTML::_('behavior.mootools').

The next step would be to allow the programmer to include a customized Clientcide version as an option, so that he/she may use just the Clientcide classes he/she needs. This customized version should be automatically generated through a download API, and injected into the corresponding JDocument (the PHP class that Joomla! uses to represent a document).

Finally, we might provide JHTMLBehavior subclasses to allow Joomla! programmers use Clientcide in a transparent manner, this is, to encapsulate the CSS/HTML/Javascript generation needed to use the coolest Clientcide features into a single PHP class. Joomla! does something similar with SqueezeBox, Mootree and Fx.Slide.

I'm not such a great Joomla! expert, but I can collaborate with the PHP coding. The JavaScript coding is open to anyone willing to participate.

Aaron Newton

unread,
May 2, 2011, 3:59:55 PM5/2/11
to clien...@googlegroups.com
Joomla! includes Mootools Core by default. Latest 1.6 version include Mootools 1.3. Older versions used to include mootools 1.1, but from Joomla! 1.20+ there is a plugin called mtupgrade, which allows us to use Mootools 1.2 instead (which in turn, with few changes would allow to use Mootools 1.3).

I wrote that plugin. Well, the javascript at least. I don't know how it's packaged inside Joomla, there may be more to it.
 
I think that as first try, a Clientcide plugin would allow to include the whole Clientcide library from a local file, either compressed or not, jut by calling JHTML::_('behavior.clientcide') from within PHP, just the same way Mootools is loaded: JHTML::_('behavior.mootools').

Hmmm. I don't really encourage people to include clientcide wholesale. (The same thing is true of MooTools More; no one should need ALL of it.)
 
The next step would be to allow the programmer to include a customized Clientcide version as an option, so that he/she may use just the Clientcide classes he/she needs. This customized version should be automatically generated through a download API, and injected into the corresponding JDocument (the PHP class that Joomla! uses to represent a document).

Aside from the fact that my current release is blocked on the current state of my download builder (the new MooTools dependency graph uses YAML headers and my current builder looks for the old scripts.json. I need to upgrade it to the new stuff), that's essentially what clientcide lets you do; you just include the bits you want.
 
Finally, we might provide JHTMLBehavior subclasses to allow Joomla! programmers use Clientcide in a transparent manner, this is, to encapsulate the CSS/HTML/Javascript generation needed to use the coolest Clientcide features into a single PHP class. Joomla! does something similar with SqueezeBox, Mootree and Fx.Slide.

I've been using this guy (which I wrote) to do that w/o the server doing that work:

 
I'm not such a great Joomla! expert, but I can collaborate with the PHP coding. The JavaScript coding is open to anyone willing to participate.

My problem is that I'm tapped out. My job is pretty demanding and I write a LOT of JavaScript all day long. I push a lot of it to github but generally don't have time to release it (that is, to make it easy to consume by others). After my job, I work on MooTools More (and do stuff like write that upgrade helper for Joomla's community). This is a higher priority than the clientcide libraries (MooTools More's contents were originally Clientcide plugins, easily 60% of it originated on Clientcide and then moved to MooTools when More was launched). After I spend time on More, fixing bugs and helping with new features and releases, I have whatever time is left to work on Clientcide. This is why it's so far behind (it's github repo runs on MooTools 1.3, but my release on clientcide.com is still stuck on 1.2 because of the aforementioned download builder issue).

So spending time doing PHP binding for these libraries is probably not something I can make time to help with. If there's something that needs to happen to the JS to make it possible to do it, I can pull fixes from you guys and offer a little support, but that's about it.

I do, however, encourage you to do whatever you want with the library; if you spend the time to make a Joomla plugin you have my blessing, encouragement, and (unfortunately limited) support.

Aaron

Daniel Antonio Peraza Cedrez

unread,
May 2, 2011, 4:18:48 PM5/2/11
to clien...@googlegroups.com
My problem is that I'm tapped out. My job is pretty demanding and I write a LOT of JavaScript all day long. I push a lot of it to github but generally don't have time to release it (that is, to make it easy to consume by others). After my job, I work on MooTools More (and do stuff like write that upgrade helper for Joomla's community). This is a higher priority than the clientcide libraries (MooTools More's contents were originally Clientcide plugins, easily 60% of it originated on Clientcide and then moved to MooTools when More was launched). After I spend time on More, fixing bugs and helping with new features and releases, I have whatever time is left to work on Clientcide. This is why it's so far behind (it's github repo runs on MooTools 1.3, but my release on clientcide.com is still stuck on 1.2 because of the aforementioned download builder issue).

So spending time doing PHP binding for these libraries is probably not something I can make time to help with. If there's something that needs to happen to the JS to make it possible to do it, I can pull fixes from you guys and offer a little support, but that's about it.


I fully understand your point. But I wrote this post with the hope to find somebody else (even may be somebody more experienced) willing to participate.

So if there's anybody in the group who may want to take the challenge, just write back!.

Besides that, given the current status of the clientcide libs, what do you think is the best? I mean, as you work on Mootools More, the Clientcide libs will be progressively included into Mootools, which in turn, will result in Joomla! including the whole Clientcide library as well, as part of the Mootools framework. In that case, I think the wait-and-see strategy will be the best in the long term.

Aaron Newton

unread,
May 2, 2011, 4:24:45 PM5/2/11
to clien...@googlegroups.com
Besides that, given the current status of the clientcide libs, what do you think is the best? I mean, as you work on Mootools More, the Clientcide libs will be progressively included into Mootools, which in turn, will result in Joomla! including the whole Clientcide library as well, as part of the Mootools framework. In that case, I think the wait-and-see strategy will be the best in the long term.

I seriously doubt any of the remaining Clientcide libs will ever be pulled into MooTools More. The difference between what's in More and what's in Clientcide is that the stuff in More is generic while the stuff in Clientcide is a more specific implementation. More gives you basic things like Accordion and Form.Validator, while the stuff left in Clientcide is more specific to my tastes (pointy tips, stickywin, etc).
Reply all
Reply to author
Forward
0 new messages