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 Tue, 30 Mar 2004 22:01:33 GMT

Sylvain Wallez wrote:

<snip />

> I made some comments in the wiki (but continuing here seems better to 

yep, I just saw that, and was already typing :-)

> me). I don't like much this namespace-like syntax, especially if a 
> <wd:import> can appear everywhere in a definition file.
> Also, the "extends" attribute will require a notation to crawl up the 
> ancestors, as e.g. a widget inside a repeater can extend a type defined 
> outside the repeater.
> Or did I miss the point and the type scope is different from the widget 
> scope, meaning we have a flat type space (globally unique names 
> throughout a definition file) whereas the widget space is hierarchical 
> (unique among siblings)? In that case (and I prefer this solution), then 
> yes, a namespace-like syntax makes sense.

actually, your last paragraph shows you did get the point
(in the end :-))

here is the history I was typing up for you:

I think we have evolved a radically different view of what wd:import was 

In the current setup it would not be a widget, hence no id, no container 
of other widgets.

actually all this started when during a discussion (we had a number of 
those, quite long-winding ones in nov-dec-jan? on the list here)

Tim and I started seeing that the current 'class' and 'new' widgets ARE 
NO REAL WIDGETS (as in 'instances' mapping to request params, what 
disguised them was the way how they abused the @id in a totally 
different way then the other widgets)

In any case we decided that this define-reuse feature-set is in fact a 
different aspect then the form-build-up aspect...
We concluded that attributes @define and @extend would be better suited 
to that purpose
Reserving @id for those cases were we actually want to instantiate and 
thus reserve a request-parameter id.

Once we were there we had actually created a local space in which the 
locally @define were reusable with a @extend.  We had created a local 
repository of widgets... so naturally came the solution for external 

so here goes the idea:
each cforms defintion file can @define reusable definition-templates
and to reuse them in a different file you would need to refer to it in 
some way, hence the prefix idea

from there I saw the resemblance to how xmlns binds a prefix to a uri, 
and tzadaam

I think this confirms your fresh understanding, right?

<snip />

> "choice" is better, as it *is* a widget. It's a container widget with an 
> id (therefore defining a scope) and no value.
> This container can have two kinds of children:
> - regular widgets that are referenced by the "case" and are therefore 
> common to several cases,
> - "case" widgets that are in turn container for regular widgets and 
> references for the above common widgets.
> This leads to the interesting fact that common widgets can actually be 
> referenced by two names: one considering only their definition, and one 
> considering their reference in a case.
> Example:
> <wd:choice id="some-id">
>  <wd:field id="field-A".../>
>  <wd:case id="case-0" expr="case-1-expression">
>    <wd:ref id="field-A"/>
>  </wd:case>
> </wd:choice>
> field-A can be referenced using "some-id.field-A" (don't care about the 
> actual case) and "". It's canonical name (used in 
> request parameters) will be of course "some-id.field-A".

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)

i.e. the request-param in my head would just be 'field-A', there is 
however also a 'some-id' request param to communicate the value that 
will drive the choice...

also, I don't know if there are to be two paths into the beast: point 
being that the 'case' part is IMHO not to be a separate 
widget-definition class, but rather a part of the 
configuration/processing context of the widget

in other words: when asking a choice-widget which children it has, it 
would just list the currently 'chosen' widgets, and not the nested cases.

(hm, the last paragraph does sound like there is some 
parent-child/containment that justifies the nested request-param...)

> Case id's are also important because they will be used in views to 
> select which part of the template is to be displayed.

not sure here, couldn't the template just react on those widgets that 
seem to have been 'chosen' at the time?

from a styling POV you'll probably have a custom style surounding each 
of the possible children, and maybe other arrangements depending on the 
mix of available widgets... so reacting on the mix seems more sensible 
then duplicating the decision logic in the template, no?

in any case, looking at the use-case behind these, I tend to believe 
that a generator approach is more natural, no?

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

View raw message