Forums

So I finally got some code together for how I'd like to see things head, and put it in a gist:

http://gist.github.com/593942

There are 3 files there, one for the Model, one for a QueryManager (still not sure I love that name but it's what I've come up with for now) and one showing how you might implement it with a table script (though I haven't finalized that script so I didn't include it for now).

First of all the Model, you define the same way you define any subclass of base, using the standard ATTRS map to define the members. There are a few utility methods on the Model class itself that are useful here, 2 of which are "reference" and "referenceMany", which allow you to create relationships between Models (in the example I have Books and Authors, and a Book has one Author). You use the reference methods (or any other parser) simply by adding a "setter" to the property, taking advantage of that functionality built into Attribute. I think I'll probably need to add some way of making the reference methods optionally be lazy and refer to a remote source, in case you don't want to load all kinds of data you might not need for every instance. You can also define RENDERERS and EDITORS (not yet implemented fully) which are indexed by the same key as the Attributes. I kind of would love to do away with RENDERERS and just use the "getter" property of an Attribute, but as far as I can tell this leaves you without a away to get the actual value in any way, so for now it needs to be separate. Finally every subclass of Model has a "members" class method which gives you an array of keys for the Model and its parents (unless they are marked as readOnly).

Model instances are fairly simple, they have "edit" and "render" methods which take a key and return the editor/rendered value for it, a "compare" method which lets you evaluate one model instance against another to see if they are equal (eg, they came from different sources), and a "toObject" method which returns a standard JS object which can then be further serialized into whatever format you'd prefer with another utility.

The QueryManager is defined into 2 parts right now, QueryManagerBase and QueryManagerLocal, and I still plan on adding a QueryManagerRemote. At its core, a QueryManager is designed to take a DataSource and a Model definition, execute queries to the source and return an ArrayList (gives you the each, some, etc. convenience methods) of instances of the Model. A QueryManagerLocal instance adds the ability to sort the data before putting it into an ArrayList, while the QueryManagerRemote will allow you to set params, serialize them into a query string, and make the request to the DataSource. Additionally, a Paginator widget would interface either directly (by taking it as an attribute) or indirectly (via events) with the QueryManager.

My goals throughout all of this are 1) reuse as much of YUI3's infrastructure as possible (take advantage of Attribute/State rather than writing Fields, FieldDefs, etc. which reproduce this functionality) 2) develop only a base amount of functionality as would be necessary to model data for use in widgets (I'd rather see this toolset come in at 60-80% of what people need and get added to rather than too much and have to find a way to deprecate/move functionality) 3) take all of the interaction with queries, sorting, and pagination out of DataTable so that it is left to do just one thing: render tables (the rest of that is just as useful to a number of other widget types which shouldn't need to load any of DataTable to do the rest).

I know this is probably quite a bit different than what you guys are coming up with, so I hope we can find some common ground and go from there.

I agree its tough to know how to partition everything. Honestly, like I mentioned I'd love to just use the Attribute "getter" property rather than a separate RENDERERS hash, if Attribute were modified to allow a way to bypass a getter and just get the raw data I think that I would go that way. As it stand I don't see one, which means that the raw data is hidden once you define a getter. As far as EDITORS goes, I'm still not convinced that belongs on the Model either; most SS frameworks seem to take the path of defining a separate Form module, which may be a better option here.

The reference methods I defined I agree have some pitfalls, as you mentioned you could end up with multiple copies of the same data (though this is as much a problem with how data is serialized between the server and JS as anything, you'd end up with that problem even if you just used raw data), and even worse it can quickly become an infinite loop, for example if I just change Author to look like this:



Now the nice thing about using the "getter" functionality of Attribute is that it's lazy; until you call myInstance.get('attr') for the first time, the getter method hasn't fired and the value in memory is just the raw data. To further help this, I thought of making reference lazy as well (lazier? ). This would first entail adding a PRIMARY_KEY (as Satyam suggested) to the Model definition, which would point to some attribute on the model to use as a unique identifier. The Model would then use that key in a hash on the constructor to store a reference to each instance built (just references so no additional memory/code is affecting performance). Then rather than pass the entire data blob to construct reference properties, just pass their primary key, and reference can just do a lookup on the supplied constructor's hash. This would also require some way of then executing a fetch to the server if the data for the given key doesn't exist.

All that being said, I think the reference stuff may violate that 60% rule I was striving for. I just thought it was a cool idea and hopefully we can make something come of it. I don't know if we can necessarily define what 100% is at this time; I think the goal should be to define at a bare minimum what would be required (even if it puts a little more work than desired into the implementors for now), try creating a few Widgets based on it (I'd like to see a DataTable, a List, and a Form at least), and see where the common pain points are.

Hi,

this is the sort of idea I was thinking with index plugins. Obviously there's more - they need to update themselves when records are added/removed, but the point is that the base filter/sort ought to check if the index exists. I suppose a RecordSetIndexBase could listen for and cancel host methods, but I don't know what the overhead of that is compared to the extra kb/hassle of supporting indexes directly...

Anyway, here it is:
http://gist.github.com/599527

Matt

Satyam,

If you want to move the discussion to a new, more appropriately titled, thread, you're welcome to. There's a pretty good chance the others on the thread would follow

Greg,

I had a bit of a thought about reference(). It involves RecordSets though!

Rather than (or perhaps as well as) telling the concrete Book instance who the Author instance is, could you have a reference at the 'table' level, so:

sort of thing?

Matt