Forums

Thanks everyone for your inputs. Please keep the suggestions coming. Just wanted to post a reply on some of the things that have been said so far:

@Satyam: You're absolutely right in your constructive criticism. Recordset as it exists right now is essentially a YUI2 port - mostly because I was unaware of ArrayList. I see no harm in augmenting ArrayList, and I am refactoring my code now to allow that. Your example has been very useful! Definitely lots there to think about.

Re. the notion of whether records within a recordset should be consistent:
My personal view on this is that they should be. I think of recordset as a way to store data which has a consistent set of properties (as Satyam said - kind of like how a SQL table would behave). To answer Matt's question on how a media shelf would behave, I was contemplating the idea of letting recordsets merge along defined fields that the user can specify.

ie: In very rough pseudocode:


Ofcourse, now we get into the idea of multiple versions of the same object residing in 2 different recordsets. However, I feel this way is more intuitive as this is similar to how SQL would behave (correct me if I am wrong).

There's a lot more to talk about. As all of you mentioned, there are a plethora of plugins that could be made to extend the functionality of Recordset. Indexing, Primary Key Handling and Serialization are good ideas which can and will be considered.

Obviously, lots of questions still unanswered. I'll post frequently outlining my updates, and posing my questions. Please continue to do the same! You guys are a great help

Hi all,

Just wanted to update everyone of the progress that has been made on recordset thus far.

The recordset-base module now has a hash table as an ATTR. The records are hashed by their 'id', as we know this will always remain unique. The hash table is kept in sync with the recordset through the custom events that are fired, "add", "remove", and "update".

recordset-base augments Arraylist as we had mentioned before (Thanks Satyam for your code samples on this - it helped a lot).

Also wanted to say thanks to Matt for his last gist. Although I have deviated from Matt's thought of hooking into ArrayList's add, remove method - I have implemented the onHostEvent() functionality throughout the plugins, and its been a great help. I'd be up for a discussion on why I did not use Arraylist's add/remove methods if anyone has a counterargument to that. I, however, am relying on arraylist for a whole host of other methods (each(), some(), filter(), etc.)

So far, there are 3 submodules for recordset - Filter, sort, and indexer. Filtering returns sub-recordsets and many of its methods simply pass through to array-extras utility. However, whereas array-extras returns arrays to you, the filter sub-module converts this to a recordset to allow you to use a common API.

Sort is pretty straightforward, and doesn't have anything too drastic in it. The ATTRS have been modified to include a state object, which records how the array was last sorted. Also, there is an "isSorted" flag which tells you whether the recordset is in a sorted state. The only other thing of note is a flip() method in addition to a reverse() method. While reverse() performs an array.reverse, flip() actually sees your last sorted state, and revereses the direction of sort. Again, the wording on these methods can be discussed but I feel there is a use-case for each method.

Indexer extends the hash table concept in recordset-base and allows you to create multiple hash tables with your own custom key. Again, the hash tables you create are kept in sync with the recordset through the custom events "add", "remove", and "update". Also, there is no collision handling when it comes to handling the hash tables. Right now, if your key is not unique, it will overwrite. Is there a need for collision handling on these tables?

Any other questions, let me know!

Hi Tilo

Thanks for the update.

I'm looking through the sources one by one. Let me comment on each:

record.js

There is a function Y.stamp() which calls guid and stores its value in a property _yuid. I believe that it would be better to use that in the initializer method so the value is stored in a well-known place (handy when debugging) and then have a read-only id attribute with a getter.

I disagree with having the id value accessible through getValue. After all, 'id' is a quite popular field name and you would be preventing developers from using that field name as it would hold a special meaning.

I am not sure it is safe to have getValue return a reference to the record values when no specific field is requested. It would be safer to return a clone of that. You should not be able to modify the values directly without going through setValue.

I was reading sequentially so I didn't notice until I got to the end of the file that there is no setValue yet.

It wouldn't be a bad idea to provide an enumerator though it is not really required, after all you could do:

Y.each(myRecord.getValue(), function (value, name) {
});

but it would provide some consistency in the interface if you did.

Now, the big question: should Record hold plain values or, as I did, hold Field instances, where you have extra information about the value itself, such as initialValue, undo stack, whether it is dirty or new?

I believe that information to be important, though it can be implemented in other ways, for example, instead having each item in the Record hold a Field instance, have separate hashes for data, initialValues, dirty and new flags and so on.

I use the dirty flag in the serializers so that only dirty fields get sent to the server. I also use the dirtyChange event to enable the submit button in the form only when there is something changed to submit. I am not sure about the usefulness of a undo stack, that can be open to a plug-in, but apart from individual features, I think it is important to define how to store meta-information for each field, not meta-information for a whole column but for each field in each record, whether a Record should contain plain values or Field instances or, alternatively, whether meta-data should be stored as separate hashes.

I think that defining this is important so I'll let comments on the other source files to further messages, let me submit the following questions:

a) Should a Record store meta-data about its values?
b) How should it be done, by having data stored in Field instances along other meta-data or have separate hashes with meta-data?
c) What meta-data is worth it and whether in the base or as an extension/plug-in?
- c1) dirty
- c2) new
- c3) initialValue
- c4) undo stack
- c5) other info?

The answers to the cx) questions above imply whether methods such as reset, undo and accept (or synced, if you will) in my example can be implemented and events such as dirtyChanged exist.

I always keep in mind that the Record and RecordSet objects are to store information coming from a server, more likely from an indexed database table and that I mean to cover the whole round trip from that table and back to it. I am not particularly excited about a client-side id for the Record (though there is nothing wrong with having one) because it is meaningless to the main repository of the data, which is the database server. In fact, such an id would be very handy since it can be used to relate TR elements in a DataTable and Record instances and I don't mean to drop it, but I want to insist on looking at the whole lifecycle of the data, not just its temporary visit to the browser. Otherwise, RecordSet would be little more than a glorified ArrayList and it would fall short of a full solution.

Regarding recordset-base:

In initializer, you don't need to use Y.bind, you can do:

this.publish('add', {defaultFn: this._defAddFn});

In most _defXxxFn, don't add the hash updaters at the end of each, I think it would be more proper to subscribe to the after add, remove, empty and update events. Remember to detach those listeners in the destructor.

I believe it should be RecordSet, not Recordset. It is RecordSet in YUI2, just as it is ColumnSet or my FieldSet.

I don't see any need for the table and key attributes. Record doesn't know about any other key than id so it is pointless to change it on the RecordSet if it doesn't match Record and, anyway, I don't see any reason to use any other name anyway. I don't see any need to be able to access the hash table except through the methods provided, I would keep it as a private property.

I like the records attribute, but I would make it use empty and add so it produces all the secondary effects that it should and might do in the future. (as it is, it doesn't create the index).

I believe RecordSet still has some carry overs from YUI2 RecordSet, for example, since RecordSet is augmented with ArrayList, what's the point of having getLength() or getRecordByIndex if you have item()?

Also, you are generating the index hash but are barely using it except in getRecord. Since GUIDs are strings, perhaps methods that take an index should also be able to take a string, this update might take an integer index and optionally range or a record id and no range. Same with delete. I don't believe it would make any sense to have add take an id instead of an index. ArrayList index should also be overridden to take an id.

I would drop getValuesByKey, if anything I would rename it getColumnValues but I think it doesn't really add anything that could not be done by the enumerator.