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

Marc Portier wrote:

>
>
> Sylvain Wallez wrote:
>
> <snip />
>
>> I made some comments in the wiki (but continuing here seems better to 
>
>
> yep, I just saw that, and was already typing :-)
>
>> 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.
>>
>
> actually, your last paragraph shows you did get the point
> (in the end :-))
>
> here is the history I was typing up for you:
>
> Sylvain,
> I think we have evolved a radically different view of what wd:import 
> was doing
>
> In the current setup it would not be a widget, hence no id, no 
> container of other widgets.
>
> actually all this started when during a discussion (we had a number of 
> those, quite long-winding ones in nov-dec-jan? on the list here)
>
> Tim and I started seeing that the current 'class' and 'new' widgets 
> ARE NO REAL WIDGETS (as in 'instances' mapping to request params, what 
> disguised them was the way how they abused the @id in a totally 
> different way then the other widgets)
>
> In any case we decided that this define-reuse feature-set is in fact a 
> different aspect then the form-build-up aspect...
> We concluded that attributes @define and @extend would be better 
> suited to that purpose
> Reserving @id for those cases were we actually want to instantiate and 
> thus reserve a request-parameter id.
>
> Once we were there we had actually created a local space in which the 
> locally @define were reusable with a @extend.  We had created a local 
> repository of widgets... so naturally came the solution for external 
> repositories


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.

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

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

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

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.

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?

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

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

> 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 :-)

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

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

Sylvain

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