--- Bruno Dumon <[EMAIL PROTECTED]> 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 http://sitebuilder.yahoo.com
