cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: [RT] Woody dynamic widgets design
Date Thu, 11 Sep 2003 21:46:52 GMT
On Thu, 2003-09-11 at 22:32, Timothy Larson wrote:
> --- Bruno Dumon <bruno@outerthought.org> wrote:
> > a first quick reaction (the rest will be for tomorrow, have to leave
> > now): what exactly should be understood here with "dynamic"?
> > 
> > AFAIU the wd:union is a sort of switch which allows to programatically
> > enable a set of widgets.
> 
> The wd:union "switch" can default to having no child widgets and later
> switch to various sets of child widgets.  Constrained only by the list of
> cases in the union, you can dynamically decide which widgets to create
> and when to create them.  If you keep choosing to create sets of widgets
> which include union widgets, then you are giving yourself the option grow
> the widget tree as large as you like.

Aha, now I get it. It's much better than I thought ;-)

And you're probably going to use this in combination with a repeater to
get a repeating structure which can contain different sets of widgets on
each row?

> > 
> > However, I thought in earlier mails you were also implying to
> > dynamically add new widgets (possibly with dynamically created widget
> > definitions) to form instances. Or does the wd:union solve all your
> > use-cases?
> 
> I prefer to direct processes with data instead of code because data is
> is easier to manipulate.

yep, and that's a good decission. After all, the woody form definition
is a sort of schema language, and by doing things this way everything
remains described in the schema. (this also gives woody form definitions
similar power to xml schemas with their sequence/choice combo)

>   The dynamically created widget definitions
> were intended as a shortcut before I came up with this design.  BTW, the
> idea of reusing groups of widget and template definitions was inspired
> by Marc's comments on the xReporter list [1].  I hope I did not mangle
> his idea too much.

That doesn't matter; I find it great how people sometimes come up with
clever ideas by misunderstanding someone else suggestions. (though I
don't know if that was the case here)


To touch some of the other topics in your previous mail:

* If I understand it right the wd:widgets/wd:include functionality is
quite orthogonal to the wd:union proposal? I.e. the one does not really
have to do with the other? (just to know that I understood it right)

* On the aggregation: it would be nice if we could keep the current
functionality of storing filename/linumber information on each node in
the configuration DOM-tree, so that error messages can point to the
exact source locations. This would require doing the aggregation on the
DOM-tree rather than in a Cocoon pipeline. I'm willing to help out on
this if needed.

* on the xpath-addressing: could you give a concrete example of when
it's needed?

BTW, this is all very good stuff you're coming up with here!

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


Mime
View raw message