Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4069E5A2.8030302@apache.org>
Date: Tue, 30 Mar 2004 23:24:50 +0200
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
 WoodyScratchpad Mon Mar 29 21:00:04 2004)
References: <200403291900.i2TJ04O23146@otsrv1.iic.ugent.be>
 <406938C7.1000605@outerthought.org>
In-Reply-To: <406938C7.1000605@outerthought.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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?


I made some comments in the wiki (but continuing here seems better to 
me). I don't like much this namespace-like syntax, especially if a 
<wd:import> can appear everywhere in a definition file.

Also, the "extends" attribute will require a notation to crawl up the 
ancestors, as e.g. a widget inside a repeater can extend a type defined 
outside the repeater.

Or did I miss the point and the type scope is different from the widget 
scope, meaning we have a flat type space (globally unique names 
throughout a definition file) whereas the widget space is hierarchical 
(unique among siblings)? In that case (and I prefer this solution), then 
yes, a namespace-like syntax makes sense.

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


"choice" is better, as it *is* a widget. It's a container widget with an 
id (therefore defining a scope) and no value.

This container can have two kinds of children:
- regular widgets that are referenced by the "case" and are therefore 
common to several cases,
- "case" widgets that are in turn container for regular widgets and 
references for the above common widgets.

This leads to the interesting fact that common widgets can actually be 
referenced by two names: one considering only their definition, and one 
considering their reference in a case.

Example:

<wd:choice id="some-id">
  <wd:field id="field-A".../>
  <wd:case id="case-0" expr="case-1-expression">
    <wd:ref id="field-A"/>
  </wd:case>
</wd:choice>

field-A can be referenced using "some-id.field-A" (don't care about the 
actual case) and "some-id.case-o.field-A". It's canonical name (used in 
request parameters) will be of course "some-id.field-A".

Case id's are also important because they will be used in views to 
select which part of the template is to be displayed.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }