New location, please! We need to move this discussion.On Fri, Jun 12, 2009 at 9:15 AM, Stian Didriksen <st...@ninjatheme.com> wrote:
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.
Den 12. juni. 2009 kl. 14.49 skrev 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.
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.
AmyOn Fri, Jun 12, 2009 at 1:36 AM, dukeofgaming <dukeof...@gmail.com> wrote:<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.
On Thu, Jun 11, 2009 at 4:53 PM, G. D. Speer <gsp...@cortech.org> wrote:> 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 CanasaSent: Thursday, June 11, 2009 8:37 AMSubject: Re: Universal JS Framework integrationThank 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
On Thu, Jun 11, 2009 at 10:17 PM, Amy Stephen <amyst...@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 9:06 AM, Amy Stephen <amyst...@gmail.com> wrote:
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.
On Thu, Jun 11, 2009 at 6:20 AM, Israel Dacanay Canasa <rae...@gmail.com> wrote:
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
On Thu, Jun 11, 2009 at 6:13 AM, dukeofgaming <dukeof...@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">
!!!!!!!! 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?
Version: 8.5.339 / Virus Database: 270.12.62/2168 - Release Date: 06/10/09 18:30:00
mark_up asks: Why are there (hundreds of thousands of?) websites out there with 70KB of JavaScript just to show captions.. which are rarely even used?
Rob Schley answers: Because the community didn’t object loudly enough to make us reconsider that decision. We do the best we can. We don’t always make the best decisions but we usually try to make the right one. Sometimes people come along and ask if we considered X or Z or whatever and sometimes the answer is no but unless that dialog happens, the community might get stuck with whatever crazy idea we came up with at 4:00 AM after drinking 9 cans of Redbull and not sleeping for 2 days. This is why community involvement is important.