One thing to watch for is this.. Grid whatever it is called form, formgrid etc. is still a form and i feel it is important to not loose form and field semantics for grids. The intent of type='..' attribute tells me that different type of forms (single, list/grid) are really just forms.
The best way may be see single and list as two types of forms - i.e. isa, Ideally implemented as inheritance in ModelForm and inheritance in XSD.(or contains using attribute groups) In emforium we have added attributes and extended ModelForm and ModelFormField. This has been messy as number of attributes increased.. The only mitigation being that we used naming convention of grid-* to separate grid/list like attributes. 'formgrid' and 'form' both map as form, but we use form to mean type=single and formgrid for grids. Harmeet On Tue, May 4, 2010 at 10:26 AM, Scott Gray <[email protected]>wrote: > On 4/05/2010, at 2:34 PM, Bob Morley wrote: > > > Scott Gray-2 wrote: > >> > >> On 4/05/2010, at 11:32 AM, Adrian Crum wrote: > >> > >>> On 5/3/2010 4:25 PM, Scott Gray wrote: > >>>> Sometimes I think using the same schema and class for single forms and > >>>> list forms holds us back from implementing features specific to one or > >>>> the other and even when we do it results in a messy schema. > >>>> > >>>> What if we were to separate the two but have them share a common base? > >>>> We could start by separating the schemas and then work on the code. > >>>> > >>>> Thoughts? > >>> > >>> Any effort to clean up and improve widget code gets a big thumbs-up > from > >>> me. > >> > > > > I was kind of amused by this only because it was one of the first > thoughts I > > had when I started looking at Ofbiz. > > Yeah it's been on my mind for a while (years). > > > One of the first things we wanted to > > do was implement a more functional "grid" view of a form of type list. > My > > first prototype involved creating a "ModelGrid" which extended / borrowed > > heavily from the ModelForm. ModelGrid gave some separation between > > attributes that were form related vs. ones of that were grid related -- > > things like sorting, grouping, etc come to mind. > > > > Unfortunately (in my mind), I lost the "model off" and we ended up with > > "formgrid" that contains the same elements as the "form". What has > happened > > is we have created a pile of new attributes that are only applicable to > the > > grid (and a whole lost more than are not applicable to it). Our internal > > solution right now is to name all of the former as "grid-xxx". > > > > In short, I would be very much in favor into splitting the "form" from > the > > "list"||"grid". I still have the "ModelGrid" code around if you wanted > to > > look at it. In affect, it was a peer to ModelForm but it leveraged its > > field rendering capabilities. They had their own dtd and resided in > their > > own file. So you would see PartyForms.xml and PartyGrids.xml together > ... > > > > As a side note; I think my use of "grid" was bad ... to me that really > > represents a UI representation of a list of entities; and List is really > the > > better term to use. At the time, I had extended the html renderer to > > provide an extjs implementation that gave us some nice client-side > features > > that come with that grid. > > > > Let me know if you think there is any value at seeing what I have done or > if > > you think I can help out in any way. > > Any ideas whether in english or code form are most welcome, feel free to > throw it a jira if you like. > > Chances are I won't work on this anytime soon, I just wanted to start the > conversation. > > Thanks > Scott
