cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject CForms "static final" widget definitions
Date Fri, 13 Feb 2004 18:53:59 GMT
I would like to make the WidgetDefinition objects
be "static final", so the compiler can help us
respect the definitions by preventing us from
changing them in ways that are not thread-safe.

There is an issue, however, with recursive forms.
An example of a recursive form is the sample "Form
Model GUI" at http://localhost:8888/samples/woody/
For this type of form, the widget definitions form
a cyclic graph instead of a tree of definitions.
This makes "static final" definitions harder to
create, because there are some widget definitions
where both definition objects must be created
before either object can finish initiallizing its
list of child definitions.

Working with Marc before his vacation and with
Antonio a couple of days ago we have designed a
solution.  The "assistant" concept in the binding
can be adapted for use with the form model.
Please see the Assistant inner class in the file
JXPathBindingManager.java to see what I am talking
about.

The DefaultFormManager would have its own Assistant
inner class and an instance of it would be passed to
the definition builder classes.  The builder
classes would then call methods on the Assistant
object to setup the current context and then pass
the Assistant object to the constructor method of
the WidgetDefinition being built.

The definition's constructor calls the Assistant's
"WidgetDefinition[] getChildDefinitions()" method
to have the child definitions transparently either
built or looked up in the cache, without needing
to know what builder objects are responsible,
because the lookup of the builder objects and the
tracking of the context for the builder objects
is hidden behind the generic Assistant interface.

Another issue with "static final" definitions is
that all of the configuration information must
be passed to the definition's constructor, rather
than be setup by later calls to the definition's
methods.

Several options for passing the config data:
  As a Map (my personal preference):
    WidgetDefinition definition =
        new SomeWidgetDefinition(map, assistant);
  Via the assistant:
    assistant.setConfig(map);
    WidgetDefinition definition =
        new SomeWidgetDefinition(assistant);
  Separate parameters:
    WidgetDefinition definition =
        new SomeWidgetDefinition(
            foo, bar, baz, assistant);

WDYT?
--Tim Larson

Mime
View raw message