Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <406938C7.1000605@outerthought.org>
Date: Tue, 30 Mar 2004 11:07:19 +0200
From: Marc Portier <mpo@outerthought.org>
Organization: Outerthought
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
 WoodyScratchpad Mon Mar 29 21:00:04 2004)
References: <200403291900.i2TJ04O23146@otsrv1.iic.ugent.be>
In-Reply-To: <200403291900.i2TJ04O23146@otsrv1.iic.ugent.be>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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