Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <406A9FB4.9090107@outerthought.org>
Date: Wed, 31 Mar 2004 12:38:44 +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: 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> <4069E5A2.8030302@apache.org>
 <4069EE3D.2040201@outerthought.org> <406A83F3.7050105@apache.org>
In-Reply-To: <406A83F3.7050105@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Sylvain Wallez wrote:

> Marc Portier wrote:
> 

<snip />

> 
> Tim and I once discussed the @define and @extend on IRC (which resulted 
> in the wiki scratchpad page), but there was no repository at that time.
> 

that part of history I didn't know...

>> so here goes the idea:
>> each cforms defintion file can @define reusable definition-templates
>> and to reuse them in a different file you would need to refer to it in 
>> some way, hence the prefix idea
>>
>> from there I saw the resemblance to how xmlns binds a prefix to a uri, 
>> and tzadaam
>>
>> I think this confirms your fresh understanding, right?
> 
> 
> 
> Yep, and I totally agree with this. Having a hierarchy of types would 
> lead to a complicated mess from a user point of view. Also, my remark on 
> nested repositories is finally non-sense. A repository only publishes 
> the types it defines, even if these types extend types defined by 
> another repository. Repository import is not a transitive relation.
> 
> So +1 for @prefix and namespaced notation, as types and widget ids leave 
> in different spaces.
> 

yep, that was the feeling

> Now for type repositories to be real repositories, there's something 
> missing in the samples: we should be able to define a type without 
> defining a widget. In other words, it should be legal to have no @id if 
> there is a @defines, e.g:
> 
> <wd:field defines-type="date-field">
>  <wd:datatype base="date"/>
> </wd:field>
> 
> This has the effect of declaring the type, but not producing any actual 
> widget in the parent container (be it a form or a repository).
> 

it's already there Sylvain: sample2 on the scratchpad page

>> <snip />
>>
>>> "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".
>>>
>>
>> hm, I think Tim and I were still thinking about not having the choice 
>> actually contain it's widgets... (I have to say I'm still doubthing, 
>> but don't see it yet)
> 
> 
> 
> Mmmh... are you stating that wd:choice doesn't contain its widgets? Or 
> do you mean wd:case?
> 

I _was_ making a statement on wd:choice, but you convinced me: choice is 
a container, requestparams should be nested choiceID.childID

> The problem we have to solve with wd:choice is that there can be some 
> widgets that are common to different cases. But IMO a wd:choice should 
> not reference widgets that are its siblings, but *contain* them. 
> wd:choice is a container.
> 
> Now the question is whether a wd:case can define its own widgets (i.e. 
> it is a container, child of the wd:choice) or if if can only reference 
> widgets defined in wd:choice (and therefore represent the "value" of the 
> wd:choice).
> 
> References are needed in a wd:case since we need widgets common to 
> different cases.
> 
> Widgets in a wd:case implicitely turns them into container, leading to 
> the dual path I outlined above. Thinking further, this overcomplexifies 
> the widget containment. Also, a wd:case can be considered as the "value" 
> of the wd:choice, driving, as you point out below, the list of available 
> children in the wd:choice.
> 

yes, but I think there is two things, though

as I see it the 'choice' has a value that can be set
(either by a request carrying its value, or by eventhandling code)

setting of that value will lead to the cases to be re-evaluated
the chosen case (internall processing to the choice class) does two things:
- 1/ describe which child-widgets need to be instantiated
- 2/ set some 'choice-label' where the template-transformer can react upon?

as I see it that last one != the actual 'value'

in any case, the wd:case are not to be seen as containers nor widgets 
(they should thus not have an @id)

> So, here's a sum up of my (current) opinion: wd:choice is a container 
> whose children are the widgets for all cases, and wd:case only define 
> test expressions that decide the available children of the wd:choice and 
> its "value", that can be used later on in the template.
> 
> How does this sound?
> 

matches my understanding indeed

>> i.e. the request-param in my head would just be 'field-A', there is 
>> however also a 'some-id' request param to communicate the value that 
>> will drive the choice...
> 
> 
> 
> Mmmh..., IMO this will be "some-id.field-A", and there should *not* be a 
> parameter driving the choice. It's the result of the server-side 
> evaluation of the test expressions. Otherwise, we're open to consistency 
> problems and hacked requests.
> 

hm, didn't think about that, but in the cases where you have a very 
clear link between a widget and the choice to make this means that 
people will need to add an explicit widget to their definition

in my head that would be a styling aspect: the template would choose if 
its on the form or not

have to think about the hacking though, what could go wrong?

>> also, I don't know if there are to be two paths into the beast: point 
>> being that the 'case' part is IMHO not to be a separate 
>> widget-definition class, but rather a part of the 
>> configuration/processing context of the widget
> 
> 
> 
> Yep. The wd:case defines the "value" of the wd:choice.
> 

see above, I don't think it needs to be matching the 'value', I think 
it's something else (that's probably how I avoid the hacking issue?)

>> in other words: when asking a choice-widget which children it has, it 
>> would just list the currently 'chosen' widgets, and not the nested cases.
> 
> 
> 
> Agree.
> 
>> (hm, the last paragraph does sound like there is some 
>> parent-child/containment that justifies the nested request-param...)
> 
> 
> 
> Yes :-)
> 

thx for shedding the light :-)

>>> Case id's are also important because they will be used in views to 
>>> select which part of the template is to be displayed.
>>
>>
>>
>> not sure here, couldn't the template just react on those widgets that 
>> seem to have been 'chosen' at the time?
> 
> 
> 
> This isn't sufficient, as the view may want to produce different layouts 
> or informative text depending on the chosen case.
> 

yeah, you're right the selected case should set some 'choice-label' oinm 
which the template can react

>> from a styling POV you'll probably have a custom style surounding each 
>> of the possible children, and maybe other arrangements depending on 
>> the mix of available widgets... so reacting on the mix seems more 
>> sensible then duplicating the decision logic in the template, no?
>>
>> in any case, looking at the use-case behind these, I tend to believe 
>> that a generator approach is more natural, no?
> 
> 
> 
> Yes, definitely yes. I started using the generator approach a while ago 
> (with JXTemplate macros) because I needed:
> - different renderings for empty/non-empty repeaters (don't want a table 
> with just headers if it's empty)
> - a very special rendering for a wd:output containing the ID of a node 
> in a tree structure (the rendering shows the full path of the node, a la 
> dmoz.org, with i18nized node labels)
> - conditional blocks depending on a widget's value (actually a poor 
> man's wd:choice)
> 
> These features are impossible to achieve with a transformer, but are 
> really easy with a generator.
> 

yep, revisiting the generator is also somewhere on my todo list

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