Record 'converter' and ColumnModel 'renderer'

[sjivan]

A Store has an list of Record definitions which have a 'converter' property. The docs for this state that it is "a function which accepts a data value and returns it formatted for display".

A Grid contains a store and a column model. Column Model has a property 'renderer' which is "a function used to generate HTML markup for a cell given the cell's data value. If not specified, the default renderer uses the raw data value."

So it appears that for grid rendering, the column models "renderer" is used. While for stores used in forms, the Record's "converter" is used.

Could the Records "converter" not be used for Grid rendering as well?

Sanjiv

[Animal]

They are two different things, and perhaps the docs are slightly misleading - I'll take a look at them.

One converts from the recieved string into an object that is stored in a Record. So you may want to store a Date object in one of the fields, or even convert into an object of your own type.

Then there's a renderer which converts an object stored in a Record to human readable format.

Jack, perhaps the "convert" method should be passed a little more contextual information. Maybe a field's value must be computed using several other fields, in which case it could be useful to be able to examine the Record (of course one must define the fields in the right order to do this):



v = f.convert(v, this);

[SteveEisner]

Actually I want to try to bring more attention to this point...

Yes "renderers" and "converters" are different, and that's fine, they serve different purposes. But it points out a bigger inconsistency: the difference between form fields and grid cells.

I don't see any reason why the fields in a grid or the fields in a form should be forced to have different behaviors:
* Both should be able to use a renderer (not a converter) to display their value in whatever format you want, without having to *store* it in that format
* Both should be able to use a converter to retrieve their value from a record (-and- to put it back into the form)
* Fields can currently be used as cell editors. But forms should also be able to have the same kind of rapid-display "not interactive until you click it / tab onto it" behaviors that cells do.

Anyway, there's a lot that's already similar between Grids and forms and I hope to see them become more similar in 2.0 and beyond.

Ideally I would be able to write a set of interfaces that handle Grid editing, and then have it apply exactly to a "list of forms". I'm working on this but it's been very challenging due to the slight mismatches...

Steve

[Animal]

Yes, there are definitel parallels that could be explored. A Grid row is just a side-by-side Form, and a Form is just a Grid row layed out over mulitple lines.