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:
Sylvain,
I think we have evolved a radically different view of what wd:import was doing
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 repositories
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 "some-id.case-o.field-A". 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?
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
