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?
- - 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?
(that was the case now, no? or is this just a vague memory of an unfinished discussion?)
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]
