[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
I think it is important for jQuery to have at least a package management tool. an example of use case is: - two plugins shares same name of jquery extensions. plugin a : jQuery.fn.func1, jQuery.fn.func2 plugin b: jQuery.fn.func1 - jQuery.fn.func2 depends on jQuery.fn.func1 - you need jQuery.fn.func2 from plugin a and jQuery.fn.func1 from plugin b. - loading plugin b would break plugin a What we need is, a way to isolate each plugin, so plugin a and b work seamlessly together. My approach would be that jQuery can have multiple instance. with each instance having their own $.fn. And each instance is able to export and import properties and of course plugins. Here is a mockup on how it could be done: http://friendpaste.com/2EIjWUxrWqQ8qFcjtc3RSQ here a implementation example (experimental packaging tool, without jquery): http://github.com/raid-ox/xi/tree/master What do you think? On Apr 29, 7:29 am, William Chang diehardb...@gmail.com wrote: @Justin Meyer @John Resig Put it this way... This is how I think jQuery (the core library) is like a global/ singleton object that can be used anywhere or in MVC/Classical Inheritance/OOP all the classes are inherit from jQuery undisclosed, because it is the ultimate parent. The JavaScriptMVC is great and I think it compliment jQuery well, as long it lets you use the jQuery object anywhere. I don't want jQuery to reinvent the wheel to be another MVC or MooTools Class (file Class.js) framework. If we want MVC/Classical Inheritance/OOP, then jQuery should recognize and extend from JavaScriptMVC to be part of jQuery documentation (on best practices and coding conventions) for: - File names - Method names - Method structures - Testing - Documentation - Packaging The third parties libraries like jQuery UI or plugins, yes, need overload/override/extensibility/modularity in them by default and jQuery (the core) should be static. Sincerely, William Changhttp://www.williamchang.org On Apr 28, 12:49 pm, Justin Meyer justinbme...@gmail.com wrote: Tres, Besides plugining your own framework is there a reason why you don't think JMVC is for jQuery? You yourself even express the needed for tighter control of jQuery and have gone as far as building your own tool. At it's center I a proposing a standard way of organizing the only things a JavaScript application actually does: Respond to events Request data / manipulate services/ Ajax Wrap the service data Update the DOM. Why do you think JavaScriptMVC is over doing it? Because it is more than one file? That is actually a huge advantage ... it allows developers to add only the functionality they need without having to worry about compression. If you are going to share a 'harsh opinion' please provide reasons for why the above Controller and View wouldn't be useful. If you can, I think you'd be the first person who doesn't like them - especially controller ... I mean, just look at that syntax ... your function names are what they respond to ... and who doesn't like event delegation? In fact, I'll take the pepsi challenge and promise that with JMVC's tools that I can create easier to understand and modify code, faster, than with jQuery alone. John has posted some valid points about how some of JMVC's features, namely class, could invade the core. However, I'm not sure if even John has worked on projects as large and complex as those that have prompted JMVC. In these projects, a wiki of suggestions is not going to be enough to refine a large group of limited skill developers code so that it is maintainable. However, for the (lucky?) few that find themselves losing the reins of apps that make Gmail look small, there will be an jQuery based solution for them. I'm hoping to find a few who are willing to help me perfect the tools and techniques. If you do want to explore these techniques I'm super pumped to work with you. Just let me know what you think jQuery needs. However, more than one file is a good thing :). @DBJ 2-4 is all done in JMVC. Please let me know if you have any comments on the above syntax. On Apr 28, 8:07 am, tres treshug...@gmail.com wrote: Justin, I think you have some good points about what you are trying to achieve, but personally, I don't think jMVC is for jQuery. I would be interested in collaborating on some projects such as this in the jQuery realm, though. I have done a bit of development on something similar (although, it's one JS file ;) ) and have recently implemented the execution of javascript files withing the context of part of the DOM as well as (previously) lazy loading, caching and namespacing while taking bits from ruby on rails, zend as well as my personal php mvc framework. Sorry. Harsh opinion, but I wouldn't be me without it. If your interested on working on some projects (as well as other people), I'd love to
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
If anyone out there is still interested ... I just put up the first
alpha. It's pretty slick. You can find it here:
http://javascriptmvc.com/wiki/index.php?title=Downloads
I re-mapped JMVC's Controller, View, and Class to work nicer with
jQuery. And, compression works with the latest env.js.
Here's how class basically works:
$.Class.extend(Name.Of.MyClass,{
static : function(){return 'static' }
},{
init : function( val){
this.val = val;
}
proto : function(){ return this.val }
})
Name.Of.MyClass.static() // - static
new Name.Of.MyClass(''proto').proto() // - proto
Name.Of.MyClass.extend(NewClassName,{},{}) //- NewClassName
Here's how a very simple 'show content' controller could work:
$.Controller.extend(ShowController,{},{
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle(); //find it inside the 'wrapped'
element
ev.preventDefault() //prevent browser from auto-scrolling there
}
})
You could add this to any collection of a's like the following:
div id='mycollection'
a href='#place_to_open'Open/a
p id='place_to_open'Blah Blah/p
/div
$('#mycollection').show_controller();
Honestly ... what could be better than that I mean really. That
has got to be the nicest way of defining and grouping functionality
just about ever.
A few more things about this.
When you 'add' show controller to mycollection it does the following:
adds the class name 'show_controller' to mycollection making it easy
to figure out what controllers are responding to mycollection just by
inspecting the dom.
puts the controller in the element's data so you can get it like:
$('#mycollection').data('show_controller')
And remove all functionality like:
$('#mycollection').data('show_controller').destroy();
You can also have 'setup' functionality. Lets say we wanted to hide
everything in our element that matched some selector, we could add an
init function:
$.Controller.extend(ShowController,{},{
init : function(element, hideSelector){
this._super(element); //sets the element to delegate from and
this.element
this.element.find(hideSelector).hide()
},
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle(); //find it inside the 'wrapped'
element
ev.preventDefault() //prevent browser from auto-scrolling there
}
})
now we could call it like:
$('#mycollection').show_controller('p');
How fantastic is that. This can be better for jQuery that the jersey
we gave John.
And if you wanted to extend the functionality and make it your own:
ShowController.extend(MyShowController,{},{
'a click' : function(el, ev){
this._super(el, ev)
el.text( el[0].style.display == ? hide : show ) //says
hide or show
}
})
Oh, I almost forgot views:
$(.some_thing).append({view '/url/to/view', data: {message:
hello_world}})
in /url/to/view.ejs
h1%= message %/h1
prepend, after, before,replace,text,html all work too.
Now that I got a rough draft ... I'm really looking for people who
want to take this project to the next level with me. Give me a shout
if you are interested and what you think - justinbme...@gmail.com
John, let me know if there is a better place for this. It's very
jQuery related, but don't want to be spamming anyone.
My next step is hardening the API and getting rhino and selenium
testing working.
On Mar 1, 7:33 am, tres treshug...@gmail.com wrote:
I realized after I made my last post (#57) I realized that you
described almost exactly what I had just built :). Sort of like
finding money behind the couch!
Try:http://code.google.com/p/jquery-plugin-dev/source/browse/trunk/jquery
Anyways, I am not trying to say MVC is over-engineering in practice as
I do understand the need for organization, code-reuse and convention
(I've authored my own PHP5 MVC framework), but currently I think that
with JavaScript, there needs to be a happy medium between performance,
organization and convention. Separating these out into at least 3
server calls per page, plus extra processing time that comes from
dispatching and routing, has the potential for a bit of overhead,
especially in a large application.
UI, being as dynamic as it is, calls for many different situations
where you might respond to an event by posting a form via ajax, and
when that is done manipulating the DOM accordingly. As simple as that
seems, more often than not something will vary with the way JavaScript
will have to handle the user's last interaction. Sometimes, simple
conventions and organization is less work and easier to maintain. The
simplest answer is usually the best answer (within reason, though).
But that is just my opinion.
Cheers,
Trey
On Feb 27, 6:03 am, Justin Meyer justinbme...@gmail.com wrote:
@Trey,
You created a plugin to deal with the exact problems we have been
talking about :).
Have you developed a JS
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Justin,
I think you have some good points about what you are trying to
achieve, but personally, I don't think jMVC is for jQuery. I would be
interested in collaborating on some projects such as this in the
jQuery realm, though. I have done a bit of development on something
similar (although, it's one JS file ;) ) and have recently implemented
the execution of javascript files withing the context of part of the
DOM as well as (previously) lazy loading, caching and namespacing
while taking bits from ruby on rails, zend as well as my personal php
mvc framework.
Sorry. Harsh opinion, but I wouldn't be me without it. If your
interested on working on some projects (as well as other people), I'd
love to hear back from you.
--
Trey
On Apr 28, 4:40 pm, Justin Meyer justinbme...@gmail.com wrote:
If anyone out there is still interested ... I just put up the first
alpha. It's pretty slick. You can find it here:
http://javascriptmvc.com/wiki/index.php?title=Downloads
I re-mapped JMVC's Controller, View, and Class to work nicer with
jQuery. And, compression works with the latest env.js.
Here's how class basically works:
$.Class.extend(Name.Of.MyClass,{
static : function(){return 'static' }},{
init : function( val){
this.val = val;
}
proto : function(){ return this.val }
})
Name.Of.MyClass.static() // - static
new Name.Of.MyClass(''proto').proto() // - proto
Name.Of.MyClass.extend(NewClassName,{},{}) //- NewClassName
Here's how a very simple 'show content' controller could work:
$.Controller.extend(ShowController,{},{
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle(); //find it inside the 'wrapped'
element
ev.preventDefault() //prevent browser from auto-scrolling there
}
})
You could add this to any collection of a's like the following:
div id='mycollection'
a href='#place_to_open'Open/a
p id='place_to_open'Blah Blah/p
/div
$('#mycollection').show_controller();
Honestly ... what could be better than that I mean really. That
has got to be the nicest way of defining and grouping functionality
just about ever.
A few more things about this.
When you 'add' show controller to mycollection it does the following:
adds the class name 'show_controller' to mycollection making it easy
to figure out what controllers are responding to mycollection just by
inspecting the dom.
puts the controller in the element's data so you can get it like:
$('#mycollection').data('show_controller')
And remove all functionality like:
$('#mycollection').data('show_controller').destroy();
You can also have 'setup' functionality. Lets say we wanted to hide
everything in our element that matched some selector, we could add an
init function:
$.Controller.extend(ShowController,{},{
init : function(element, hideSelector){
this._super(element); //sets the element to delegate from and
this.element
this.element.find(hideSelector).hide()
},
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle(); //find it inside the 'wrapped'
element
ev.preventDefault() //prevent browser from auto-scrolling there
}
})
now we could call it like:
$('#mycollection').show_controller('p');
How fantastic is that. This can be better for jQuery that the jersey
we gave John.
And if you wanted to extend the functionality and make it your own:
ShowController.extend(MyShowController,{},{
'a click' : function(el, ev){
this._super(el, ev)
el.text( el[0].style.display == ? hide : show ) //says
hide or show
}
})
Oh, I almost forgot views:
$(.some_thing).append({view '/url/to/view', data: {message:
hello_world}})
in /url/to/view.ejs
h1%= message %/h1
prepend, after, before,replace,text,html all work too.
Now that I got a rough draft ... I'm really looking for people who
want to take this project to the next level with me. Give me a shout
if you are interested and what you think - justinbme...@gmail.com
John, let me know if there is a better place for this. It's very
jQuery related, but don't want to be spamming anyone.
My next step is hardening the API and getting rhino and selenium
testing working.
On Mar 1, 7:33 am, tres treshug...@gmail.com wrote:
I realized after I made my last post (#57) I realized that you
described almost exactly what I had just built :). Sort of like
finding money behind the couch!
Try:http://code.google.com/p/jquery-plugin-dev/source/browse/trunk/jquery
Anyways, I am not trying to say MVC is over-engineering in practice as
I do understand the need for organization, code-reuse and convention
(I've authored my own PHP5 MVC framework), but currently I think that
with JavaScript, there needs to be a happy medium between performance,
organization and convention. Separating these out into at least 3
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Recap ...
1.
JR has a strategy with which I agree right now.
The whole jQ movement matures very quickly. If anything jQ lacks it
is one thing: stability. I think, jQ right now, before anything else
needs much better Wiki, full of usefull conceptual material, diagrams,
samples etc. And I can not be happier when I see that JR et. all. do
realise that.
2.
OO: we (IT community) have nothing better (yet). Feel free to dive in.
It is mature and proven and mutch older thank you think ;o)
3.
MVC: one of the oldest OOA concepts (we are talking 70's here!).
Things have advanced since then ... considerably. (sideline: But not
for M$FT , who is trumpeting MVC 30+ years later, after OO disasters
like MFC, COM and yes, .NET )
4.
Inheritance : somehow it turns out that the trully usefull software is
never based on inheritance. c++ stdlib (aka stl) and loads of others,
including jQuery. Keep that in mind. There must be a reason for that.
5.
The last but not the least is a little herresy: JavaScript is not the
best programing language ever. It is invented with a very strict and
narrow scope. Maybe one could consider more appropriate or mature
languages for server side, like : ... Python or PHP? Even Java will
do ;o) Oh, and there is always c++ ;o)
ECMA 4 (http://www.ecmascript.org/es4/spec/overview.pdf) is based on
the same assumption (about current JavaScript). Unfortunately it is
fundamentaly wrong and too late anyway. So look elsewhere ;o)
My five points . Thanks for persevering and reading all the way till
here...
--- DBJ
On Apr 28, 2:07 pm, tres treshug...@gmail.com wrote:
Justin,
I think you have some good points about what you are trying to
achieve, but personally, I don't think jMVC is for jQuery. I would be
interested in collaborating on some projects such as this in the
jQuery realm, though. I have done a bit of development on something
similar (although, it's one JS file ;) ) and have recently implemented
the execution of javascript files withing the context of part of the
DOM as well as (previously) lazy loading, caching and namespacing
while taking bits from ruby on rails, zend as well as my personal php
mvc framework.
Sorry. Harsh opinion, but I wouldn't be me without it. If your
interested on working on some projects (as well as other people), I'd
love to hear back from you.
--
Trey
On Apr 28, 4:40 pm, Justin Meyer justinbme...@gmail.com wrote:
If anyone out there is still interested ... I just put up the first
alpha. It's pretty slick. You can find it here:
http://javascriptmvc.com/wiki/index.php?title=Downloads
I re-mapped JMVC's Controller, View, and Class to work nicer with
jQuery. And, compression works with the latest env.js.
Here's how class basically works:
$.Class.extend(Name.Of.MyClass,{
static : function(){return 'static' }},{
init : function( val){
this.val = val;
}
proto : function(){ return this.val }
})
Name.Of.MyClass.static() // - static
new Name.Of.MyClass(''proto').proto() // - proto
Name.Of.MyClass.extend(NewClassName,{},{}) //- NewClassName
Here's how a very simple 'show content' controller could work:
$.Controller.extend(ShowController,{},{
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle(); //find it inside the 'wrapped'
element
ev.preventDefault() //prevent browser from auto-scrolling there
}
})
You could add this to any collection of a's like the following:
div id='mycollection'
a href='#place_to_open'Open/a
p id='place_to_open'Blah Blah/p
/div
$('#mycollection').show_controller();
Honestly ... what could be better than that I mean really. That
has got to be the nicest way of defining and grouping functionality
just about ever.
A few more things about this.
When you 'add' show controller to mycollection it does the following:
adds the class name 'show_controller' to mycollection making it easy
to figure out what controllers are responding to mycollection just by
inspecting the dom.
puts the controller in the element's data so you can get it like:
$('#mycollection').data('show_controller')
And remove all functionality like:
$('#mycollection').data('show_controller').destroy();
You can also have 'setup' functionality. Lets say we wanted to hide
everything in our element that matched some selector, we could add an
init function:
$.Controller.extend(ShowController,{},{
init : function(element, hideSelector){
this._super(element); //sets the element to delegate from and
this.element
this.element.find(hideSelector).hide()
},
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle(); //find it inside the 'wrapped'
element
ev.preventDefault() //prevent browser from auto-scrolling there
}
})
now we could call it like:
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Tres,
Besides plugining your own framework is there a reason why you don't
think JMVC is for jQuery? You yourself even express the needed for
tighter control of jQuery and have gone as far as building your own
tool.
At it's center I a proposing a standard way of organizing the only
things a JavaScript application actually does:
Respond to events
Request data / manipulate services/ Ajax
Wrap the service data
Update the DOM.
Why do you think JavaScriptMVC is over doing it? Because it is more
than one file? That is actually a huge advantage ... it allows
developers to add only the functionality they need without having to
worry about compression.
If you are going to share a 'harsh opinion' please provide reasons for
why the above Controller and View wouldn't be useful. If you can, I
think you'd be the first person who doesn't like them - especially
controller ... I mean, just look at that syntax ... your function
names are what they respond to ... and who doesn't like event
delegation? In fact, I'll take the pepsi challenge and promise that
with JMVC's tools that I can create easier to understand and modify
code, faster, than with jQuery alone.
John has posted some valid points about how some of JMVC's features,
namely class, could invade the core. However, I'm not sure if even
John has worked on projects as large and complex as those that have
prompted JMVC. In these projects, a wiki of suggestions is not going
to be enough to refine a large group of limited skill developers code
so that it is maintainable.
However, for the (lucky?) few that find themselves losing the reins of
apps that make Gmail look small, there will be an jQuery based
solution for them. I'm hoping to find a few who are willing to help
me perfect the tools and techniques.
If you do want to explore these techniques I'm super pumped to work
with you. Just let me know what you think jQuery needs. However,
more than one file is a good thing :).
@DBJ 2-4 is all done in JMVC. Please let me know if you have any
comments on the above syntax.
On Apr 28, 8:07 am, tres treshug...@gmail.com wrote:
Justin,
I think you have some good points about what you are trying to
achieve, but personally, I don't think jMVC is for jQuery. I would be
interested in collaborating on some projects such as this in the
jQuery realm, though. I have done a bit of development on something
similar (although, it's one JS file ;) ) and have recently implemented
the execution of javascript files withing the context of part of the
DOM as well as (previously) lazy loading, caching and namespacing
while taking bits from ruby on rails, zend as well as my personal php
mvc framework.
Sorry. Harsh opinion, but I wouldn't be me without it. If your
interested on working on some projects (as well as other people), I'd
love to hear back from you.
--
Trey
On Apr 28, 4:40 pm, Justin Meyer justinbme...@gmail.com wrote:
If anyone out there is still interested ... I just put up the first
alpha. It's pretty slick. You can find it here:
http://javascriptmvc.com/wiki/index.php?title=Downloads
I re-mapped JMVC's Controller, View, and Class to work nicer with
jQuery. And, compression works with the latest env.js.
Here's how class basically works:
$.Class.extend(Name.Of.MyClass,{
static : function(){return 'static' }},{
init : function( val){
this.val = val;
}
proto : function(){ return this.val }
})
Name.Of.MyClass.static() // - static
new Name.Of.MyClass(''proto').proto() // - proto
Name.Of.MyClass.extend(NewClassName,{},{}) //- NewClassName
Here's how a very simple 'show content' controller could work:
$.Controller.extend(ShowController,{},{
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle(); //find it inside the 'wrapped'
element
ev.preventDefault() //prevent browser from auto-scrolling there
}
})
You could add this to any collection of a's like the following:
div id='mycollection'
a href='#place_to_open'Open/a
p id='place_to_open'Blah Blah/p
/div
$('#mycollection').show_controller();
Honestly ... what could be better than that I mean really. That
has got to be the nicest way of defining and grouping functionality
just about ever.
A few more things about this.
When you 'add' show controller to mycollection it does the following:
adds the class name 'show_controller' to mycollection making it easy
to figure out what controllers are responding to mycollection just by
inspecting the dom.
puts the controller in the element's data so you can get it like:
$('#mycollection').data('show_controller')
And remove all functionality like:
$('#mycollection').data('show_controller').destroy();
You can also have 'setup' functionality. Lets say we wanted to hide
everything in our element that matched some selector, we could add an
init
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Sorry, I didn't mean to offend you. What it really comes down to, I
think, is two different methods to tackle the same problem. I like
your initiative and enthusiasm and it's nice to see someone else out
there who sees a need for organization with JavaScript.
My *opinion* that it isn't for jQuery rests in the fact that although
your mvc model is more structured, it isn't as concise and as geared
toward rapid development as jQuery is. I am not saying people should
use what I wrote, or start a framework war. I am just stating, more or
less, my opinion. I myself don't believe there exactly needs to be a
model, controller and view *for javascript*. I do however, believe JS
should be separated into multiple files and with things like
DUI.stream (Digg UI Streams), this could easily become more
commonplace very soon.
I'd love to talk with you about my views toward JavaScript and MVC,
but I'm a little pressed for time at the moment.
Much good could come out of this and I would be excited to collaborate
on this as I really believe that you have some great points. Feel free
to email me anytime.
Cheers,
Trey
On Apr 29, 2:49 am, Justin Meyer justinbme...@gmail.com wrote:
Tres,
Besides plugining your own framework is there a reason why you don't
think JMVC is for jQuery? You yourself even express the needed for
tighter control of jQuery and have gone as far as building your own
tool.
At it's center I a proposing a standard way of organizing the only
things a JavaScript application actually does:
Respond to events
Request data / manipulate services/ Ajax
Wrap the service data
Update the DOM.
Why do you think JavaScriptMVC is over doing it? Because it is more
than one file? That is actually a huge advantage ... it allows
developers to add only the functionality they need without having to
worry about compression.
If you are going to share a 'harsh opinion' please provide reasons for
why the above Controller and View wouldn't be useful. If you can, I
think you'd be the first person who doesn't like them - especially
controller ... I mean, just look at that syntax ... your function
names are what they respond to ... and who doesn't like event
delegation? In fact, I'll take the pepsi challenge and promise that
with JMVC's tools that I can create easier to understand and modify
code, faster, than with jQuery alone.
John has posted some valid points about how some of JMVC's features,
namely class, could invade the core. However, I'm not sure if even
John has worked on projects as large and complex as those that have
prompted JMVC. In these projects, a wiki of suggestions is not going
to be enough to refine a large group of limited skill developers code
so that it is maintainable.
However, for the (lucky?) few that find themselves losing the reins of
apps that make Gmail look small, there will be an jQuery based
solution for them. I'm hoping to find a few who are willing to help
me perfect the tools and techniques.
If you do want to explore these techniques I'm super pumped to work
with you. Just let me know what you think jQuery needs. However,
more than one file is a good thing :).
@DBJ 2-4 is all done in JMVC. Please let me know if you have any
comments on the above syntax.
On Apr 28, 8:07 am, tres treshug...@gmail.com wrote:
Justin,
I think you have some good points about what you are trying to
achieve, but personally, I don't think jMVC is for jQuery. I would be
interested in collaborating on some projects such as this in the
jQuery realm, though. I have done a bit of development on something
similar (although, it's one JS file ;) ) and have recently implemented
the execution of javascript files withing the context of part of the
DOM as well as (previously) lazy loading, caching and namespacing
while taking bits from ruby on rails, zend as well as my personal php
mvc framework.
Sorry. Harsh opinion, but I wouldn't be me without it. If your
interested on working on some projects (as well as other people), I'd
love to hear back from you.
--
Trey
On Apr 28, 4:40 pm, Justin Meyer justinbme...@gmail.com wrote:
If anyone out there is still interested ... I just put up the first
alpha. It's pretty slick. You can find it here:
http://javascriptmvc.com/wiki/index.php?title=Downloads
I re-mapped JMVC's Controller, View, and Class to work nicer with
jQuery. And, compression works with the latest env.js.
Here's how class basically works:
$.Class.extend(Name.Of.MyClass,{
static : function(){return 'static' }},{
init : function( val){
this.val = val;
}
proto : function(){ return this.val }
})
Name.Of.MyClass.static() // - static
new Name.Of.MyClass(''proto').proto() // - proto
Name.Of.MyClass.extend(NewClassName,{},{}) //- NewClassName
Here's how a very simple 'show content' controller could work:
$.Controller.extend(ShowController,{},{
'a click'
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
@Justin Meyer
@John Resig
Put it this way...
This is how I think jQuery (the core library) is like a global/
singleton object that can be used anywhere or in MVC/Classical
Inheritance/OOP all the classes are inherit from jQuery undisclosed,
because it is the ultimate parent.
The JavaScriptMVC is great and I think it compliment jQuery well, as
long it lets you use the jQuery object anywhere. I don't want jQuery
to reinvent the wheel to be another MVC or MooTools Class (file
Class.js) framework. If we want MVC/Classical Inheritance/OOP, then
jQuery should recognize and extend from JavaScriptMVC to be part of
jQuery documentation (on best practices and coding conventions) for:
- File names
- Method names
- Method structures
- Testing
- Documentation
- Packaging
The third parties libraries like jQuery UI or plugins, yes, need
overload/override/extensibility/modularity in them by default and
jQuery (the core) should be static.
Sincerely,
William Chang
http://www.williamchang.org
On Apr 28, 12:49 pm, Justin Meyer justinbme...@gmail.com wrote:
Tres,
Besides plugining your own framework is there a reason why you don't
think JMVC is for jQuery? You yourself even express the needed for
tighter control of jQuery and have gone as far as building your own
tool.
At it's center I a proposing a standard way of organizing the only
things a JavaScript application actually does:
Respond to events
Request data / manipulate services/ Ajax
Wrap the service data
Update the DOM.
Why do you think JavaScriptMVC is over doing it? Because it is more
than one file? That is actually a huge advantage ... it allows
developers to add only the functionality they need without having to
worry about compression.
If you are going to share a 'harsh opinion' please provide reasons for
why the above Controller and View wouldn't be useful. If you can, I
think you'd be the first person who doesn't like them - especially
controller ... I mean, just look at that syntax ... your function
names are what they respond to ... and who doesn't like event
delegation? In fact, I'll take the pepsi challenge and promise that
with JMVC's tools that I can create easier to understand and modify
code, faster, than with jQuery alone.
John has posted some valid points about how some of JMVC's features,
namely class, could invade the core. However, I'm not sure if even
John has worked on projects as large and complex as those that have
prompted JMVC. In these projects, a wiki of suggestions is not going
to be enough to refine a large group of limited skill developers code
so that it is maintainable.
However, for the (lucky?) few that find themselves losing the reins of
apps that make Gmail look small, there will be an jQuery based
solution for them. I'm hoping to find a few who are willing to help
me perfect the tools and techniques.
If you do want to explore these techniques I'm super pumped to work
with you. Just let me know what you think jQuery needs. However,
more than one file is a good thing :).
@DBJ 2-4 is all done in JMVC. Please let me know if you have any
comments on the above syntax.
On Apr 28, 8:07 am, tres treshug...@gmail.com wrote:
Justin,
I think you have some good points about what you are trying to
achieve, but personally, I don't think jMVC is for jQuery. I would be
interested in collaborating on some projects such as this in the
jQuery realm, though. I have done a bit of development on something
similar (although, it's one JS file ;) ) and have recently implemented
the execution of javascript files withing the context of part of the
DOM as well as (previously) lazy loading, caching and namespacing
while taking bits from ruby on rails, zend as well as my personal php
mvc framework.
Sorry. Harsh opinion, but I wouldn't be me without it. If your
interested on working on some projects (as well as other people), I'd
love to hear back from you.
--
Trey
On Apr 28, 4:40 pm, Justin Meyer justinbme...@gmail.com wrote:
If anyone out there is still interested ... I just put up the first
alpha. It's pretty slick. You can find it here:
http://javascriptmvc.com/wiki/index.php?title=Downloads
I re-mapped JMVC's Controller, View, and Class to work nicer with
jQuery. And, compression works with the latest env.js.
Here's how class basically works:
$.Class.extend(Name.Of.MyClass,{
static : function(){return 'static' }},{
init : function( val){
this.val = val;
}
proto : function(){ return this.val }
})
Name.Of.MyClass.static() // - static
new Name.Of.MyClass(''proto').proto() // - proto
Name.Of.MyClass.extend(NewClassName,{},{}) //- NewClassName
Here's how a very simple 'show content' controller could work:
$.Controller.extend(ShowController,{},{
'a click' : function(el, ev){
var id = el.attr('href'); //get id we want to show
this.element.find(id ).toggle();
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
I realized after I made my last post (#57) I realized that you
described almost exactly what I had just built :). Sort of like
finding money behind the couch! Try:
http://code.google.com/p/jquery-plugin-dev/source/browse/trunk/jquery.plugin.js.
Anyways, I am not trying to say MVC is over-engineering in practice as
I do understand the need for organization, code-reuse and convention
(I've authored my own PHP5 MVC framework), but currently I think that
with JavaScript, there needs to be a happy medium between performance,
organization and convention. Separating these out into at least 3
server calls per page, plus extra processing time that comes from
dispatching and routing, has the potential for a bit of overhead,
especially in a large application.
UI, being as dynamic as it is, calls for many different situations
where you might respond to an event by posting a form via ajax, and
when that is done manipulating the DOM accordingly. As simple as that
seems, more often than not something will vary with the way JavaScript
will have to handle the user's last interaction. Sometimes, simple
conventions and organization is less work and easier to maintain. The
simplest answer is usually the best answer (within reason, though).
But that is just my opinion.
Cheers,
Trey
On Feb 27, 6:03 am, Justin Meyer justinbme...@gmail.com wrote:
@Trey,
You created a plugin to deal with the exact problems we have been
talking about :).
Have you developed a JS centered application, something that could
be considered a 'Thin-Server-Architecture' app?
When you build the entire HTML structure client side, a lack of a JS
template (View) is brutal.
If you only have raw services to work from, something that can wrap
and provide context to the data is essential.
Although widget.js comes close to a 'controller' anyway, wouldn't it
be great if you can make plugins like:
$.plugin('todo',{
init : function(element, options) {
//initialization code on the element
//uses something in 'data' as 'this' for state, instead of
this=element
this.created = true;
}
a.destroy click : function(element, event){
//uses event delegation to call without actually having to setup
delegation
this.destroyed = true;
},
destroyed : function(){ return this.destroyed } // a normal function
on the plugin
})
Widget.js could just see which functions look for events and setup
delegation on the element for you.
Now, what if you can create your plugin like:
var instances = $('.someClass').todo(options)
and it would return the 'instances' of the plugin you were operating
on so you could do something like:
instances[0].destroyed();
MVC isn't over-engineering in a 'large' project because it fits
perfects with what you always have to do.
-respond to events
-connect to/manipulate services
-wrap data from those services
-Build/manipulate HTML/DOM
Logically separating these concerns is extremely helpful. Doing it in
an organized and repeatable fashion is event more important.
@nicolas - I was never implying any of this should be part of the
core. It should not be. I was simply proposing that a new 'branch'
of jQuery is started with a focus on tools and structure needed for
large projects.
On Feb 25, 6:11 pm, tres treshug...@gmail.com wrote:
I think 'MVC as it states - Model, View, Controller - in JavaScript
terms, is over-engineering what doesn't need to be over-engineered.
jQuery in it's simplicity can evolve with a very complex application
quite nicely.
That being said, I have authored myself a plugin called jFrame in
order to help with code convention, organization as well as automated
loading. Works nicely for me.
-Trey
On Feb 25, 8:26 am, John Resig jere...@gmail.com wrote:
Ok, so boiling down a list:
Needs code:
- Widget utility (I'm working on this)
- Debugging utility
- Static plugin analyzer
Need a tutorial to cover the concepts of (I'm working on this):
- Encapsulation
- Extensibility
- Modularity
Needs (defined/documented) conventions:
- File names
- Method names
- Method structures
- Testing
- Documentation
- Packaging
Once the above conventions are finalized, that static plugin analyzer
can be written.
Once the widget code is done, the tutorial needs to be updated.
---
So, with that drawn in the sand, Justin, would you be interested in
working on the debugging plugin, the static analyzer, defining
conventions, all of the above?
Any/all of those would be a huge help and I'd imagine that if the work
is solid they should all become official jQuery projects/conventions.
Now I'm not discounting any additional code or patterns but we need to
start with what we have and make sure that we're working with the best
possible resources. If we define the above conventions and code we may
find that there is less of a need for a new project
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Hi guys,
I have written a couple of plugins that I'd to share. The first is an
MVC style mini-framework with the M and V (or C, depends on how you
look at it) stripped out of it. Anything more, IMHO, is overdoing it
no matter how large the project. It is called jFrame. It works on top
jQuery and provides a way to enforce convention and javascript code
separation. The other benefit from it is that it allows 'registry'
variables (accessible application-wide) and dispatch parameters which
get sent to the script that is being dispatched to and cleared
afterwards. Current plans are to remove prototyped methods, convert to
private functions and keep only the ones that are necessary. I put
those in for fun at first.
The second is a plugin for plugins. It takes John's idea with his
widget plugin (dare I say) a step farther and instead of just creating
another method in the jQuery namespace it allows you to create a new
plugin namespace with multiple methods. 'this', when inside of a given
plugin namespace is used in the same manner as when inside the jQuery
namespace, thus is interchangeable. Plugin methods are available on
'this', but jQuery methods aren't unless wrapped ($(this)). It also
includes a method in the jQuery scope for setting and auto-extending
options. It saves it as data to each object, so options for each
object on a given plugin can be changed independently. There's a
couple of more functions, but they're not worth mentioning at this
stage.
The original reason I wrote this is because I have a form validation
plugin that I wanted to namespace due to it containing a lot of
methods and was built more as a library than a widget. Currently
namespacing seems to consist of passing a string argument to a
function of the method you want to call and I didn't like that. So
instead of:
jQuery('ul').somePlugin('someMethod').somePlugin('anotherMethod',
'arg');
it would allow for:
jQuery('ul').plugin('somePlugin').someMethod().anotherMethod('arg');
If you want to chain the jQuery namespace back in:
jQuery('ul').options('somePlugin', {
opt1 : 'val1',
opt2 : 'val2'
}).plugin('somePlugin').aMethod().jQuery.find(' li').show();
Currently, argument handling hasn't been built in (hey, I started it
today on 3 hours of sleep!). No excuses, right?!
Now, these are just ideas and it is a work in progress as is jFrame. I
would love any input from you guys, especially John, as I feel they
both relate heavily to this thread. Let me know if you have any
questions or comments. Links below:
Plugin plugin (no pun):
http://code.google.com/p/jquery-plugin-dev/source/browse/trunk/jquery.plugin.js
jFrame plugin:
http://code.google.com/p/jquery-plugin-dev/source/browse/trunk/jquery.jFrame.js
Thanks,
Trey
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Having missed most of the discussion, I wanted to at least throw in some existing resources on the topic. For one, the Plugin Authoring guide covers a few of the requirements that Matt listed: http://docs.jquery.com/Plugins/Authoring On the topic of extending plugins, I covered one approach to that in my The Onion talk: http://www.slideshare.net/joern.zaefferer/the-onion-147705 On building robust plugins in general: http://www.slideshare.net/joern.zaefferer/building-robust-jquery-plugins-presentation (click the notes tab below the slides to get the notes for each slide) I still think that making plugins extensible isn't something you can throw a generic solution at. Finding extension points, exposing and documenting them is a unique process for every problem. My favorite example for such an extension point are custom methods for the validation plugin. There is a documented API (http://docs.jquery.com/Plugins/Validation/Validator/addMethod) to add methods, which makes the plugin very extensible in one direction. Jörn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Feb 26, 5:37 pm, chris thatcher thatcher.christop...@gmail.com wrote: I get both sides, though I'm sure there are more than two ;) What I'm hoping is that we can keep jQuery simple, clean elegant (we could burden plugin developers just a little more to pass muster.) Let UI focus on widgets. And add a spot for the railable patterns we need to scale to satisfy the next generation (meaning about 2 years at this point). the mvc stuff should pass all the ussual tests: look, feel, taste like jQuery. be small and effiecient and focused on real problems that arent alreay solved. +1. What I think Justin is proposing is to provide a framework that would *enforce* conventions, libraries/plugins and good practices. Note that, at least in my opinion, it's very different to show or define conventions in the docs than forcing them. I don't think the jQuery core should be changed, extended or branched in any way. Most of the things we need for this are already there (JMVC, QUnit, YUI Compressor, JSDoc, JSpec, ...). I believe that the point, however, is to provide a framework with a defined structure, where a developer shouldn't have to go over the docs to see what's the convention for doing X is. I feel that slowly more and more users will be developing larger projects, and maybe it would be useful to provide an out of the box solution where you could do something like: ~: jqcmd _project_name_ (init a project with default plugins as well as testing/debugging libraries and a well defined folder structure) ~: jqcmd plugin list ~: jqcmd plugin install _name_or_url_ ~: jqcmd generate plugin _name_ ~: jqcmd generate test _name_ ~: jqcmd tests:run In any case, I think what John listed are the steps just needed and would be the base for building such a tool. Needs code: - Widget utility (I'm working on this) - Debugging utility - Static plugin analyzer Need a tutorial to cover the concepts of (I'm working on this): - Encapsulation - Extensibility - Modularity Needs (defined/documented) conventions: - File names - Method names - Method structures - Testing - Documentation - Packaging So I think it's time to help with that first and then see where all these definitions takes us. Is there a place where all this stuff is being discussed (separatedly)? --Luciano. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Heads up: I just updated that page because it was a little out of date, especially with the jQuery UI/Draggables/draggable examples. If anyone sees any obvious errors, feel free to fix them. Also, if we're going to make this a standard way for people to document their plugins, it might make sense to wipe out the old plugins page at http://docs.jquery.com/Plugins , unfreeze it, and use it as an index to the individual plugin documentation pages. --Karl Karl Swedberg www.englishrules.com www.learningjquery.com On Feb 27, 2009, at 9:34 AM, John Resig wrote: Actually, we wrote up how to write API documentation a while back: http://docs.jquery.com/How_to_write_API_documentation You can feel welcome to document your plugins on the jQuery wiki (and in doing so, your docs will be able to be extracted to api.jquery.com, visualjquery, and other resources). --John On Fri, Feb 27, 2009 at 6:17 AM, Nicolas R ruda...@googlemail.com wrote: I know that this may not be the best place to ask this, but since it was mentioned quite a few times, I'll ask anyway. At the moment, are there any guidelines for writing documentation for plugins, or at least some indication on how jquery plugins should be documented? Or is the pattern of jquery ui docs the only thing to go with? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
I'll admit that I wasn't aware this page existed. As for jQuery UI documentation, it's had a bit of an overhaul over the last couple weeks. It's now similar, but significantly different (read: incompatible) with the jQuery docs standard. This is necessary for a number of reasons that I won't go into on this thread. Anyway, it's being finalized over the next couple of days and will be part of the 1.7 final release, and will be fully documented, as jQuery's is. - Richard On Fri, Feb 27, 2009 at 11:31 AM, Karl Swedberg k...@englishrules.comwrote: Heads up: I just updated that page because it was a little out of date, especially with the jQuery UI/Draggables/draggable examples. If anyone sees any obvious errors, feel free to fix them. Also, if we're going to make this a standard way for people to document their plugins, it might make sense to wipe out the old plugins page at http://docs.jquery.com/Plugins , unfreeze it, and use it as an index to the individual plugin documentation pages. --Karl Karl Swedberg www.englishrules.com www.learningjquery.com On Feb 27, 2009, at 9:34 AM, John Resig wrote: Actually, we wrote up how to write API documentation a while back: http://docs.jquery.com/How_to_write_API_documentation You can feel welcome to document your plugins on the jQuery wiki (and in doing so, your docs will be able to be extracted to api.jquery.com, visualjquery, and other resources). --John On Fri, Feb 27, 2009 at 6:17 AM, Nicolas R ruda...@googlemail.com wrote: I know that this may not be the best place to ask this, but since it was mentioned quite a few times, I'll ask anyway. At the moment, are there any guidelines for writing documentation for plugins, or at least some indication on how jquery plugins should be documented? Or is the pattern of jquery ui docs the only thing to go with? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
@Trey,
You created a plugin to deal with the exact problems we have been
talking about :).
Have you developed a JS centered application, something that could
be considered a 'Thin-Server-Architecture' app?
When you build the entire HTML structure client side, a lack of a JS
template (View) is brutal.
If you only have raw services to work from, something that can wrap
and provide context to the data is essential.
Although widget.js comes close to a 'controller' anyway, wouldn't it
be great if you can make plugins like:
$.plugin('todo',{
init : function(element, options) {
//initialization code on the element
//uses something in 'data' as 'this' for state, instead of
this=element
this.created = true;
}
a.destroy click : function(element, event){
//uses event delegation to call without actually having to setup
delegation
this.destroyed = true;
},
destroyed : function(){ return this.destroyed } // a normal function
on the plugin
})
Widget.js could just see which functions look for events and setup
delegation on the element for you.
Now, what if you can create your plugin like:
var instances = $('.someClass').todo(options)
and it would return the 'instances' of the plugin you were operating
on so you could do something like:
instances[0].destroyed();
MVC isn't over-engineering in a 'large' project because it fits
perfects with what you always have to do.
-respond to events
-connect to/manipulate services
-wrap data from those services
-Build/manipulate HTML/DOM
Logically separating these concerns is extremely helpful. Doing it in
an organized and repeatable fashion is event more important.
@nicolas - I was never implying any of this should be part of the
core. It should not be. I was simply proposing that a new 'branch'
of jQuery is started with a focus on tools and structure needed for
large projects.
On Feb 25, 6:11 pm, tres treshug...@gmail.com wrote:
I think 'MVC as it states - Model, View, Controller - in JavaScript
terms, is over-engineering what doesn't need to be over-engineered.
jQuery in it's simplicity can evolve with a very complex application
quite nicely.
That being said, I have authored myself a plugin called jFrame in
order to help with code convention, organization as well as automated
loading. Works nicely for me.
-Trey
On Feb 25, 8:26 am, John Resig jere...@gmail.com wrote:
Ok, so boiling down a list:
Needs code:
- Widget utility (I'm working on this)
- Debugging utility
- Static plugin analyzer
Need a tutorial to cover the concepts of (I'm working on this):
- Encapsulation
- Extensibility
- Modularity
Needs (defined/documented) conventions:
- File names
- Method names
- Method structures
- Testing
- Documentation
- Packaging
Once the above conventions are finalized, that static plugin analyzer
can be written.
Once the widget code is done, the tutorial needs to be updated.
---
So, with that drawn in the sand, Justin, would you be interested in
working on the debugging plugin, the static analyzer, defining
conventions, all of the above?
Any/all of those would be a huge help and I'd imagine that if the work
is solid they should all become official jQuery projects/conventions.
Now I'm not discounting any additional code or patterns but we need to
start with what we have and make sure that we're working with the best
possible resources. If we define the above conventions and code we may
find that there is less of a need for a new project than we originally
thought - and we get the benefit of having excellently defined and
documented resources and conventions for people to use - so everyone
wins.
--John
On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer justinbme...@gmail.com
wrote:
- package and minimize multiple files (YUI Compressor)
- Could be solved much better as it is not integrated into the
'framework'. You have to 'double' include everything (once in your
page, another in your build script). You have to set your html to
switch from loading separate files to loading the combined in
production.
- documentation (jQuery Documentation Wiki - already allows devs to
have inline demos and can be extracted to external sources)
Unless I am misunderstanding something, does this allow me to document
my application, or is this just for jQuery? I am talking about
something similar to JSDoc.
- testing (QUnit)
Does it handles synthetic events? Can it run server-side to ensure
sanity before checkin? Can you do point and click testing like
selenium?
Where do I put the files?
What should I name the files?
I'm not completely convinced that this is a huge problem - but at
worst this could be solved through convention and documentation.
How/where should I respond to events?
How should I deal with state?
How can I maximize the chances of re-usability?
All
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Hey John, sorry to chime in late here, just wanted to get my thoughts out as well: On Tue, Feb 24, 2009 at 10:26 PM, John Resig jere...@gmail.com wrote: Ok, so boiling down a list: Needs code: - Widget utility (I'm working on this) We should make sure the new core widget factory can be used as true replacement for the jQuery UI widget factory. If it can survive this test, it's probably good for other audiences as well. Also, I'd really love to have this become part of core, rather than as a separate utility, partially for my own selfish reasons, heh. We could strip out a significant code block of both jQuery UI's and jQuery Sky's core (Sky is the new suite featuring the magnifier). - Debugging utility This could be external, but I could also imagine having a prebuild debug version of jQuery which could be used in development and later on replaced by the production version. - Static plugin analyzer Need a tutorial to cover the concepts of (I'm working on this): - Encapsulation - Extensibility - Modularity Needs (defined/documented) conventions: - File names - Method names - Method structures - Testing - Documentation - Packaging Once the above conventions are finalized, that static plugin analyzer can be written. Once the widget code is done, the tutorial needs to be updated. --- So, with that drawn in the sand, Justin, would you be interested in working on the debugging plugin, the static analyzer, defining conventions, all of the above? Any/all of those would be a huge help and I'd imagine that if the work is solid they should all become official jQuery projects/conventions. Now I'm not discounting any additional code or patterns but we need to start with what we have and make sure that we're working with the best possible resources. If we define the above conventions and code we may find that there is less of a need for a new project than we originally thought - and we get the benefit of having excellently defined and documented resources and conventions for people to use - so everyone wins. --John On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer justinbme...@gmail.com wrote: - package and minimize multiple files (YUI Compressor) - Could be solved much better as it is not integrated into the 'framework'. You have to 'double' include everything (once in your page, another in your build script). You have to set your html to switch from loading separate files to loading the combined in production. - documentation (jQuery Documentation Wiki - already allows devs to have inline demos and can be extracted to external sources) Unless I am misunderstanding something, does this allow me to document my application, or is this just for jQuery? I am talking about something similar to JSDoc. - testing (QUnit) Does it handles synthetic events? Can it run server-side to ensure sanity before checkin? Can you do point and click testing like selenium? Where do I put the files? What should I name the files? I'm not completely convinced that this is a huge problem - but at worst this could be solved through convention and documentation. How/where should I respond to events? How should I deal with state? How can I maximize the chances of re-usability? All three of these are handled either through better documentation or with the widget/jQuery.plugin code that I showed earlier (it especially helps to deal with state and reusability, while responding to events would be more of a documentation issue). Yes, these conventions are exactly what is needed. Documentation can definitely do that, but so far I've not seen it for jQuery. Where should I be connecting to the service? That's probably outside the scope of anything that we would do, since it would probably define what needs to happen on the server-side. I mean, where should ajax calls happen in the client? In JMVC they are in the Model, akin to ORM. How can I wrap the service data? (For example, maybe the todo has passed it's completion date and you want to ask it .isPastDue(). This seems like another case of encapsulation or dealing with state (imo). How can I create HTML in a readable manner? At best, something that's done through convention. Yes, but where should that html go, etc. Yes, convention is needed. I guess that is the central point we've arrived at. -- Paul Bakaus UI Architect -- http://paulbakaus.com http://www.linkedin.com/in/paulbakaus --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Some great replies by Matt Kruse.
I'd like to propose, in addition:
13. In all but trivial circumstances, events and callbacks should
always be implemented with named functions. Invoking in-situ
anonymous functions and callbacks, as convenient as these may appear,
are eventually going to give somebody, somewhere, fits. We forget
this when we create trivial demos and code-examples.
-- Incidentally, I couldn't find any documentation, official or
otherwise, on callbacks (in general) and callback-seeding within
plugins (specifically) when I looked long-and-hard for this sometime
last week.
14. Extensibility means hooking critical junctures. However end-
user usability means hooking predictable junctures. To minimize
this dichotomy, first follow Matt's Rule #4 (All logic should be
broken up into the smallest logical chunk possible) so critical
junctures and predictable junctures are likely proximate. Next
consider hooking inherently predictable locations, for example the
very beginning of event code (i.e. pre-process native events) and the
very end of methods invoked by those events (i.e. post-process the
calls that emanate from events).
The main benefit of proscribing systematic extensibility at
predictable junctures is they are, by definition, easy to identify,
document, and conceptually convey.
THEREFORE, if there is merit to 13. and 14., in non-trivial plugins,
don't just blindly seed hot-spots with a callback opportunity.
Provide consistently-named function extensions, and seed for callbacks
at the very top of native events, and at the end of named-function
extensions.
**---** Steve
On Feb 24, 5:57 pm, Matt Kruse m...@thekrusefamily.com wrote:
On Feb 24, 3:57 pm, John Resig jere...@gmail.com wrote:
Does anyone have
any examples of plugins that they wished to extend in a particular
manner? (I needed the validation plugins X method to do Y - examples
like that.)
Many!
I've had to re-write BlockUI, Autocomplete, accordian, bgiframe,
context menu, etc. Others I have abandoned completely because they
were overly restrictive. I don't recall the reason in each case.
I've arrived at some guidelines I think should be followed when
writing plugins:
1. No method should be private. Not every method needs to be part of
the API, but don't hide any logic from being customized by a
developer. Just because you can't imagine a case where someone would
need to change the internal logic doesn't mean it won't happen.
2. All static values (strings, class names, numbers, defaults, etc)
should be stored as plugin properties that can be changed
3. Users should be able to over-ride defaults at the plugin level
(true for all instances) or per-instance
4. All logic should be broken up into the smallest logical chunks
possible. Each method should have a very specific task, which can be
over-ridden if needed
5. No assumptions should be made about the user's environment. For
example, don't blindly append newly created DOM elements to the body.
Allow the user to over-ride this default behavior if they wish. Don't
assume you know how to calculate a container's size using the built-in
jquery methods - separate that logic out to a function so I can
customize it if needed. In general, AVOID ASSUMPTIONS.
6. Any time HTML is created inside the plugin, generate it inside a
function that can be over-ridden if the user wants to generate
something slightly different
7. If your plugin has dependencies, do a quick check up-front to make
sure they are there, otherwise alert the developer
8. Any time you have static quoted text (or id's or class names, or
element names, etc), you better have a really good reason for assuming
that the user would never want to change it. And if you have a reason,
it's probably not good enough.
9. Provide many options, but also provide a logical default
implementation. Let the user do as little as possible to begin using
the plugin in a reasonable way, then show them just how much power
they have to customize it.
10. Pass in an {options} parameter instead of a hard-coded list of
options
11. Provide useful examples
12. Use a good code structure like ;(function($){ })(jQuery) and other
common recommendations
That's a short brain-storm at least. Key concept when writing a
general-use plugin - Avoid Assumptions! :)
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Feb 25, 11:36 am, Daniel Friesen nadir.seen.f...@gmail.com wrote: I also thought about the idea of a jquery-debug.js at one point. My thought was adding a number of logging statements for various warnings (selector found 0 nodes but you try to style or do stuff to it; common issue for not understanding why nothing has been styled sometimes) which would hook into a variety of debuggers including FireBug. I've posted something very much like this in the past: http://groups.google.com/group/jquery-en/browse_thread/thread/5e3b22a592d27247?fwc=1 My proof-of-concept tried to catch things like selectors that return no matches and passing complex selectors to .is (which often tripped up many developers in the past). Putting debug code into the core itself for a debug version and then filtering it out for the release version of jQuery would be the ideal solution, IMO. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
I think 'MVC as it states - Model, View, Controller - in JavaScript terms, is over-engineering what doesn't need to be over-engineered. jQuery in it's simplicity can evolve with a very complex application quite nicely. That being said, I have authored myself a plugin called jFrame in order to help with code convention, organization as well as automated loading. Works nicely for me. -Trey On Feb 25, 8:26 am, John Resig jere...@gmail.com wrote: Ok, so boiling down a list: Needs code: - Widget utility (I'm working on this) - Debugging utility - Static plugin analyzer Need a tutorial to cover the concepts of (I'm working on this): - Encapsulation - Extensibility - Modularity Needs (defined/documented) conventions: - File names - Method names - Method structures - Testing - Documentation - Packaging Once the above conventions are finalized, that static plugin analyzer can be written. Once the widget code is done, the tutorial needs to be updated. --- So, with that drawn in the sand, Justin, would you be interested in working on the debugging plugin, the static analyzer, defining conventions, all of the above? Any/all of those would be a huge help and I'd imagine that if the work is solid they should all become official jQuery projects/conventions. Now I'm not discounting any additional code or patterns but we need to start with what we have and make sure that we're working with the best possible resources. If we define the above conventions and code we may find that there is less of a need for a new project than we originally thought - and we get the benefit of having excellently defined and documented resources and conventions for people to use - so everyone wins. --John On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer justinbme...@gmail.com wrote: - package and minimize multiple files (YUI Compressor) - Could be solved much better as it is not integrated into the 'framework'. You have to 'double' include everything (once in your page, another in your build script). You have to set your html to switch from loading separate files to loading the combined in production. - documentation (jQuery Documentation Wiki - already allows devs to have inline demos and can be extracted to external sources) Unless I am misunderstanding something, does this allow me to document my application, or is this just for jQuery? I am talking about something similar to JSDoc. - testing (QUnit) Does it handles synthetic events? Can it run server-side to ensure sanity before checkin? Can you do point and click testing like selenium? Where do I put the files? What should I name the files? I'm not completely convinced that this is a huge problem - but at worst this could be solved through convention and documentation. How/where should I respond to events? How should I deal with state? How can I maximize the chances of re-usability? All three of these are handled either through better documentation or with the widget/jQuery.plugin code that I showed earlier (it especially helps to deal with state and reusability, while responding to events would be more of a documentation issue). Yes, these conventions are exactly what is needed. Documentation can definitely do that, but so far I've not seen it for jQuery. Where should I be connecting to the service? That's probably outside the scope of anything that we would do, since it would probably define what needs to happen on the server-side. I mean, where should ajax calls happen in the client? In JMVC they are in the Model, akin to ORM. How can I wrap the service data? (For example, maybe the todo has passed it's completion date and you want to ask it .isPastDue(). This seems like another case of encapsulation or dealing with state (imo). How can I create HTML in a readable manner? At best, something that's done through convention. Yes, but where should that html go, etc. Yes, convention is needed. I guess that is the central point we've arrived at. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
I'd just like to speak up in favour of this proposal. Working on a JavaScript/AIR project recently, I rolled my own JavaScript MVC library on top of jQuery, largely because I didn't know that JavaScriptMVC existed at the time I started, and I wanted to keep jQuery at the heart of the project (rather than move to Dojo, Mootools etc.). Having a 'jQuery Enterprise' project would be awesome and I'd certainly be willing to contribute code and ideas where my own development has covered areas not covered by JavaScriptMVC (though, from what I can see, JMVC does everything my library does and more). +1 from me, for whatever that counts for. - Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Sounds fantastic to me. On Feb 24, 6:38 am, Justin Meyer justinbme...@gmail.com wrote: jQuery community, Amazing work. I can't believe how fast jQuery has developed into the best bottom-up JS library. 1.4 looks great. But as jQuery expands to include things like lazy loading, it might be time for a sister project that provides important, but less commonly needed functionality in a standard and organized way. Essentially, I would like to start a new branch of jQuery, akin to jQuery UI, that provides a standard set of tools and 'classes' that enable the development of more complex applications (by no means, does jQuery Enterprise has to be the name, just the first thing I came up with). The project COULD include: - A 'standard' way of organizing files - Compression - Documentation - Testing - Code generators - Scaffolding for easily connecting to services - Command line plug-in installation and dependency management. - A powerful class system (based off Resig's class) Obviously, these are all features of my project - JavaScriptMVC. But, I am more than willing to sacrifice the name/leadership/everything for the ability to explore these ideas with the jQuery community. Furthermore, it seems all JavaScriptMVC users use it with jQuery anyway! If you are questioning if these features are necessary, they are! I've worked on some very large projects with hundreds of custom JS files and multiple developers. At some point, developers need a repeatable way of building their applications and separating concerns. JavaScriptMVC provides that to a few lucky souls. I'd like to help jQuery provide that to everyone. It will also will help keep jQuery's core small and applicable to as many projects as possible. Here's my rough plan: 1. Get your blessing and support. Blessing being SVN access to a new branch. Support being interest and involvement from a few contributors. 2. Engage top jQuery contributors and users on application development best practices. I've slowly been interviewing some JS luminaries:http://javascriptmvc.com/blog/?cat=36. 3. Build it. I have already started to convert JavaScriptMVC to depend on jQuery (it's in JMVC's trunk). With support, this will take less than a month. That being said, I'm going to skip to step #2: jQuery community, What would you like to see in the jQuery Framework? How do you organize your applications? What sucks about testing, compression, documentation, etc? I can't wait to work for you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
1) If you have to work with certain design patterns, either out of personal preference or because that's how your organisation works, jQuery will allow you to do that. For example, I rolled my own MVC framework on top of jQuery with no problems. However, it would have been beneficial to have had a known, well-supported MVC framework to use off-the-shelf. For someone coming into JS development from other areas where these frameworks are just part of the standard toolset, jQuery can appear a bit too minimalist. I'm not convinced by this argument. Because it's what we're familiar with does not imply that it's the best solution - or even a good solution - neither does everyone else is doing it. I've been doing JavaScript development for a while now and I'm becoming less-and-less convinced that the traditional MVC/Classical inheritance styles of development (carried over from Java or Ruby, for example) do not translate to JavaScript/DOM well and can, in fact, be improved upon in some dramatic ways. I will fully concede that there might a portion of the jQuery development audience that might be interested in this structure since it's what they're most familiar with, but that doesn't mean that they can't be re-educated. jQuery itself has a very bizarre structure, if you're coming to it from a normal classical-style language. There are no classes, seemingly no inheritance, and the syntax is just strange - but that hasn't stopped it from having some very-large uptake, even amongst highly-skilled developers. So while I think the classical-style inheritance may be of benefit to some other frameworks (since that's how they're designed) I'm not convinced that it would be of benefit to jQuery or jQuery users. 2) There's a lot of stuff being done in support for RESTful Ajax (the RESTful JSON stuff is v. cool imo). Again, jQuery has no explicit support beyond allowing you to do Ajax calls. This is great, but it would save on development time if there were standard libraries that could support common REST patterns. Can you expand on this? We already do a pretty good job of this. I think there's a bug filed to try and improve upon our content-type checking and data determination. It sounds like you're using Ruby/Rails so you can feel pretty safe in knowing that we're going to have the best solution here (especially since one of our team members, Yehuda Katz, is a Rails core contributor). 3) I know jQuery UI supports widgets, but it's a long way off being a comprehensive UI/widget framework. Absolutely - and it's a definite work in progress. The UI team is getting larger, becoming more efficient, well-organized, all around a central plan for a strong UI/widget framework. I have good confidence that they will continue to do well. 4) No real support for data handling. That means ORM for stuff like Adobe AIR SQL databases (or other SQL databases), no particular support for ActiveResource-style use of remote data as a data source (see #2). Basically, jQuery is awesome for handling the DOM, but what if your data lives somewhere else, and most of your app revolves around manipulating that data? I disagree on the client-side SQL database/ActiveResource style stuff. The client-side SQL stuff is used so infrequently (on specialized WebKit platforms, only) as to relegate it only to plugin status, at best. As far as the ActiveResource stuff goes - much of that dictates how your server-side application should be structured and how it should return data. jQuery has never been about that (dictating what your page should look like or what server-side language you should use) and it's flourished because of that. That being said, I will agree with your point about mapping remote data and manipulating it. I know of a number of techniques that developers have used (transmitting metadata inline, in HTML, sending JSON blocks, etc.) and I think this could be documented much better. I would like to explore documenting it first, before looking to implementing more code. However, none of these are really a good fit for jQuery core. Adding them to jQuery core would increase code size, increase complexity, add new paradigms and generally confuse everyone. The reason I love jQuery and use it ahead of Dojo every time is because I can work out how I'm going to use it in my head, only occasionally referring to the docs. But I like Justin's idea of creating a layer on top of jQuery that would provide a lot of the 'enterprise' stuff. I've been reading Martin Fowler's Patterns of Enterprise Application Architecture recently (it was a Christmas present!) and I'm struck by just how useful those patterns are. It would be great to have some pattern implementations that sit on top of jQuery. The project I'm working on at the moment (with the self-created MVC framework) is an Adobe AIR app for internal use within a business as part of an Enterprise Resource Planning system. It's a long way away from
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
@John regarding his specific questions: Part of the issue isn't that there isn't any way to solve jQuery's shortcomings, it's that there are no really good ways to solve them. For instance, I know I can use closures to get around scoping issues in jQuery, but most enterprises are stuck on IE6, and a ton of closures floating in memory that have a bunch of variables stored in each copy isn't ideal. My understanding of the JS memory model is no doubt flawed, but even MS themselves try to steer people away from closures because of how poorly they handle them. On the other hand, property lookups in Internet Explorer are just abysmal - and you'd be doing a ton of those if you were using nothing but OO techniques. You're damned if you do and damned if you don't in the land of Internet Explorer! Also, with extensibility, there are ways to overload methods. Sure I can rename an existing method to _something, and create a new one that references the old one, but that is NOT an ideal way to go about extending an object, especially in a multi-developer scenario with different scripts accessing the same objects. I agree with this. This was a big step that my proposed jQuery.plugin/widget code helped to solve: http://dev.jquery.com/~john/plugins/widget/widget.js It's very rough right now but it allows you to override existing methods and alter their inputs in ways that are quite elegant. I'm going to be working with the UI team some more (since they've been dealing with the issue of building complex, extensible, jQuery plugins for while now) to try and solve some of their problems. And the method should take advantage of Javascripts benefits. I don't think every plugin developer understands that shoving object properties and methods onto instances is way less efficient than using the prototype. Nor do I think they should have to understand. The system (like the current plugin system) should handle that for them. Agreed - also something the widget code helps with. See, I have no problem dropping 40 lines of code into core if it means that it'll help in the construction of jQuery plugins - making them dramatically simpler to develop complex ones - and extend them - without sacrificing simplicity. --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
disclaimer: I've just built a pretty complex app (drag/drop, inline editing, history support, popup windows) with jmvc jquery I personally feel that jquery as it stands at the moment is superb for doing all the nitty gritty details of dhtml sites, but as the scope of the functionality in the site your are building grows towards that of a desktop app, it still becomes too easy to get sucked into the Big Ball Of Mud (that may say something about my discipline though). There may be guidance already out there for jquery, but it would be useful to have a project that offers a cohesive bunch of tools that are considered the best starting point for that type of site development. I think there are already some good plugins that could be referenced, like the history plugin that I've recently used. I agree with you very strongly - and gives me all the more reason to keep working on the writeup that I've been working on (that I linked to, before). I like the suggestion of the History plugin, I think that's a great example of a plugin that helps to simplify complex applications. --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Tue, Feb 24, 2009 at 9:36 PM, John Resig jere...@gmail.com wrote: 3) I know jQuery UI supports widgets, but it's a long way off being a comprehensive UI/widget framework. Absolutely - and it's a definite work in progress. The UI team is getting larger, becoming more efficient, well-organized, all around a central plan for a strong UI/widget framework. I have good confidence that they will continue to do well. This is my biggest contention with the widget framework at the moment and I am only left with the option of copy/pasting snippets due to lack of extensibility features. In fact, if I may be bold enough to say it, I think the widget framework wasn't well planned and I have a feeling that due to backward compatibility issues it will be a while before it can be cleaned up. A design overhaul for widgets is my biggest wish for the upcoming release. Not only will it make it easy to extend plugins, but it will reduce the overall footprint of plugins which sometimes end up cramming in quite a lot. Is this already on the radar and when should we set our expectations for an the widget architecture? -- Aleem --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
This is my biggest contention with the widget framework at the moment and I am only left with the option of copy/pasting snippets due to lack of extensibility features. In fact, if I may be bold enough to say it, I think the widget framework wasn't well planned and I have a feeling that due to backward compatibility issues it will be a while before it can be cleaned up. A design overhaul for widgets is my biggest wish for the upcoming release. Not only will it make it easy to extend plugins, but it will reduce the overall footprint of plugins which sometimes end up cramming in quite a lot. Is this already on the radar and when should we set our expectations for an the widget architecture? As I mentioned in the previous email in this thread, this is something that I've started to work with the jQuery UI team on. The issue of extensible plugins is very real - and it's one that may only be solved with code. I pointed to a mock-up of jQuery.plugin which could be used for improving the extensibility of any plugin that uses it (including UI) and I'll certainly continue to work on it if, for nothing else, to make sure that UI has a good extensibility solution that doesn't compromise the current API. --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Point well made and understood. Perhaps what we're looking for here can be achieved without the wholesale adoption of an MVC framework. Perhaps the UI/widget framework can do a lot of the visual controller stuff anyway, allowing people to create abstract 'objects' (without full OOP) for controlling visual elements. Obviously DOM manipulation provides us with a view component, and people are free to create templating systems or whatever else they like on top of that. The real area where progress can be made, imo, is in data handling. That means, for example, being able to define a 'model' with certain fields, tying those fields to DOM elements, and automatically validating the input in those elements against the rules within the model, then calling a simple function to persist the model data to the server, or load a new model and display that instead, etc. I think that this would be sufficiently useful that a 'jQuery Data' plugin that aims to make this kind of task as easy as DOM manipulation is already would be worth pursuing. Full MVC would be one extension of this approach, but not essential to it. If I had to guess and put percentages on the jQuery user base I would say that they break down something like this: - 95% of jQuery user's needs are perfectly met by current jQuery code/plugins (19 out of 20 users) - 4% of jQuery user's create complex interactions - would possibly benefit from a widget architecture - 1% of jQuery users have a need for both complex widgets and a means of tying them to an existing data model I'd like to propose taking two steps (mostly on my end): 1) Writing up a solid overview of how to make the best use of current jQuery technology (for extensibility, encapsulation, etc.) 2) Work on refining the widget code with the ultimate goal of having it be ready for jQuery UI 1.8 - but releasing it separately so that people can start to play around with it and see if it'll benefit their plugins/writing style. Once we tackle those two points (#1 will help those in the 95% to realize how to best use their current tools, #2 will help the demands of the other 4%) we can safely start to look at some sort of data abstraction code. My biggest concern with a data abstraction is that it usually requires some sort of specific set up on the server to benefit from it. Would everyone be able to benefit from this addition regardless of server construction? (PHP users? .NET users? ColdFusion users? Rails users? etc.) So while I will continue in this direction for now, I'd still love more feedback: Cases of where complex applications worked well in jQuery, examples where they did not. Knowing the exact set of use cases that might exist would help us to quantify the amount of work that we should put in and where. --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Quick comments: On OOP and not being convinced. What other approaches are you hinting at? OOP being well understood is a valid argument only because inheritance and OO does provide reuse. If you have something that does work in many cases, you are allowed to factor in popularity and understandability. For example, the widget plugin that I pointed to. I keep talking about it so I'll just link to it again: http://dev.jquery.com/~john/plugins/widget/widget.js This is a case where many of the problems (or complexities) that exist in advanced jQuery plugins are already taken care of: extensibility, encapsulation, and reusability. I consider this to be a good example of introducing a selective piece of jQuery functionality that'll help developers but without doing a wholesale import of OOP techniques. Why do you think this would contribute to jQuery bloat anymore than jQuery.UI does? Because jQuery UI isn't, or doesn't, have the ability to become a dependency for nearly every plugin created. As I mentioned before, most developers look at the tool of Classes as the be-all and end-all of development patterns. Introducing that in a sanctioned manner will instantly make it a dependency of countless plugins, at which point we would be required to include it in core, out of necessity. It seems like it would be a much better option to produce a plugin/widget construction utility that solves all the problems that advanced jQuery developers encounter, in a style that meshes well with the jQuery philosophy, rather than a wholesale import of OOP concepts. --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
- package and minimize multiple files (YUI Compressor) - Could be solved much better as it is not integrated into the 'framework'. You have to 'double' include everything (once in your page, another in your build script). You have to set your html to switch from loading separate files to loading the combined in production. - documentation (jQuery Documentation Wiki - already allows devs to have inline demos and can be extracted to external sources) Unless I am misunderstanding something, does this allow me to document my application, or is this just for jQuery? I am talking about something similar to JSDoc. - testing (QUnit) Does it handles synthetic events? Can it run server-side to ensure sanity before checkin? Can you do point and click testing like selenium? Where do I put the files? What should I name the files? I'm not completely convinced that this is a huge problem - but at worst this could be solved through convention and documentation. How/where should I respond to events? How should I deal with state? How can I maximize the chances of re-usability? All three of these are handled either through better documentation or with the widget/jQuery.plugin code that I showed earlier (it especially helps to deal with state and reusability, while responding to events would be more of a documentation issue). Yes, these conventions are exactly what is needed. Documentation can definitely do that, but so far I've not seen it for jQuery. Where should I be connecting to the service? That's probably outside the scope of anything that we would do, since it would probably define what needs to happen on the server-side. I mean, where should ajax calls happen in the client? In JMVC they are in the Model, akin to ORM. How can I wrap the service data? (For example, maybe the todo has passed it's completion date and you want to ask it .isPastDue(). This seems like another case of encapsulation or dealing with state (imo). How can I create HTML in a readable manner? At best, something that's done through convention. Yes, but where should that html go, etc. Yes, convention is needed. I guess that is the central point we've arrived at. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
I'm a little scared of jumping into this, but I feel I'd like to make a few quick points, as I've run up against these issues myself. 1. I've scheduled time for myself and my team to re-build the plugins site next week. The goal initially is simply to re-create the existing functionality in a more maintainable way, but I'd love to see features added like the following: - Developer uploads his JS, and a gzipped, compressed and/or minified version is automatically generated - Developer specifies in a structured way dependent plugins. This opens up the potential for a plugin and their dependencies to be automatically generated and downloaded. I've love to get all the feedback we can, we have a wiki to help collect and organize things: http://jqueryplugins.pbwiki.com/FrontPage 2. I've been bumping up against the data issue for a few months now on various projects. I admittedly have not spent time trying to do it *right*, due to project constraints. I've built a jQuery plugin to manage the data layer in my application, choosing to do it as a plugin for the reasons explained above. If I had to do this task again right now, I'd choose to do it the same way. John's widget code presents a very interesting possibility though. If the jQuery team adopted a few choice plugins, like a debugging plugin, a data layer plugin, and by putting the widget code into the core, allowed these plugins to be extended, I think a very powerful foundation would be provided to developers. jQuery is about providing choice, and with the size of the user base, all of the choices that are made are magnified 100-fold. So, they cannot be taken lightly. 3. Lastly, I'm involved with collecting and writing down the latest information and practices of building jQuery plugins, and using jQuery in large projects. The group of developers who use jQuery in large projects is small, but important. Large projects are growing in number, and a good foundation is needed, we just need to be careful. My 2 cents. Thanks! Mike Hostetler http://amountaintop.com On Tue, Feb 24, 2009 at 12:51, Justin Meyer justinbme...@gmail.com wrote: JS is Object Oriented. So are we really just talking about classical inheritance (and even more specific, _super) ? I see how widget.js creates a plugin. But how does one expand on the plugin? I'm more than happy with widget.js if you can easily expand on the widget. For example, quickly added a delegated hoverenter that will show a tooltip, or change an existing function. I don't think super is necessary at all. I've only used it a few times, never needed it. But if you let go of _super, and you are able to easily expand the widget, how is that different than what you are considering OOP? On Feb 24, 1:22 pm, John Resig jere...@gmail.com wrote: Quick comments: On OOP and not being convinced. What other approaches are you hinting at? OOP being well understood is a valid argument only because inheritance and OO does provide reuse. If you have something that does work in many cases, you are allowed to factor in popularity and understandability. For example, the widget plugin that I pointed to. I keep talking about it so I'll just link to it again: http://dev.jquery.com/~john/plugins/widget/widget.jshttp://dev.jquery.com/%7Ejohn/plugins/widget/widget.js This is a case where many of the problems (or complexities) that exist in advanced jQuery plugins are already taken care of: extensibility, encapsulation, and reusability. I consider this to be a good example of introducing a selective piece of jQuery functionality that'll help developers but without doing a wholesale import of OOP techniques. Why do you think this would contribute to jQuery bloat anymore than jQuery.UI does? Because jQuery UI isn't, or doesn't, have the ability to become a dependency for nearly every plugin created. As I mentioned before, most developers look at the tool of Classes as the be-all and end-all of development patterns. Introducing that in a sanctioned manner will instantly make it a dependency of countless plugins, at which point we would be required to include it in core, out of necessity. It seems like it would be a much better option to produce a plugin/widget construction utility that solves all the problems that advanced jQuery developers encounter, in a style that meshes well with the jQuery philosophy, rather than a wholesale import of OOP concepts. --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Ok, so boiling down a list: Needs code: - Widget utility (I'm working on this) - Debugging utility - Static plugin analyzer Need a tutorial to cover the concepts of (I'm working on this): - Encapsulation - Extensibility - Modularity Needs (defined/documented) conventions: - File names - Method names - Method structures - Testing - Documentation - Packaging Once the above conventions are finalized, that static plugin analyzer can be written. Once the widget code is done, the tutorial needs to be updated. --- So, with that drawn in the sand, Justin, would you be interested in working on the debugging plugin, the static analyzer, defining conventions, all of the above? Any/all of those would be a huge help and I'd imagine that if the work is solid they should all become official jQuery projects/conventions. Now I'm not discounting any additional code or patterns but we need to start with what we have and make sure that we're working with the best possible resources. If we define the above conventions and code we may find that there is less of a need for a new project than we originally thought - and we get the benefit of having excellently defined and documented resources and conventions for people to use - so everyone wins. --John On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer justinbme...@gmail.com wrote: - package and minimize multiple files (YUI Compressor) - Could be solved much better as it is not integrated into the 'framework'. You have to 'double' include everything (once in your page, another in your build script). You have to set your html to switch from loading separate files to loading the combined in production. - documentation (jQuery Documentation Wiki - already allows devs to have inline demos and can be extracted to external sources) Unless I am misunderstanding something, does this allow me to document my application, or is this just for jQuery? I am talking about something similar to JSDoc. - testing (QUnit) Does it handles synthetic events? Can it run server-side to ensure sanity before checkin? Can you do point and click testing like selenium? Where do I put the files? What should I name the files? I'm not completely convinced that this is a huge problem - but at worst this could be solved through convention and documentation. How/where should I respond to events? How should I deal with state? How can I maximize the chances of re-usability? All three of these are handled either through better documentation or with the widget/jQuery.plugin code that I showed earlier (it especially helps to deal with state and reusability, while responding to events would be more of a documentation issue). Yes, these conventions are exactly what is needed. Documentation can definitely do that, but so far I've not seen it for jQuery. Where should I be connecting to the service? That's probably outside the scope of anything that we would do, since it would probably define what needs to happen on the server-side. I mean, where should ajax calls happen in the client? In JMVC they are in the Model, akin to ORM. How can I wrap the service data? (For example, maybe the todo has passed it's completion date and you want to ask it .isPastDue(). This seems like another case of encapsulation or dealing with state (imo). How can I create HTML in a readable manner? At best, something that's done through convention. Yes, but where should that html go, etc. Yes, convention is needed. I guess that is the central point we've arrived at. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
I'd definitely be interested in working with someone like Justin to define/document the conventions listed. Keeping the guess work out of thoses area would benefit the plugin developer community for sure and help lower the barrier of entry for new developers. Thatcher On Tue, Feb 24, 2009 at 4:26 PM, John Resig jere...@gmail.com wrote: Ok, so boiling down a list: Needs code: - Widget utility (I'm working on this) - Debugging utility - Static plugin analyzer Need a tutorial to cover the concepts of (I'm working on this): - Encapsulation - Extensibility - Modularity Needs (defined/documented) conventions: - File names - Method names - Method structures - Testing - Documentation - Packaging Once the above conventions are finalized, that static plugin analyzer can be written. Once the widget code is done, the tutorial needs to be updated. --- So, with that drawn in the sand, Justin, would you be interested in working on the debugging plugin, the static analyzer, defining conventions, all of the above? Any/all of those would be a huge help and I'd imagine that if the work is solid they should all become official jQuery projects/conventions. Now I'm not discounting any additional code or patterns but we need to start with what we have and make sure that we're working with the best possible resources. If we define the above conventions and code we may find that there is less of a need for a new project than we originally thought - and we get the benefit of having excellently defined and documented resources and conventions for people to use - so everyone wins. --John On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer justinbme...@gmail.com wrote: - package and minimize multiple files (YUI Compressor) - Could be solved much better as it is not integrated into the 'framework'. You have to 'double' include everything (once in your page, another in your build script). You have to set your html to switch from loading separate files to loading the combined in production. - documentation (jQuery Documentation Wiki - already allows devs to have inline demos and can be extracted to external sources) Unless I am misunderstanding something, does this allow me to document my application, or is this just for jQuery? I am talking about something similar to JSDoc. - testing (QUnit) Does it handles synthetic events? Can it run server-side to ensure sanity before checkin? Can you do point and click testing like selenium? Where do I put the files? What should I name the files? I'm not completely convinced that this is a huge problem - but at worst this could be solved through convention and documentation. How/where should I respond to events? How should I deal with state? How can I maximize the chances of re-usability? All three of these are handled either through better documentation or with the widget/jQuery.plugin code that I showed earlier (it especially helps to deal with state and reusability, while responding to events would be more of a documentation issue). Yes, these conventions are exactly what is needed. Documentation can definitely do that, but so far I've not seen it for jQuery. Where should I be connecting to the service? That's probably outside the scope of anything that we would do, since it would probably define what needs to happen on the server-side. I mean, where should ajax calls happen in the client? In JMVC they are in the Model, akin to ORM. How can I wrap the service data? (For example, maybe the todo has passed it's completion date and you want to ask it .isPastDue(). This seems like another case of encapsulation or dealing with state (imo). How can I create HTML in a readable manner? At best, something that's done through convention. Yes, but where should that html go, etc. Yes, convention is needed. I guess that is the central point we've arrived at. -- Christopher Thatcher --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Mike, Justin, other's interested in helping with this area, Can we chat for 30 min this evening online and talk about how we coordinate? Thatcher On Tue, Feb 24, 2009 at 4:45 PM, Mike Hostetler mike.hostet...@gmail.comwrote: I can help write up the following, as I'm already writing some of this already: Needs (defined/documented) conventions: - File names - Method names - Method structures - Testing - Documentation - Packaging Mike Hostetler http://amountaintop.com On Tue, Feb 24, 2009 at 14:37, chris thatcher thatcher.christop...@gmail.com wrote: I'd definitely be interested in working with someone like Justin to define/document the conventions listed. Keeping the guess work out of thoses area would benefit the plugin developer community for sure and help lower the barrier of entry for new developers. Thatcher On Tue, Feb 24, 2009 at 4:26 PM, John Resig jere...@gmail.com wrote: Ok, so boiling down a list: Needs code: - Widget utility (I'm working on this) - Debugging utility - Static plugin analyzer Need a tutorial to cover the concepts of (I'm working on this): - Encapsulation - Extensibility - Modularity Needs (defined/documented) conventions: - File names - Method names - Method structures - Testing - Documentation - Packaging Once the above conventions are finalized, that static plugin analyzer can be written. Once the widget code is done, the tutorial needs to be updated. --- So, with that drawn in the sand, Justin, would you be interested in working on the debugging plugin, the static analyzer, defining conventions, all of the above? Any/all of those would be a huge help and I'd imagine that if the work is solid they should all become official jQuery projects/conventions. Now I'm not discounting any additional code or patterns but we need to start with what we have and make sure that we're working with the best possible resources. If we define the above conventions and code we may find that there is less of a need for a new project than we originally thought - and we get the benefit of having excellently defined and documented resources and conventions for people to use - so everyone wins. --John On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer justinbme...@gmail.com wrote: - package and minimize multiple files (YUI Compressor) - Could be solved much better as it is not integrated into the 'framework'. You have to 'double' include everything (once in your page, another in your build script). You have to set your html to switch from loading separate files to loading the combined in production. - documentation (jQuery Documentation Wiki - already allows devs to have inline demos and can be extracted to external sources) Unless I am misunderstanding something, does this allow me to document my application, or is this just for jQuery? I am talking about something similar to JSDoc. - testing (QUnit) Does it handles synthetic events? Can it run server-side to ensure sanity before checkin? Can you do point and click testing like selenium? Where do I put the files? What should I name the files? I'm not completely convinced that this is a huge problem - but at worst this could be solved through convention and documentation. How/where should I respond to events? How should I deal with state? How can I maximize the chances of re-usability? All three of these are handled either through better documentation or with the widget/jQuery.plugin code that I showed earlier (it especially helps to deal with state and reusability, while responding to events would be more of a documentation issue). Yes, these conventions are exactly what is needed. Documentation can definitely do that, but so far I've not seen it for jQuery. Where should I be connecting to the service? That's probably outside the scope of anything that we would do, since it would probably define what needs to happen on the server-side. I mean, where should ajax calls happen in the client? In JMVC they are in the Model, akin to ORM. How can I wrap the service data? (For example, maybe the todo has passed it's completion date and you want to ask it .isPastDue(). This seems like another case of encapsulation or dealing with state (imo). How can I create HTML in a readable manner? At best, something that's done through convention. Yes, but where should that html go, etc. Yes, convention is needed. I guess that is the central point we've arrived at. -- Christopher Thatcher -- Christopher Thatcher --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
JS is Object Oriented. So are we really just talking about classical
inheritance (and even more specific, _super) ?
Yeah, I'm talking about constructing classes and inheritance.
I see how widget.js creates a plugin. But how does one expand on the
plugin?
There's two ways (one implemented, one not yet).
- Not implemented yet is a way to take an existing plugin and derive
a new plugin from it (one that completely overrides some existing
methods)
- Right now there's an easy way to inject new functionality into
existing plugins.
For example right now you would be able to do the following (if you
wanted to make an element fade out when a drag stops):
jQuery.plugin(draggable, {
options: { isBeingDragged: false },
setup: function(){ /* Setup... */ },
methods: {
stopDrag: function(){
this.options.isBeingDragged = false;
}
}
});
jQuery.fn.stopDrag.fadeOut = function(){
this.fadeOut(2000);
};
A little bit contrived, but just an example (jQuery.plugin is pretty
rough at the moment - haven't had a chance to mess with it since last
fall, and only then it was for an hour or two).
The important thing here is being able to extend the existing plugin
methods - plugins for plugins.
I'm more than happy with widget.js if you can easily expand on the
widget. For example, quickly added a delegated hoverenter that will
show a tooltip, or change an existing function.
I agree that something like this should be very easy. Does anyone have
any examples of plugins that they wished to extend in a particular
manner? (I needed the validation plugins X method to do Y - examples
like that.)
I don't think super is necessary at all. I've only used it a few
times, never needed it. But if you let go of _super, and you are able
to easily expand the widget, how is that different than what you are
considering OOP?
I think we're probably conflating the terms here. I'm using the term
OOP to imply adding on a Java-Class-style solution to jQuery as a
magic wand to take care of any complexity problems when, in fact, a
much more fine-tuned approach might be more appropriate (dealing with
jQuery-specific concepts like option encapsulation and event
triggering and communication, for example).
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Don't want to sound like I'm pushing my own wishlist (though this is
up there on mine) but I consider browser history support to be a
critical for RIA and usability. AJAXy apps have hijacked native
browser navigation/bookmarking facilities.
Whether or not this belongs in the core, I am not sure. I say this
because even though I feel that this feature should be available to
all developers, I understand the core is additive and once moved into
the core, it will have to stay there. And again, it's not the DOM. At
the same time however, I feel that allowing developers to conveniently
update url fragement with a single function
(.state('view-thread-456')) call can change the RIA landscape by
allowing developers to preserve state. In turn this will return native
browser navigation controls back to the user.
-- Aleem
On Wed, Feb 25, 2009 at 2:26 AM, John Resig jere...@gmail.com wrote:
Ok, so boiling down a list:
Needs code:
- Widget utility (I'm working on this)
- Debugging utility
- Static plugin analyzer
Need a tutorial to cover the concepts of (I'm working on this):
- Encapsulation
- Extensibility
- Modularity
Needs (defined/documented) conventions:
- File names
- Method names
- Method structures
- Testing
- Documentation
- Packaging
Once the above conventions are finalized, that static plugin analyzer
can be written.
Once the widget code is done, the tutorial needs to be updated.
---
So, with that drawn in the sand, Justin, would you be interested in
working on the debugging plugin, the static analyzer, defining
conventions, all of the above?
Any/all of those would be a huge help and I'd imagine that if the work
is solid they should all become official jQuery projects/conventions.
Now I'm not discounting any additional code or patterns but we need to
start with what we have and make sure that we're working with the best
possible resources. If we define the above conventions and code we may
find that there is less of a need for a new project than we originally
thought - and we get the benefit of having excellently defined and
documented resources and conventions for people to use - so everyone
wins.
--John
On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer justinbme...@gmail.com wrote:
- package and minimize multiple files (YUI Compressor)
- Could be solved much better as it is not integrated into the
'framework'. You have to 'double' include everything (once in your
page, another in your build script). You have to set your html to
switch from loading separate files to loading the combined in
production.
- documentation (jQuery Documentation Wiki - already allows devs to
have inline demos and can be extracted to external sources)
Unless I am misunderstanding something, does this allow me to document
my application, or is this just for jQuery? I am talking about
something similar to JSDoc.
- testing (QUnit)
Does it handles synthetic events? Can it run server-side to ensure
sanity before checkin? Can you do point and click testing like
selenium?
Where do I put the files?
What should I name the files?
I'm not completely convinced that this is a huge problem - but at
worst this could be solved through convention and documentation.
How/where should I respond to events?
How should I deal with state?
How can I maximize the chances of re-usability?
All three of these are handled either through better documentation or
with the widget/jQuery.plugin code that I showed earlier (it
especially helps to deal with state and reusability, while responding
to events would be more of a documentation issue).
Yes, these conventions are exactly what is needed. Documentation can
definitely do that, but so far I've not seen it for jQuery.
Where should I be connecting to the service?
That's probably outside the scope of anything that we would do, since
it would probably define what needs to happen on the server-side.
I mean, where should ajax calls happen in the client? In JMVC they
are in the Model, akin to ORM.
How can I wrap the service data? (For example, maybe the todo has
passed it's completion date and you want to ask it .isPastDue().
This seems like another case of encapsulation or dealing with state (imo).
How can I create HTML in a readable manner?
At best, something that's done through convention.
Yes, but where should that html go, etc. Yes, convention is needed.
I guess that is the central point we've arrived at.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Feb 24, 2:15 pm, Mike Hostetler mike.hostet...@gmail.com wrote: If the jQuery team adopted a few choice plugins, like a debugging plugin, a data layer plugin, and by putting the widget code into the core, allowed these plugins to be extended, I think a very powerful foundation would be provided to developers. I've often said that plugins are vital to jQuery's success, but also it's weakest link. IMO, there must be: 1. A roadmap for plugins. Someone needs to sit down and design a strategy for breaking up functionality into reusable parts, and make a list of what plugins are needed 2. A specific list of requirements, documentation standards, and development style needs to be decided on 3. A core list of official plugins needs to be created and maintained by developers, and integrated into the test suites. The concept of a jQuery Enterprise suite could just be a collection of official plugins that do most of what a developer may need in a single package. Similar in concept to My Eclipse which offers a package of Eclipse plugins based on your development environment and goals. 3. Lastly, I'm involved with collecting and writing down the latest information and practices of building jQuery plugins Is this a public effort? Because I have struggled so much with the quality of existing plugins and their lack of extensibility (IMO, of course), I've been trying to advocate a plugin structure in projects that I've worked on. If you're looking for any new thoughts on the issue, I'd like to participate. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
Somewhat off-topic, but: On the other hand, property lookups in Internet Explorer are just abysmal - and you'd be doing a ton of those if you were using nothing but OO techniques. You're damned if you do and damned if you don't in the land of Internet Explorer! John, do you have any documentation or know of any online regarding this in more detail? Also, is this for all lookups (dot notation, and [] notation), and I'm guessing the speed hit is on execution, correct? Just a bit more curious about this, because I'm truly curious which would be the worse hit in IE, 100 chubby closures, or 500 property lookups. Thanks John, Nate Cavanaugh Director of User Interface Engineering Liferay, Inc. Enterprise. Open Source. For life On Tue, Feb 24, 2009 at 8:46 AM, John Resig jere...@gmail.com wrote: @John regarding his specific questions: Part of the issue isn't that there isn't any way to solve jQuery's shortcomings, it's that there are no really good ways to solve them. For instance, I know I can use closures to get around scoping issues in jQuery, but most enterprises are stuck on IE6, and a ton of closures floating in memory that have a bunch of variables stored in each copy isn't ideal. My understanding of the JS memory model is no doubt flawed, but even MS themselves try to steer people away from closures because of how poorly they handle them. On the other hand, property lookups in Internet Explorer are just abysmal - and you'd be doing a ton of those if you were using nothing but OO techniques. You're damned if you do and damned if you don't in the land of Internet Explorer! Also, with extensibility, there are ways to overload methods. Sure I can rename an existing method to _something, and create a new one that references the old one, but that is NOT an ideal way to go about extending an object, especially in a multi-developer scenario with different scripts accessing the same objects. I agree with this. This was a big step that my proposed jQuery.plugin/widget code helped to solve: http://dev.jquery.com/~john/plugins/widget/widget.js It's very rough right now but it allows you to override existing methods and alter their inputs in ways that are quite elegant. I'm going to be working with the UI team some more (since they've been dealing with the issue of building complex, extensible, jQuery plugins for while now) to try and solve some of their problems. And the method should take advantage of Javascripts benefits. I don't think every plugin developer understands that shoving object properties and methods onto instances is way less efficient than using the prototype. Nor do I think they should have to understand. The system (like the current plugin system) should handle that for them. Agreed - also something the widget code helps with. See, I have no problem dropping 40 lines of code into core if it means that it'll help in the construction of jQuery plugins - making them dramatically simpler to develop complex ones - and extend them - without sacrificing simplicity. --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Feb 24, 3:57 pm, John Resig jere...@gmail.com wrote:
Does anyone have
any examples of plugins that they wished to extend in a particular
manner? (I needed the validation plugins X method to do Y - examples
like that.)
Many!
I've had to re-write BlockUI, Autocomplete, accordian, bgiframe,
context menu, etc. Others I have abandoned completely because they
were overly restrictive. I don't recall the reason in each case.
I've arrived at some guidelines I think should be followed when
writing plugins:
1. No method should be private. Not every method needs to be part of
the API, but don't hide any logic from being customized by a
developer. Just because you can't imagine a case where someone would
need to change the internal logic doesn't mean it won't happen.
2. All static values (strings, class names, numbers, defaults, etc)
should be stored as plugin properties that can be changed
3. Users should be able to over-ride defaults at the plugin level
(true for all instances) or per-instance
4. All logic should be broken up into the smallest logical chunks
possible. Each method should have a very specific task, which can be
over-ridden if needed
5. No assumptions should be made about the user's environment. For
example, don't blindly append newly created DOM elements to the body.
Allow the user to over-ride this default behavior if they wish. Don't
assume you know how to calculate a container's size using the built-in
jquery methods - separate that logic out to a function so I can
customize it if needed. In general, AVOID ASSUMPTIONS.
6. Any time HTML is created inside the plugin, generate it inside a
function that can be over-ridden if the user wants to generate
something slightly different
7. If your plugin has dependencies, do a quick check up-front to make
sure they are there, otherwise alert the developer
8. Any time you have static quoted text (or id's or class names, or
element names, etc), you better have a really good reason for assuming
that the user would never want to change it. And if you have a reason,
it's probably not good enough.
9. Provide many options, but also provide a logical default
implementation. Let the user do as little as possible to begin using
the plugin in a reasonable way, then show them just how much power
they have to customize it.
10. Pass in an {options} parameter instead of a hard-coded list of
options
11. Provide useful examples
12. Use a good code structure like ;(function($){ })(jQuery) and other
common recommendations
That's a short brain-storm at least. Key concept when writing a
general-use plugin - Avoid Assumptions! :)
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
I think I agree with all of your points, a great list. I was wondering
if you could clarify:
3. Users should be able to over-ride defaults at the plugin level
(true for all instances) or per-instance
Do you mean something like: .myplugin({ myprop: override }) where
passing in the option overrides it for that instance? (I think that's
what you meant, just wanted to clarify.)
5. No assumptions should be made about the user's environment. For
example, don't blindly append newly created DOM elements to the body.
Do you mean in the sense that appending to the body is bad - or that
body is a static word and thus should be a mutable option in the
plugin (#8).
10. Pass in an {options} parameter instead of a hard-coded list of
options
I think the corollary to this would be: If you start having optional
arguments you should really push your users towards using the
{options} object exclusively.
This gives a lot to work with, though. I think I'll probably do a
quick re-write of the jQuery.plugin stuff to try and codify some of
these notions.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
John, I am potentially interested. I'm concerned that what you are proposing would be a step back in helping large application development. There are a few reasons: 1. Some of jQuery's current conventions might hurt large projects (I've seen far too much added to $ and jQuery.fn ). Without code/ support for 'model' and 'view' type concerns, I think that these important components will be ignored. 2. There are 'better' solutions to some problems - like JMVC's include compared to ShrinkSafe alone. JMVC makes use of ShrinkSafe, but adds automatic compression to it. I think JMVC's controller is also 'better' at encapsulating event handling than widget.js. I am not attached to jQuery or its current user base. I want to deliver the best framework possible without much concern for prior-art for its own sake. I understand you have to protect your community center. 3. Most importantly, a single, integrated package is critical. It drives the development of the parts together. Plus, forcing testing and documentation isn't a bad thing. Well, I feel like the nerd after getting rejected by the prom queen. In movies, she always end up with him after he works real hard, makes his millions, and experiences some much needed personal and physical growth. It appears that I must travel this road. I would like to continue the discussion as a jQuery plugin. I submitted it to the plugins forum. I will add a link when/if this gets approved. On Feb 24, 3:26 pm, John Resig jere...@gmail.com wrote: Ok, so boiling down a list: Needs code: - Widget utility (I'm working on this) - Debugging utility - Static plugin analyzer Need a tutorial to cover the concepts of (I'm working on this): - Encapsulation - Extensibility - Modularity Needs (defined/documented) conventions: - File names - Method names - Method structures - Testing - Documentation - Packaging Once the above conventions are finalized, that static plugin analyzer can be written. Once the widget code is done, the tutorial needs to be updated. --- So, with that drawn in the sand, Justin, would you be interested in working on the debugging plugin, the static analyzer, defining conventions, all of the above? Any/all of those would be a huge help and I'd imagine that if the work is solid they should all become official jQuery projects/conventions. Now I'm not discounting any additional code or patterns but we need to start with what we have and make sure that we're working with the best possible resources. If we define the above conventions and code we may find that there is less of a need for a new project than we originally thought - and we get the benefit of having excellently defined and documented resources and conventions for people to use - so everyone wins. --John On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer justinbme...@gmail.com wrote: - package and minimize multiple files (YUI Compressor) - Could be solved much better as it is not integrated into the 'framework'. You have to 'double' include everything (once in your page, another in your build script). You have to set your html to switch from loading separate files to loading the combined in production. - documentation (jQuery Documentation Wiki - already allows devs to have inline demos and can be extracted to external sources) Unless I am misunderstanding something, does this allow me to document my application, or is this just for jQuery? I am talking about something similar to JSDoc. - testing (QUnit) Does it handles synthetic events? Can it run server-side to ensure sanity before checkin? Can you do point and click testing like selenium? Where do I put the files? What should I name the files? I'm not completely convinced that this is a huge problem - but at worst this could be solved through convention and documentation. How/where should I respond to events? How should I deal with state? How can I maximize the chances of re-usability? All three of these are handled either through better documentation or with the widget/jQuery.plugin code that I showed earlier (it especially helps to deal with state and reusability, while responding to events would be more of a documentation issue). Yes, these conventions are exactly what is needed. Documentation can definitely do that, but so far I've not seen it for jQuery. Where should I be connecting to the service? That's probably outside the scope of anything that we would do, since it would probably define what needs to happen on the server-side. I mean, where should ajax calls happen in the client? In JMVC they are in the Model, akin to ORM. How can I wrap the service data? (For example, maybe the todo has passed it's completion date and you want to ask it .isPastDue(). This seems like another case of encapsulation or dealing with state (imo). How can I create HTML in a readable manner?
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Feb 24, 5:44 pm, John Resig jere...@gmail.com wrote:
3. Users should be able to over-ride defaults at the plugin level
(true for all instances) or per-instance
Do you mean something like: .myplugin({ myprop: override }) where
passing in the option overrides it for that instance? (I think that's
what you meant, just wanted to clarify.)
I'm not sure if you mean what I mean :)
For example, in my context menu plugin (which is the only plugin I've
published so far as an example of some of the concepts I promote):
http://www.javascripttoolbox.com/lib/contextmenu/
source:
http://www.javascripttoolbox.com/libsource.php/contextmenu/source/jquery.contextmenu.js
You can do this:
$.contextMenu.shadow = false;
This will set the default value of the 'shadow' property to false for
all instances created from then on. So what I typically do is include
the contextmenu plugin, then in a separate include file per project I
will setup the defaults. From then on, everywhere I use the plugin in
the app I don't have to worry about setting it up, I can just use it
in the default state.
If I want to over-ride defaults for one specific context menu, I can
do it using the options array like:
$(.context).contextMenu( [menu] , {options} );
5. No assumptions should be made about the user's environment. For
example, don't blindly append newly created DOM elements to the body.
Do you mean in the sense that appending to the body is bad - or that
body is a static word and thus should be a mutable option in the
plugin (#8).
The latter. I've had situations where appending objects to the body
caused issues (because of weird layouts, etc). I've also had some
situations where I wanted newly-created objects to be children of a
specific container, not of the whole body. It's just one example of a
situation where a plugin author may assume that every object like an
absolutely-position menu should be appended to the body, but by making
it configurable it gives the developer flexibility without negatively
impacting the plugin functionality at all.
10. Pass in an {options} parameter instead of a hard-coded list of
options
I think the corollary to this would be: If you start having optional
arguments you should really push your users towards using the
{options} object exclusively.
Agreed. And required attributes should be hard-coded parameters before
the {options}.
This gives a lot to work with, though. I think I'll probably do a
quick re-write of the jQuery.plugin stuff to try and codify some of
these notions.
I hope you'll take a quick look at
http://www.javascripttoolbox.com/libsource.php/contextmenu/source/jquery.contextmenu.js
I don't propose it as a perfect or ideal solution. But it's one
approach, and I've built a template from it that I use in developing
new plugins. There are some places in the code where I could do some
re-writes to better incorporate my own guidelines!
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
