Woody dynamic widgets

[Timothy Larson <ti...@yahoo.com>]

I am using Woody to try to make a form and report design gui.
It seems that some type of dynamic form is required to do this
well.  If anybody has an alternate suggestion, I'm all ears.

With woody there is a form model which is like a class, and
there are form instances which are like objects.  To make the
widgets dynamic we could:

1) Show and hide always-present widgets to simulate dynamic
addition and removal of widgets.  This is pretty limiting and
wastes processing and network bandwidth.

2) Create a new form model and instance and copy the data to
it every time a widget (or group of widgets) is added or removed.
This wastes server memory and feels very hacky, but could be
implemented pretty quickly.

3) Allow the definitions for dynamic widgets to reside in the
form instance, possibly referencing a fragment of the form model.
This seems the cleanest, but also the most work.  It could
eventually be driven by some sort of schema, allowing the forms
to still be defined primarily declaratively.

What do you think? Should I get a seatbelt before I fall off my rocker?
--Tim Larson


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: Woody dynamic widgets

[Bruno Dumon <br...@outerthought.org>]

On Thu, 2003-08-28 at 20:54, Timothy Larson wrote:
> I am using Woody to try to make a form and report design gui.
> It seems that some type of dynamic form is required to do this
> well.  If anybody has an alternate suggestion, I'm all ears.
> 
> With woody there is a form model which is like a class, and
> there are form instances which are like objects.  To make the
> widgets dynamic we could:
> 
> 1) Show and hide always-present widgets to simulate dynamic
> addition and removal of widgets.  This is pretty limiting and
> wastes processing and network bandwidth.
> 
> 2) Create a new form model and instance and copy the data to
> it every time a widget (or group of widgets) is added or removed.
> This wastes server memory and feels very hacky, but could be
> implemented pretty quickly.
> 
> 3) Allow the definitions for dynamic widgets to reside in the
> form instance, possibly referencing a fragment of the form model.
> This seems the cleanest, but also the most work.  It could
> eventually be driven by some sort of schema, allowing the forms
> to still be defined primarily declaratively.
> 
> What do you think?

I think it would basically come down to making the addWidget() method of
the Form class public, so that new widgets can be added at runtime.

Of course the question then remains how these widgets can be created.
Basically they can be any object implementing the Widget interface (so
they don't need to be backed by WidgetDefinitions), but you'll probably
want to reuse the existing widgets such as Field. This means you'll
first have to create a FieldDefinition object and then call
createInstance() on it.

Currently the FieldDefinitions (or other *Definitions) are created by
builders which create them based on an XML description (DOM-fragment).
If this fits you well, then it would be easy to add a method to the
FormManager to create individual widgets from an XML-file (after all, a
Form is just another widget). If on the other hand you'd like to create
them completely programmatically, then I'd still have to look somewhat
futher...

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org