cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)
Date Thu, 01 Apr 2004 09:35:55 GMT

Tim Larson wrote:

> On Wed, Mar 31, 2004 at 12:38:44PM +0200, Marc Portier wrote:
>>Sylvain Wallez wrote:
>>>Marc Portier wrote:
>>>>><wd:choice id="some-id">
>>>>><wd:field id="field-A".../>
>>>>><wd:case id="case-0" expr="case-1-expression">
>>>>>  <wd:ref id="field-A"/>
> We could think of defining widgets inside a case as being merely
> a syntactic shorthand for defining these widgets directly in the
> choice and then referencing them into that case. This shortcut
> may only be used on widgets which are only used by one case.
> In other words, do not think of cases as widgets or containers,
> but only as parts of the control structure syntax. This removes
> the problem of having two reference paths to a widget.


>>>>hm, I think Tim and I were still thinking about not having the choice 
>>>>actually contain it's widgets... (I have to say I'm still doubthing, 
>>>>but don't see it yet)
> The motivation behind this was to ease the process of evolving a
> simple widget or collection of widgets into a choice of widgets.
> If the widgets listed "in" the choice are referenced by widget-id
> rather than by choice-id.widget-id then the existing templates
> and bindings could continue to work unmodified to ease the
> incremental process of development.

ah, didn't get that, my original motivation was actually 
negative-motivation: I couldn't see a reason to complicate things, but 
when starting the talk with sylvain I realized the container-child 
relation and find the effect on the request-parameter quite logic

as foir templating: I guess the existing ft:widget elements don't need 
to be changed, but rather wrapped inside a ft:choice/ft:case structure?

in any case I find it logic that the change in the model would have an 
impact on the styling...

> Besides making the implementation of choice more complicated,
> this plan may not work out anyway. I will be examining use cases
> tomorrow to see if there is actually any merit in this design,
> but wanted to at least let you know the motivations right now
> since we have a such a big timezone difference between when your
> day starts and when mine does.

ok, staying tuned over here for when the sun comes up again :-)

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message