cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] Forwarding: Explanation of "dynamic stuff in form model"
Date Fri, 09 Jan 2004 11:16:40 GMT
Tim Larson wrote:

> --- Marc Portier <> wrote:
>>Tim Larson wrote:
>>>--- Marc Portier <> wrote:
>>>>1/ to me this sounds like the use of @id on new and class was fraudulous:
>>>>what I mean is: it is abusing that field in the implementation classes, 
>>>>but with utterly different semantics:  not to be mapped onto actual 
>>>>request-parameter-names, but rather a type-def/type-ref mechanism
>>>This is all true, except for the small detail that the class id is
>>>currently occupying space in the same namespace as the regular widget
>>which seems to be more of a consequence of current approach then a goal, no?
> I think so; see "red flag" comment below.
>>>We also need to be able to distinguish between just-create-prototype
>>>versus create-widgets-and-create-prototype-at-the-same-time.
>>see my other posting... distinguishing is done by looking at the 
>>combination of present attributes
>><wd:whatever id=".." >       --> classic use, create widget
>><wd:whatever type-def=".." > --> prototype-only (ie equivalent of wrapping
with wd:class )
>><wd:whatever id=".." type-def=".." > --> create and prototype
>>so one of @type-def or @id always would need to be present
>>@id would say: give this a place in the active tree of nodes
>>@type-def would say: add this to the active registry of reusable prototypes
> This separation of widget and prototype namespaces seems good.
> Instead of letting any widget act as a prototype, only the ones
> marked with a type-def attribute are available as prototypes.
> This provides a red flag to anyone modifying the widget, alerting
> them that their changes may affect other parts of the form.

indeed, didn't even think about that extra bonus

>>>In addition, how would you handle a class containing two or more widgets?
>>>For this case I think we still need a wrapping element without namespacing.
>>>Example with current (possibly soon to be old) syntax:
>>>  <wd:class id="asdf">
>>>    <wd:widget id="qwerty"/>
>>>    <wd:widget id="zxcv"/>
>>>  </wd:class>
>>>  <wd:new id="asdf">
>>>which should be functionally equivalent to:
>>>  <wd:widget id="qwerty"/>
>>>  <wd:widget id="zxcv"/>
>>touche, but let's cheat by changing the rules of the game:
>>I don't like this feature, and I don't think you need it :-)
> I will describe below how to support the feature cheaply, and
> further down, the reasons why it is needed.
>>Here is why I don't like it
>>suppose this:
>>    <wd:class id="asdf">
>>      <wd:widget id="qwerty"/>
>>      <wd:widget id="zxcv"/>
>>    </wd:class>
>>then using this:
>>    <wd:new id="asdf">
>>    <wd:widget id="qwerty">
>>would lead to a conflict, right?
>>if we like to extend the re-use paradigm to central catalogs, then 
>>having this feature would expect me to know the internals of the 'asdf' 
>>class to make sure this doesn't happen, right?
> Quoting myself:
>>>Not good.  When reusing, currently with "new", you should not need to
>>>know or restate what type(s) of widget(s) the class contains.  I.e. we
> I am going to relax this statement from "should not need to know or
> restate" to just "should not need to restate", because if you write a
> custom template or binding for an instance of a prototype (currently
> called a "class"), then you already need to know the types and ids of
> the widgets the prototype contains.  Just like "type-def" acts as a red
> flag, informing the form designer to be careful when a widget is acting
> as a prototype, a special element (currently "new", but could be "inline",
> etc.) could be required to create an instance of one of these multi-widget
> prototypes which add their widget ids to the current namespace.
> This way there is never a question about when id clashes are possible,
> following the pattern of only having those who need the feature pay the
> costs of using the feature.

I can live with that.

(hm, added later:
below I find myself still struggling with the case you present... I 
really can live with the concept "the one using should pay the cost" and 
thus conclude to "let's support both" however the proposed use is just 
not something I would galdly recommend, sorry)

>>And I think you don't need it, it's not adding features, is it?
> I will start with some admittedly less significant arguments:
> By not introducing another layer of namespacing, we saves memory,
> processing, and network bandwidth by allowing for shorter fully
> qualified widget ids, and more importantly, save the form designer
> from having to navigate the namespace in the binding and template.
> These issues seem unimportant until we get catalogs and start to
> build up forms via composition of prototypes which are in turn
> built via composition of other prototypes...then sprinkle in a few
> repeaters to taste, and we could have some very long fully qualified
> ids to deal with.  With non-namespacing prototypes there could be
> several layers of composition in use without burdening the ids.

hm, you are right, but is indeed questionable:
- if BW becomes an issue you could still use short id's, but probably 
will be faced with the fact that it only has minor effect IMHO
- navigating the widget-tree could be resolved by adding some 
WidgetLookupHelper that parses a hierachical String to navigate the tree 
for you (much like xpath versus DOM traversal, haven't looked yet at how 
we could maybe reuse jxpath in this area)
- and catalogs? well, they should be organized well to avoid the issue :-)
note in this respect that using the 'extend' idea one _can_ add widgets 
to the base-group (meaning: inside it's namespace) so smart extension 
trees can be

(note that people doing extensions will need to know about the base 
class internals to avoid name-clashes: in any case we will need to speak 
about these extensions in more depth later on IMHO)

> Here is a more significant argument:
> It allows the set of cases (choices) in a union to be built up by
> adding a set of choices for each multi-widget prototype that is
> referenced.  Pseudocode to illustrate:
>   <union>
>     <new type-ref="prototype1"/>
>     <new type-ref="prototype2"/>
>   </union>
> could expand into this combined set of union cases:
>   <widget id="widgetA-from-prototype1"/>
>   <widget id="widgetB-from-prototype1"/>
>   <widget id="widgetC-from-prototype2"/>
>   <widget id="widgetD-from-prototype2"/>
>   <widget id="widgetE-from-prototype2"/>

and the possible clash if both prototypes would have both a 
widget/@id='F', right?

> We could not pull in *sets* of choices like this if each prototype
> provided a wrapping namespace like struct does.  Instead we could
> only pull in one union case per class, ugh!

hm, don't like it,
Kinda looks too much like using xml &entities; in the sense that it is 
more targetted to economising typing then it is to help define the 
widget structure: you are _not_ re-using the structure here!  This is a 
different kind of reuse, and doing it the same way makes it confusing to 

Looking at the wd:widgets inside the union we have to realize that they 
are not equivalent to the children of the <wd:group>. Meaning case-sets 
to be reused inside union are functionally different to 
grouping-prototypes that actually create a class-like struct.

Example: if I have a <wd:group type-def="Address"> then it would be odd 
to reuse that inside a 'union' that would allow you to edit only one 
part of it... union-cases are OR, group-children are AND?

In fact it also brings to light a different double-use of @id, no?
IIUC (please help clearing the mist) the union-instance has it's own id 
  that is used to namespace the selected-child?
However, this id is not present in the request-params, right? in stead 
the selecting-value is picked from the id in the @case?
That value then is used to select the active child?

So the union/@id role is NOT a request-param, and
union/wd:widgets/*/@id is both a request-param (in the union/@id 
namespace) and a matching-value to get selected?  (this last thing is 
the main problem you want to address with non-namespacing groups, again 
it looks like a consequence of an earlier decission, not a goal)

hm, I'm afraid I'm getting into new change proposals here, so shoot at will:

1/ why not have the selecting-widget defined INSIDE the union (that is 
his role, no?) --> so no more @case required, and thus no other widget 
to build and refer to

   <wd:datatype base="string">
     <wd:item value=""/>
     <wd:item value="OPT1"/>
     <wd:item value="OPT2"/>

2/ and then have nested wd:cases (I would use the grouping wd:widgets in 
fact that provide themselves the test to be selected)
The @expression hints that similar logic as in the validation 
expressions might be used possibly?

     <wd:case expression="OPT1">
       <... whatever the sub-widget might be ...>

re-using these case-sets in different 'choices' sounds more like a 
special case of extending (deriving) the union itself...
(it would also more logically map the wt:class, no?)

I'm quite sure there are more details I'm overlooking yet, but as a 
general approach this is less confusing IMHO



> To summarize, I like the type-def and type-ref design, and I think we should
> retain a way to also create and use mulit-widget prototypes that do not
> provide wrapping namespaces.

again, I'm not in principle against some combination of the best of both 
worlds, I'm just are cautious of patching something that is really the 
consequence of some other choices that could be reconsidered...

hope I gave some arguments above

> --Tim Larson
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message