cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Larson <>
Subject Re: [RT] Woody dynamic widgets design
Date Fri, 12 Sep 2003 14:53:23 GMT
--- Bruno Dumon <> wrote:
> On Thu, 2003-09-11 at 22:32, Timothy Larson wrote:
> > 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?

Yes, that's the plan.

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

Good, we are on the same page.

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

Yes, wd:widgets and wd:include are intended for general use.  The wd:union
just happens to be my first use case that requires their functionality.

I hope they will be useful for modularizing forms, and possibly be developed
along with their siblings (wt:templates/wt:include and some analog in the
binding and flowscripts) to where they can also provide a concept of subforms.

So yes, it is pretty much a separate proposal, just presented here because
the initial union use case requires it.  I could not support specifying true
recursive unions without wd:include, unless I was willing to have the widget
definition file be infinitely large.  In the implementation envisioned,
wd:include allows for "lazy evaluation" like functional programming uses.

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

Chances are I will need your help on this, thanks.

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

A first implementation does not need this, so we could postpone the
decision for later.  Here is a (wet cement) example anyway:  Say you have
a top-level, non-rendered widget that stores some state.  Way down nested
somewhere in the widget tree you want to use this state to control the
visual representation (template) selected for a widget.  How do you refer
to the top-level widget when your current context is deeply nested?

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

Thanks.  I wish I could get to the Hackathon, but the city does not have
any travel money.  These things are a lot easier to design and implement
when interacting with other programmers in person.

--Tim Larson

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

View raw message