cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)
Date Tue, 30 Mar 2004 17:52:56 GMT
On Tue, Mar 30, 2004 at 11:07:19AM +0200, Marc Portier wrote:
> 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?

Yes, please do.  I am not interested in saving the comments (wiki
history will do that for us), just in hammering out the best design.

> >+ 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)
> 
> >+ (''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

Yes, any suggestions for the "c switch"-like syntax? Or do you just mean
that the explaination needs to be more understandable?

> >+ *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 your 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...

Thinking clearer now, the original question did not make sense. Skipping.

> >+ *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

Thanks.

> >+ ''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?

There will be an actual widget, because we have to store the previous
choice to be able to tell if the new choice is different and thus
requires action, such as creating the associated widgets.  This will
also solve the early validation problem the union widget introduced to
the field widget. By this reasoning, the name should be "choice", right?

--Tim Larson

Mime
View raw message