Since this starts looking like a consensus-reaching discussion I'm pulling it to the dev list
others that want to join in, be sure to read up:
Page: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad , version: 12 on Sun Mar 29 19:17:58 2004 by 65.116.199.19
+ (tim: +1 to this alternative; nice syntax, and conveys the right ideas more clearly.)
+
Tim, thx for this feedback, ok if I swap it over the previous section then?
I made some comments in the wiki (but continuing here seems better to 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.
- - This would also stress nicely that prefixes only have local scope, that the sources are the real important things, and that the form-manger could cache these repositories based on the source.
+ This would also stress nicely that prefixes only have local scope, that the sources are the real important things, and that the form-manger could cache these repositories based on the source. (tim: +1 the pre-built definition caching is one of the reasons for importing instead of just using (x|c)include)
? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- **Anywhere a widget definition is allowed. (+1 mpo) + **Anywhere a widget definition is allowed. (+1 mpo, +1 tim) ? ++++++++
- *Where should imported types be registered (affects namespace)? (mpo: I don't get this question)
+ *Where should imported types be registered (affects namespace)? (mpo: I don't get this question) (tim: let's ignore it, I don't think it makes sense anymore.)
? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ok
- **Widget definitions that will have instances created.
+ **Widget definitions that will have instances created. (tim: Does this have any usecases?)
? ++++++++++++++++++++++++++++++++++++
not that I know of, in fact I couldn't really place that one either :-(
+ (''tim: I was thinking of offering both forms, not just one-or-the-other, because I have usecases for both.'')
ah, wasn't clear, I like the idea, just have to make the syntax clear then
- *What should we do if the expression evaluates to the default anyway? (mpo: seems more logic in the [EMAIL PROTECTED]/otherwise filosophy?)
+ *What should we do if the expression evaluates to the default anyway? (mpo: seems more logic in the [EMAIL PROTECTED]/otherwise filosophy?) (tim: I do not understand; could you clarify you comment?)
? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
in the when/@test and otherwise there is no real expression to be evaulated, just a last section that is always true if none of the above was...
- *What namespace should the widget id's be in? (''mpo: supposing you refer to namespacing with respect to generated request-parameter names, right?'')
+ *What namespace should the widget id's be in? (''mpo: supposing you refer to namespacing with respect to generated request-parameter names, right?'') (''tim: yes'')
? +++++++++++++++
I'll rephrase our dialog as an extra clarification then
- ''mpo comments: I would prefer the case/@expr and default to become when/@test and otherwise''
+ ''mpo comments: I would prefer the case/@expr and default to become when/@test and otherwise''//
? ++
+ ''tim comments: when/@test would be fine with me; should we also copy the word 'choose' from xslt, instead of using 'choice'? 'choice' seems more declarative, but I would be ok with either word.''
choose points at processing and doing the action choice makes it an entity
the latter seems to hint that there is actually a widget with its own value to be used for driving the choice?
"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".
Case id's are also important because they will be used in views to select which part of the template is to be displayed.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
