Sylvain Wallez wrote:
Marc Portier wrote:
<snip />
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.
that part of history I didn't know...
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.
yep, that was the feeling
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).
it's already there Sylvain: sample2 on the scratchpad page
<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?
I _was_ making a statement on wd:choice, but you convinced me: choice is a container, requestparams should be nested choiceID.childID
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.
yes, but I think there is two things, though
as I see it the 'choice' has a value that can be set (either by a request carrying its value, or by eventhandling code)
setting of that value will lead to the cases to be re-evaluated the chosen case (internall processing to the choice class) does two things: - 1/ describe which child-widgets need to be instantiated - 2/ set some 'choice-label' where the template-transformer can react upon?
as I see it that last one != the actual 'value'
in any case, the wd:case are not to be seen as containers nor widgets (they should thus not have an @id)
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?
matches my understanding indeed
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.
hm, didn't think about that, but in the cases where you have a very clear link between a widget and the choice to make this means that people will need to add an explicit widget to their definition
in my head that would be a styling aspect: the template would choose if its on the form or not
have to think about the hacking though, what could go wrong?
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.
see above, I don't think it needs to be matching the 'value', I think it's something else (that's probably how I avoid the hacking issue?)
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 :-)
thx for shedding the light :-)
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.
yeah, you're right the selected case should set some 'choice-label' oinm which the template can react
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.
yep, revisiting the generator is also somewhere on my todo list
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]
