Re: [jQuery] Designing for reuse
Hi Alan! Thus, jQuery can take the controller centric model and make it lot more powerful. It would be really great if you could put an example showing what you described here. Something to click trough to see it in action. -- Jörn Zaefferer http://bassistance.de ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
Alan Gutierrez schrieb: I'm now growing partial to this convention... $(div.grid).grid() .data(gridData). .columns(2, 3, 7) .select() .sortable() .grid() .rowHeight(22) .jQuery() .show() .css(width, 500px) Which is where you return control by naming the object that you wish to recover. I don't see what you gain here. Why don't you stick with simple references? var grid = $(div.grid); var gridController = grid.grid(data); gridController.select().sortable().blablabla(); grid.show().css(width, 500px); If you don't need the references anyway you don't have any overhead of saving them. Makes debugging much easier anyway: Imagine that you columns() method is buggy: The complete chain goes to hell and you have to split it into small parts to find the problem. -- Jörn Zaefferer http://bassistance.de ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
Hi,
// imagine yourself some code in these functions.
[...]
Event.observe($(#switch), 'click', switchViews)
I like that. In jQuery-style it could be something like this:
jQuery('#switch').bind('click',function() {
var showme = jQuery.treeView('#mytree');
var hideme = jQuery.gridView('#mygrid');
if(showme.visible()) {
var tmp = hideme;
hideme = showme;
showme = tmp;
}
jQuery(hideme).hide();
jQuery(showme.redraw()).show();
jQuery.menu('#mymenu').viewToggle(true);
});
That way the controlers themself can be queuable with their methods and the
jQuery() function can convert controllers to jQuery-Objects. If the
controller functions usually take everything that jQuery() takes as well they
migt always have the same structure:
jQuery.treeView = function(selector,options,context) {
return {
jqo :$(selector,context).each(function() {
if( !this.controllers ) this.controllers = {};
if( !this.controllers.treeView ) {
this.controllers.treeView = {
options: options,
init: function() {...},
changeOptions: function(newOptions)
{...},
redraw: function() {...},
...
}
this.controllers.treeView.init();
} else this.controllers.treeView.changeOptions(options);
}),
redraw: function() {
this.jqo.each(function() { this.redraw(); });
return this;
},
...
}
};
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
Hi,
Controller set of methods is returned..
$('#grid').grid().data(data).drig().show()
$('#grid').grid().scrollToRow(6).drig().css(border, 1px)
A controller object is returned..
var grid = null
$(grid).grid({
data: data,
onComplete: function(controller) { grid = controller }
})
grid.srollToRow(6)
What is best practice?
How about the Idea to have a jQuery-function that returns the controller
object:
$('#grid').grid({data:data}).show().gridController().scrollToRow(6);
That way the function that creates the grid does not break the chain, but
there is a function that returns a controller object. You don't necessarily
need a way to come back to jQuery if you do it that way, because you can
chose to get the controller Object later in the queue.
You should think if you want a controller object that can handle mutliple
grids at the same time:
$('.allmygrids').grid({data:data}).show().gridController().scrollToRow(6);
If not, then gridController() needs to take a parameter to know which of the
grids you mean:
$('.allmygrids').grid({data:data}).show().gridController(42).scrollToRow(6);
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
On 01/12/06, Christof Donat [EMAIL PROTECTED] wrote:
Hi,
Controller set of methods is returned..
$('#grid').grid().data(data).drig().show()
$('#grid').grid().scrollToRow(6).drig().css(border, 1px)
A controller object is returned..
var grid = null
$(grid).grid({
data: data,
onComplete: function(controller) { grid = controller }
})
grid.srollToRow(6)
What is best practice?
How about the Idea to have a jQuery-function that returns the controller
object:
$('#grid').grid({data:data}).show().gridController().scrollToRow(6);
An perhaps have a method that returns you back to jQuery object?
Calling it 'end' (or any other jQuery method name) may be confusing,
something like 'endGrid'.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
Hi,
$('#grid').grid({data:data}).show().gridController().scrollToRow(6);
An perhaps have a method that returns you back to jQuery object?
Calling it 'end' (or any other jQuery method name) may be confusing,
something like 'endGrid'.
I don't think that is necessary. You could compare it to a call like
$('...').css('color'). That returns a string wich has methods like e.g.
substr() but no way to return to jQuery, because it is not necessary. You
almost always can move the call to gridController() to the end of your chain.
Another way to solve the problem would be to use classes in the grid like
this:
$('#grid').grid({data:data}).find('.row_42').scrollToView();
Then you just add methods like scrollToView() to the jQuery object which are
very usefull in other cases as well. Though I am not shure if you can do
everything the grid controller needs that way.
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
Heh, I should have read this first, before suggesting it myself. *blush*
- Brian
On 01/12/06, Christof Donat [EMAIL PROTECTED] wrote:
Hi,
Controller set of methods is returned..
$('#grid').grid().data(data).drig().show()
$('#grid').grid().scrollToRow(6).drig().css(border, 1px)
A controller object is returned..
var grid = null
$(grid).grid({
data: data,
onComplete: function(controller) { grid = controller }
})
grid.srollToRow(6)
What is best practice?
How about the Idea to have a jQuery-function that returns the controller
object:
$('#grid').grid({data:data}).show().gridController().scrollToRow(6);
An perhaps have a method that returns you back to jQuery object?
Calling it 'end' (or any other jQuery method name) may be confusing,
something like 'endGrid'.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
On 01/12/06, Brandon Aaron [EMAIL PROTECTED] wrote: If this type of functionality starts to be required I would suggest including a standard way for plugins to easily restore state (.end()) in the core. Destructive methods will be no more in 1.1, so I don't think .end() will be around either. Going a bit offtopic, but how would it work if it is non-destrutive? div /div div class=foo /div div class=foo /div $(div).eq(0).append((first)).eq(1).append((second)).filter(.foo).append((has class foo)); If 'end' is executed before the next filter/eq etc, then the result would be the following (rather than just the first append working). div(first) /div div class=foo(has class foo)(second) /div div class=foo(has class foo) /div Also, what if you did (I'm assuming 0 based, so lt(2) returns those before the 3rd): $(div).lt(2).gt(0); Would that result in the first 2 div's being selected, or all 3? If all three, then you would need 'between' as a function ($(div).between(0,2)). Also you may want to do something a bit more complex: $(div).lt(2).filter(.foo); // should return the second div only Or am I not understanding non-destructive properly? ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
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/
Re: [jQuery] Designing for reuse
* Brandon Aaron [EMAIL PROTECTED] [2006-12-01 10:16]:
On 12/1/06, Sam Collett [EMAIL PROTECTED] wrote:
An perhaps have a method that returns you back to jQuery object?
Calling it 'end' (or any other jQuery method name) may be confusing,
something like 'endGrid'.
I don't think using .end() would be confusing. If it makes sense for a
plugin to use method chaining then why not use the standard for
returning state, .end(). If this type of functionality starts to be
required I would suggest including a standard way for plugins to
easily restore state (.end()) in the core. Destructive methods will be
no more in 1.1, so I don't think .end() will be around either.
However, it seems to make sense (to me at least) to be used in
situations like these.
$('#foo').grid({data:data}).show()
.gridController() // load grid object
.scrollToRow(6).anything().else().with().grid()
.end(); // back to jQuery
Does destructive mean that a filter changes the returned contents of
the list returned by the initial jQuery?
--
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/
Re: [jQuery] Designing for reuse
* Brian Miller [EMAIL PROTECTED] [2006-12-01 09:05]:
Hi,
Controller set of methods is returned..
$('#grid').grid().data(data).drig().show()
$('#grid').grid().scrollToRow(6).drig().css(border, 1px)
A controller object is returned..
var grid = null
$(grid).grid({
data: data,
onComplete: function(controller) { grid = controller }
})
grid.srollToRow(6)
What is best practice?
How about the Idea to have a jQuery-function that returns the controller
object:
$('#grid').grid({data:data}).show().gridController().scrollToRow(6);
That way the function that creates the grid does not break the chain, but
there is a function that returns a controller object. You don't
necessarily
need a way to come back to jQuery if you do it that way, because you can
chose to get the controller Object later in the queue.
You should think if you want a controller object that can handle mutliple
grids at the same time:
$('.allmygrids').grid({data:data}).show().gridController().scrollToRow(6);
If not, then gridController() needs to take a parameter to know which of
the
grids you mean:
$('.allmygrids').grid({data:data}).show().gridController(42).scrollToRow(6);
How about overriding $.end() in the grid plugin, so that it returns the
original jquery object if it's run on the grid controller?
Of course, you'd have to remember to make $.end() behave normally if run
elsewhere. Or, you could just create an $.endGrid() function for the
controller, and not worry about messing with $end() at all.
I'm now growing partial to this convention...
$(div.grid).grid()
.data(gridData).
.columns(2, 3, 7)
.select()
.sortable()
.grid()
.rowHeight(22)
.jQuery()
.show()
.css(width, 500px)
Which is where you return control by naming the object that you wish
to recover.
--
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/
Re: [jQuery] Designing for reuse
* Christof Donat [EMAIL PROTECTED] [2006-12-01 05:28]:
Hi,
$('#grid').grid({data:data}).show().gridController().scrollToRow(6);
An perhaps have a method that returns you back to jQuery object?
Calling it 'end' (or any other jQuery method name) may be confusing,
something like 'endGrid'.
I don't think that is necessary. You could compare it to a call like
$('...').css('color'). That returns a string wich has methods like e.g.
substr() but no way to return to jQuery, because it is not necessary. You
almost always can move the call to gridController() to the end of your chain.
Another way to solve the problem would be to use classes in the grid like
this:
$('#grid').grid({data:data}).find('.row_42').scrollToView();
Then you just add methods like scrollToView() to the jQuery object which are
very usefull in other cases as well. Though I am not shure if you can do
everything the grid controller needs that way.
Christof
You can't do everything that the grid controller needs, but some of
the things that you do need, can be universal. Your suggestion takes
advantage of the jQuery way, which is very DOM centric. It doesn't
treat the DOM as primitives, but a useful model. Tree structures,
event bubbling, path langauges are powerfully expressive, they
simply need to be made consistant across browsers.
Thus, there are some ways in which a grid might have components that
are grid abstractions, but also document the structure of the DOM
that it generates so that programmers can add their own effects.
$('#grid').grid({ data: data })
.gridController()
.column(5).select().gridController()
.jQuery()
.find('.row_42').scrollIntoView().addClass('selected')
Here's a case study to lead into a point.
I came to jQuery looking for a way to create a grid control that did
a grid and nothing but a grid. Other libraries had grid controls,
with sortable, reorderable, resizable columns, with ajax updates,
and in place editing, etc. I didn't want these things. I could turn
them off, but I'd still have to download them, parse them, and step
around them.
What I wanted was a table that could scroll. If I didn't need the
other features, I didn't want to pay for them.
What I like about jQuery, is the potential to build more complicated
objects from primatives. With jQuery you don't hide DOM behind
controllers the way you do in Prototype. jQuery is very DOM centric,
which is good, because we still don't have the speed to afford
ourselves too many abstractions.
At the same time, the DOM is a pretty powerful abstraction, and
probably doesn't need to be treated like gorey details.
One programmer can create a simple grid renderer, but advertise what
is rendered. Another programmer can whip up a smooth scroll into
view, by attaching jQuery behaviors to the well-documented grid markup.
--
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/
Re: [jQuery] Designing for reuse
Alan Gutierrez schrieb:
A controller object is returned..
var grid = null
$(grid).grid({
data: data,
onComplete: function(controller) { grid = controller }
})
grid.srollToRow(6)
I favor that approach, modified:
var gridControl = $(#grid).grid(data);
gridControl.scrollToRow(6);
I don't mind breaking the chain in that case.
The nice thing: You can still use jQuery's documentation system when
writing your own objects and methods.
It would be nice to hear other's opinions on this topic, in the end,
more stuff for the plugin authoring guide may be the result.
--
Jörn Zaefferer
http://bassistance.de
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
* Jörn Zaefferer [EMAIL PROTECTED] [2006-11-30 16:12]:
Alan Gutierrez schrieb:
A controller object is returned..
var grid = null
$(grid).grid({
data: data,
onComplete: function(controller) { grid = controller }
})
grid.srollToRow(6)
I favor that approach, modified:
var gridControl = $(#grid).grid(data);
gridControl.scrollToRow(6);
I don't mind breaking the chain in that case.
The nice thing: You can still use jQuery's documentation system when
writing your own objects and methods.
It would be nice to hear other's opinions on this topic, in the end,
more stuff for the plugin authoring guide may be the result.
I'm very interested to hear more ideas. The documentation system is
attached only to jQuery.fn I take it.
After writing about it, I gave the method chaining solutions some
more thought, I guess because they seem more jQuery like. Some of
the problems I had with it started to explain themselves.
// return dimesions of the first grid
var h = $(#grid).grid(0).rowHeight
// ..or
var h = $(#grid).grid().rowHeight()
// apply to all grids
$(#grid).grid().disableColumn(2).rowHeight('22px').drig().width('300px')
// maybe this reads better...
$(#grid).grid().disableColumn(2).rowHeight('22px').jQuery().width('300px')
// does it get out of hand?
$(#grid).grid()
.columns(2, 5, 6).select().grid()
.rowHeight('22px')
.jQuery().width('300px')
--
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/
Re: [jQuery] Designing for reuse
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/
Re: [jQuery] Designing for reuse
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/
Re: [jQuery] Designing for reuse
Remember not everything needs to look like jQuery.
Or does it?
On 11/30/06, Stephen Howard [EMAIL PROTECTED] wrote:
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/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
only when it's better stated in jquery! which is always!
On 11/30/06, Matt Stith [EMAIL PROTECTED] wrote:
Remember not everything needs to look like jQuery.
Or does it?
On 11/30/06, Stephen Howard [EMAIL PROTECTED] wrote:
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/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
--
Ⓙⓐⓚⓔ - יעקב ʝǡǩȩ ᎫᎪᏦᎬ
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Designing for reuse
jQuery is a library that acknowledges the existance of the DOM, and
builds on on the DOM. Prototype is a library that focuses on
creating controllers, and looks at the DOM more as a templating
engine, not a data structure in itself.
If all this method does...
var grid = $('#grid').grid()
...is what you suggest below, then I agree that it's probably better
to say that you've creating a controller, and you should use objects
to model these complicated user interfaces.
You've added grid to the namespace of jQuery, but all it is a
constructor. You can use the documentation, but it doesn't buy you
anything.
It's creating a very contentious namespace, the jQuery.fn object,
and I'm kind of surpised to find a lot of singleton objects there.
I'm using a method $.toJSON, it's a jQuery json plugin, but it's
entirely static and has nothing to do with the selection engine.
* 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)
--
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/
