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<scott.g...@hotwaxmedia.com>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
