cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)
Date Tue, 30 Mar 2004 09:07:19 GMT
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?

> - 
> - 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 when@test/otherwise filosophy?)
> + *What should we do if the expression evaluates to the default anyway? (mpo: seems more
logic in the when@test/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/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message