I'm fond of the elegance of chaining for manipulating the DOM.
The chaining methods of jQuery operate on a set of items and as
someone who's landed and getting used to the library and it's idioms
the ability to act on all the elements that match a pattern
accurately models how I view markup.
$('div.menu').click(menuClick)
.addClass('top-level')
.css('height', calculateMenuHeight() + 'px')
I agree, Stephen, that sometimes it doesn't make sense to me to have
a method in the jQuery namespace.
jQuery.fn.toJSON
It doesn't chain. It doesn't maniuplate the DOM. I love the library,
but maybe it would be better off in a different "namespace".
When I look at some Prototype code, I can see how the controller way
of doing things is very easy to read and maintain.
Especially, when Prototype idioms are used without going through the
bother of creating new classes and setting up prototypes for
what are singletons. The code gets a lot cleaner. There are
controllers for distinct views of the MAJOR compontents of a UI.
// imagine yourself some code in these functions.
var gridView = {
redraw: function () { }
show: function () { }
hide: function () { }
showing: function () { }
}
var treeView = {
redraw: function () { }
show: function () { }
hide: function () { }
showing: function () { }
}
var menu = {
switchViews: function () {
var showing = gridView, hidden = treeView
if (treeView.showing()) hidden = gridView, showing = treeView
showing.hide()
hidden.redraw()
hidden.show()
menu.viewToggle(treeView.showing())
},
viewToggle: function () { }
}
Event.observe($("#switch"), 'click', switchViews)
I have been programming this way with Prototype. You'll note that I
don't have to bind to this, which saves a lot of verbiage.
This might not be ideal for jQuery, because there is path for the
above singletons to follow where they can become classes, and begin
to look like script.aculo.us objects, fully reusable.
jQuery may want to draw a distinction between what should be a DOM
manipulation plugin, versus a complicated UI object, like a tree
view or grid.
To me the distinction is the differnce in traditional UI programming
between a form control like a check box, versus the lineTo and
fillRect methods of the device context.
What I didn't like about Prototype was that idioms were did not
embrace the structure of the DOM. Prototype prefers that you find
things by ID. There was one of everything. The controllers could get
monolitic, when sometimes I want dozens of little active UI elements.
jQuery allows me to quickly attach event handlers to the specific
nodes in the document that represent UI controls. Within the above
controllers, I find that jQuery serves me well.
Thus, jQuery can take the controller centric model and make it lot
more powerful.
* Stephen Howard <[EMAIL PROTECTED]> [2006-11-30 17:25]:
> I know we're all fond of the elegance of chaining, but would it be the
> least confusing to write it like:
>
> var gridControl = new Grid( '#grid' )
>
> where:
>
> function Grid( dom_string ) {
>
> jQuery( dom_string ).each( function() { instantiate here... } );
> ...
> }
>
> Remember not everything needs to look like jQuery.
>
> - Stephen
>
> Dave Methvin wrote:
> > This will be a short thread--NOT! :-)
> >
> >
> >> Controller set of methods is returned..
> >>
> >> $('#grid').grid().data(data).drig().show()
> >> $('#grid').grid().scrollToRow(6).drig().css("border", "1px")
> >>
> >
> > Uh, drig()? So if I want to return to I was before scrollToRow(6), should I
> > use (6)woRoTllorsc? ;-)
> >
> > I don't know if this a good idiom; changing the object type within the chain
> > might be be too tricky. Also, would the plugin itself have a need for
> > chained methods to change its internal state? Still, to make your object
> > chainable like that, I think your $().grid method would just need to save
> > its jQuery "this" in your Grid object before returning:
> >
> > jQuery.fn.grid = function() {
> > var gridObject = // ... get your grid object ...
> > gridObject.jQuery = this;
> > return gridObject;
> > }
> > jQuery.fn.drig = function() {
> > return this.jQuery;
> > }
> >
> > As Jörn mentioned, you could still use $("#grid").grid() to create and/or
> > retrieve a Grid object, even if it wasn't chainable. It seems like you'd
> > want some way to determine whether it was a Grid creation or just getting an
> > existing object; you could have a separate $().createGrid() method or maybe
> > the $().grid() argument could be required on creation. (Also, should the
> > core should a standard way for plugins to associate object data with an
> > element, like it does with events?)
> >
> > Whatever results from this discussion should go to the plugins authoring
> > page on the wiki, http://jquery.com/plugins/Authoring/
> >
> >
> > _______________________________________________
> > jQuery mailing list
> > discuss@jquery.com
> > http://jquery.com/discuss/
> >
>
> _______________________________________________
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
--
Alan Gutierrez - 504 717 1428 - [EMAIL PROTECTED] - http://blogometer.com/
Think New Orleans - http://thinknola.com/
_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
