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
Tim and I once discussed the @define and @extend on IRC (which resulted in the wiki scratchpad page), but there was no repository at that time.
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?
Yep, and I totally agree with this. Having a hierarchy of types would lead to a complicated mess from a user point of view. Also, my remark on nested repositories is finally non-sense. A repository only publishes the types it defines, even if these types extend types defined by another repository. Repository import is not a transitive relation.
So +1 for @prefix and namespaced notation, as types and widget ids leave in different spaces.
Now for type repositories to be real repositories, there's something missing in the samples: we should be able to define a type without defining a widget. In other words, it should be legal to have no @id if there is a @defines, e.g:
<wd:field defines-type="date-field"> <wd:datatype base="date"/> </wd:field>
This has the effect of declaring the type, but not producing any actual widget in the parent container (be it a form or a repository).
<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)
Mmmh... are you stating that wd:choice doesn't contain its widgets? Or do you mean wd:case?
The problem we have to solve with wd:choice is that there can be some widgets that are common to different cases. But IMO a wd:choice should not reference widgets that are its siblings, but *contain* them. wd:choice is a container.
Now the question is whether a wd:case can define its own widgets (i.e. it is a container, child of the wd:choice) or if if can only reference widgets defined in wd:choice (and therefore represent the "value" of the wd:choice).
References are needed in a wd:case since we need widgets common to different cases.
Widgets in a wd:case implicitely turns them into container, leading to the dual path I outlined above. Thinking further, this overcomplexifies the widget containment. Also, a wd:case can be considered as the "value" of the wd:choice, driving, as you point out below, the list of available children in the wd:choice.
So, here's a sum up of my (current) opinion: wd:choice is a container whose children are the widgets for all cases, and wd:case only define test expressions that decide the available children of the wd:choice and its "value", that can be used later on in the template.
How does this sound?
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...
Mmmh..., IMO this will be "some-id.field-A", and there should *not* be a parameter driving the choice. It's the result of the server-side evaluation of the test expressions. Otherwise, we're open to consistency problems and hacked requests.
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
Yep. The wd:case defines the "value" of the wd:choice.
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.
Agree.
(hm, the last paragraph does sound like there is some parent-child/containment that justifies the nested request-param...)
Yes :-)
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?
This isn't sufficient, as the view may want to produce different layouts or informative text depending on the chosen case.
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?
Yes, definitely yes. I started using the generator approach a while ago (with JXTemplate macros) because I needed:
- different renderings for empty/non-empty repeaters (don't want a table with just headers if it's empty)
- a very special rendering for a wd:output containing the ID of a node in a tree structure (the rendering shows the full path of the node, a la dmoz.org, with i18nized node labels)
- conditional blocks depending on a widget's value (actually a poor man's wd:choice)
These features are impossible to achieve with a transformer, but are really easy with a generator.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
