cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.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 18:48:40 GMT


Tim Larson wrote:

<snip/>

>>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.
> 

ok, still have to though

<snip />

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

nope you got me allright
we just have to find a good syntax for them both, right?
proposing here and now:

switch-like:
<fb:choice expression="">
<fb:when result="">
<fb:otherwise>

ifelseif-like
<fb:choice>
<fb:when test="">
<fb:otherwise>

wdyt?

<snip />

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

another still todo

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

thx for clarifying again, this is how I (thought I) remembered the 
discussion (been some time)

I'm ok either way, only slightly favouring the noun.

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