Splitting out single and list into separate form widgets

[Scott Gray-2]

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?

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

[Adrian Crum]

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.

While we're at it, could we separate the styling into a separate element
and Java class? Chris Howe had suggested that some years ago.

-Adrian

[Scott Gray-2]

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.
>
> While we're at it, could we separate the styling into a separate element and Java class? Chris Howe had suggested that some years ago.

I'm not entirely sure what you mean on this one?  Could you give me an example of what the problem is and how this would solve it?

[Bob Morley]

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.  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.

[Adrian Crum-2]

--- On Mon, 5/3/10, Scott Gray <[hidden email]> 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.
> >
> > While we're at it, could we separate the styling into
> a separate element and Java class? Chris Howe had suggested
> that some years ago.
>
> I'm not entirely sure what you mean on this one? 
> Could you give me an example of what the problem is and how
> this would solve it?

I think it was around the beginning of 2007. The idea was to move all of the form widget styling attributes to a style element - to cut down on the amount of form attributes. We made a preliminary move in that direction by putting all of the form styling attributes on their own line - so that later they could be contained in a separate element.

-Adrian

[Adrian Crum-2]

--- On Mon, 5/3/10, Adrian Crum <[hidden email]> wrote:

> --- On Mon, 5/3/10, Scott Gray <[hidden email]>
> 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.
> > >
> > > While we're at it, could we separate the styling
> into
> > a separate element and Java class? Chris Howe had
> suggested
> > that some years ago.
> >
> > I'm not entirely sure what you mean on this one? 
> > Could you give me an example of what the problem is
> and how
> > this would solve it?
>
> I think it was around the beginning of 2007. The idea was
> to move all of the form widget styling attributes to a style
> element - to cut down on the amount of form attributes. We
> made a preliminary move in that direction by putting all of
> the form styling attributes on their own line - so that
> later they could be contained in a separate element.

I can't find the ml discussion, but here is the related Jira issue:

https://issues.apache.org/jira/browse/OFBIZ-760

-Adrian

[Scott Gray-2]

On 4/05/2010, at 4:23 PM, Adrian Crum wrote:

> --- On Mon, 5/3/10, Adrian Crum <[hidden email]> wrote:
>> --- On Mon, 5/3/10, Scott Gray <[hidden email]>
>> 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.
>>>>
>>>> While we're at it, could we separate the styling
>> into
>>> a separate element and Java class? Chris Howe had
>> suggested
>>> that some years ago.
>>>
>>> I'm not entirely sure what you mean on this one?
>>> Could you give me an example of what the problem is
>> and how
>>> this would solve it?
>>
>> I think it was around the beginning of 2007. The idea was
>> to move all of the form widget styling attributes to a style
>> element - to cut down on the amount of form attributes. We
>> made a preliminary move in that direction by putting all of
>> the form styling attributes on their own line - so that
>> later they could be contained in a separate element.
>
> I can't find the ml discussion, but here is the related Jira issue:
>
> https://issues.apache.org/jira/browse/OFBIZ-760
>
> -Adrian

Okay thanks, I see what you mean now.  I'll stew on it for a bit and see what I can add to the discussion.

Regards
Scott

[Adrian Crum-2]

--- On Mon, 5/3/10, Scott Gray <[hidden email]> wrote:

> On 4/05/2010, at 4:23 PM, Adrian Crum
> wrote:
>
> > --- On Mon, 5/3/10, Adrian Crum <[hidden email]>
> wrote:
> >> --- On Mon, 5/3/10, Scott Gray <[hidden email]>
> >> 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.
> >>>>
> >>>> While we're at it, could we separate the
> styling
> >> into
> >>> a separate element and Java class? Chris Howe
> had
> >> suggested
> >>> that some years ago.
> >>>
> >>> I'm not entirely sure what you mean on this
> one?
> >>> Could you give me an example of what the
> problem is
> >> and how
> >>> this would solve it?
> >>
> >> I think it was around the beginning of 2007. The
> idea was
> >> to move all of the form widget styling attributes
> to a style
> >> element - to cut down on the amount of form
> attributes. We
> >> made a preliminary move in that direction by
> putting all of
> >> the form styling attributes on their own line - so
> that
> >> later they could be contained in a separate
> element.
> >
> > I can't find the ml discussion, but here is the
> related Jira issue:
> >
> > https://issues.apache.org/jira/browse/OFBIZ-760
> >
> > -Adrian
>
> Okay thanks, I see what you mean now.  I'll stew on it
> for a bit and see what I can add to the discussion.

There is a chance it isn't needed any more. The problem 3 years ago was that there was a form attribute to style nearly every element in the form. I introduced the concept of having a container CSS class that would style the form and all of its child elements (using descendant selectors). After that the effort to move styling to a separate element fizzled out. I don't know if that was due to lack of interest or the new container method of styling.

-Adrian

[Scott Gray-2]

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

[Harmeet Bedi]

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 <[hidden email]>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

[Adrian Crum]

It would be nice if all of the screen widgets used a factory method, and
the widget factory allowed user-defined widgets to be registered with
the factory. Then you could develop your own screen widgets and use them
without having to touch the framework code.

-Adrian

On 5/6/2010 11:24 AM, Harmeet Bedi wrote:

> 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<[hidden email]>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
>