Forums

Matt,

I think I didn't opt for the best solution and you have the right of it. The way it now works is that you define your DataSource and DataSchema and tell it which fields there are and it will read all of them and add default FieldDefs for everything that comes in that is not already defined. So, in the way it is now, you are not forced to have FieldDefs for fields you don't care much about. If there is a FieldDef for a particular field, it will use it, in this case, it will take the server.parser function. In the way you suggest, which seems more formal, you would have to have FieldDefs for all fields because the resultFields would be build out of that.

Perhaps I could have it both ways. If there is no resultFields defined, take them from the FieldsDefs for the RecordSet, otherwise, accept what there is.

Regarding 'visible' I have it all messed up in my mind along with filtering. I can't figure out a way of doing it properly. Filtering out visible records is no different than filtering page one for a paged DataTable. To start with, I'm not sure if it should be a Record attribute or it should be a filtering function.

I'm not sure about setting 'visible' on a FieldDefs either (column instead of record visibility). I am more inclined to think that it would be up to the UI widget to decide on that though, I guess, it might be both ways, have the 'visible' fieldDef attribute (for example, on primary keys) and be able to override it in the UI widget as well.

I am quite sure by now that I can't have RecordSet be augmented from ArrayList just like that. Filtering is one reason, I can't let, say, DataTable, loop through all the records via ArrayList.each(). Also, I need to keep in mind missing records when using server-side paging. I should fire an event when a Record is not there (either by using the search() method to fetch by key or the item() method to search by index) so that a new request can be sent to the server.

The enumerating function should also be able to take a start index and item count so it can loop through a specific page of Records.

I know I'm missing lots in the area of events. Sort should first fire an event and the actual sorting function should be the default action for that event. That would allow, for example, to handle server-side sorting.

And I'm unhappy with sing 'key' to refer to the field name. I guess I'll go on and replace fieldName for key everywhere.

Thanks for the ideas. I have two more clear items on my todo list and the filtering stuff I'm still unclear about.

I would like to keep the public interface of ArrayList, methods like each() and item() but I'm afraid that I wouldn't be able to keep any of the implementation of it, since ArrayList always assumes that what it has is all there is and allows for no filtering. So, it is the implementation of ArrayList the one I cannot keep and as for the method names, some might not be possible or might need to have extra arguments.

In terms of filtering, visible would be one more filter and I believe I would have to allow to pipe records from one filter to the next. For example, a request for a certain page of visible records might require piping first from the 'visible' filter into the 'skip nth records' then to the 'count nth records'.

The order of these filters matters because, currently, if you want to filter on display (for example, via a row formatter) you get pages of different lengths since DataTable first picks rowsPerPage records and only then you get a chance to filter out, but you can't add extras to compensate for the ones you filtered out.

An item that has long been in my wishlist was paginating by initial(s) or date or other value ranges instead of plain page numbers. Filtering would allow this.

I'm not sure about putting DataSource functionality into RecordSet, I might be overstepping beyond safe boundaries if I set the schema on the DataSource automatically. In fact, that might be a reason to prevent me from doing it. The way you suggested, by using some getKeys() or getFieldList() might be proper.

I'd like to throw my 2 cents in on this (sorry if it's a bit late, I was in meetings all day and only now was able to read all the thoughts coming in).. I'm not sure I agree with the idea that the fieldDefs are a property of the RecordSet. In my mind, all of that data lives with the fields on the Record itself. The Record should be a base constructor which you extend to represent various types of data you have. Fields could be a property of the class you create, similar to ATTRS now. Each field definition in that array could have all of what has been discussed already (a key, a way to parse and serialize itself for the server, a way to present, edit, and validate edits in the UI).

What I've found is that in working with the current Records/RecordSets from the YUI 2 DataTable, it is very convenient to pass around the Record instances themselves, but passing around the RecordSet itself as well is an extra burden. For example say I have a table representing a collection of books, and I want to click on one and edit it, I can have a BookEditor widget that takes a Record that represents a book, and draw itself accordingly as a form. I may also want to take books and push them into a cart for checking out, and that widget can also take a book Record and draw what it needs to (likely a small subset of the data).

In this new model, I would have a Book class, which has defined a number of fields. In my DataTable, I can define which keys I want to show, and then load in a set of Books, and each of those fields knows how to format itself for the UI and renders appropriately. Similarly, I go to edit one, and the BookEditor just has to take the Book instance and draw all the editors for the fields in the Book. Additionally, knowing that we are going to be working with Book instances, we can take the constructor class and easily define a DataSchema in JSON or XML or whatever from the fields defined there. Records could probably even have simple CRUD in user defined methods, though batch operations would be best handled elsewhere.

In this case the RecordSet itself becomes a lot more abstract. In fact, I'm not even sure we need an actual RecordSet class. Certainly there is a need for coordinating class that has a DataSource and a Record definition, and is able to make requests to the server (or take static data) an turn the results into an array of Records. But I would imagine it could just fire an event when it has that array, basically saying "anyone who wants these can have them."

Luke,

Widget-Parent uses ArrayList but only overrides add and remove. I would need to override almost all other methods.

For a server-side paged set, I need to override item() so that if the item is not found, I can fire an event that will trigger a request to the DataSource to load that page.

If I use filtering, I can't use each() and some() since I have to get filtering functions stand in between the caller to each() and the actual array.

Widget-Parent rests at ease knowing that there are no more items than it has and that all items are good, none needs to be filtered out. Only add and remove need some special handling.

Matt,

I think that Greg's point is not that there should be no RecordSet at all but that Records should have a life of their own. Forms, for example, cannot show more than one Record at a time so Records need to have some independence of RecordSets.

It would be great to have a DataSource.SQL to use in Node.js, whenever the time comes for Node.js to have access to any SQL engine: (good question for Dav for next Open Hours) or even some noSQL engine (which it should be possible right now since some NoSql engines use HTTP requests: note to Dav: some demo would be great), though NoSql engines are not really suited to serve tabular data but documents.

In either case, RecordSets would be the natural mechanism for all this to happen, after all, they do parsing and serialization so they could work nicely on both sides. The RecordSet on Node.js would not have any storage, all requests would produce a page fault which should be served by the DataBase engine .... or the storage for RecordSet would be the DataBase engine itself. Never mind, I hadn't thought about Node.js and YUI on the server side until right now that I read your message, so I'm just brainstorming .... more storming than braining. Luke: another guest for our not so open hours?