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 Thu, 08 Jan 2004 13:37:12 GMT
Tim Larson wrote:

> --- Marc Portier <> wrote:
>>1/ this would make the  builders stateful, so we probably will need some 
>>different type of classes like 'prototype' or something (could be inner 
>>class of the builder).
> I will have to think about this stateful builder issue some more, but
> time is a little tight right now.
>>Overall this pretty  much resembles the copy-constructor idea, but by 
>>creating the prototype and it's derived into different classes you _can_ 
>>get everything final...
>>2/ but there is a more essential issue I think, 'order' of definition is 
>>only one thing (for that we could just do a DOM-search to look ahead in 
>>the definition file, remember?)
>>However, you spent quite some time explaining me that binding and 
>>definition graphs could get cyclic (ie no longer straight top-down 
>>trees) by using the 'union' (to be called: 'choice')
>>class (x) --> union --> new (x)
>>                    \--> other stuff...
> Yes, essential for the form-based-GUI use case, and for some interactive
> data exploration use cases...
>>in which case there really is a chicken and egg problem:
>>chicken class-x will wait to be constructed untill all it's children are 
>>known, as will sub-chicken 'union', so to relieve the 'we are all 
>>waiting each other' we need to be able to create the egg new-x in some 
>>'dummy way' with a non-final ref to be filled-in later once class-x is 
>>actually done
> I will try to work out the details when I have time again, but I think
> the coordinating builder-and-object-constructor idea can be made to
> solve this while retaining 'final'.

I haven't seen a solution yet, and would not mind a less strict 
implementation if the same concept by using the pattern I discribed 

>>>"class" nor "new" currently wrap any namespacing around the widget
>>>definitions that are retrieved from the class via "new".  That is:
>>>  <wd:class id="asdf">
>>>    <wd:widget id="qwerty"/>
>>>  </wd:class>
>>>  <wd:new id="asdf">
>>>is functionally equivalent to:
>>>  <wd:widget id="qwerty"/>
>>>and *not* to:
>>>  <wd:some-wrapper-widget-or-element id="asdf">
>>>    <wd:widget id="qwerty"/>
>>>  </wd:some-wrapper-widget-or-element>
>>>(How) does this affect your proposals?
>>actually it kinda offers extra arguments to my reasoning:
>>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?

> ids.  The introduction of "type-def" would give us a way to put the
> class name in a separate "types" namespace.  I.e. "type-ref" could
> only see classes (types) and wt:widget, etc. could only see widgets.

yes, one could thus use the same values for @id and @type-def without 

admitted: doing so might yield some confusion to the reader of the 
definition file that does that, but that seems to be more of a 
best-practices thing then the more conceptual SoC issue?

>>2/ the elements new and class are just decorating around whatever is 
>>inside them: so why not use attributes in stead, those are more suited 
>>for the decorating job... the actual elements in the wd:file then all 
>>map onto actual types, while two introduced attributes (I would propose 
>>@type-def and @type-ref would take over the define/reuse goal of 'class' 
>>and 'new')
>>so in your above example, the new equivalent syntax for
>> >   <wd:class id="asdf">
>> >     <wd:widget id="qwerty"/>
>> >   </wd:class>
>>would become
>><wd:widget id="qwerty" type-def="asdf" />
> 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

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

Here is why I don't like it
suppose this:
    <wd:class id="asdf">
      <wd:widget id="qwerty"/>
      <wd:widget id="zxcv"/>

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?

And I think you don't need it, it's not adding features, is it?

I do understand that this is quite an impact-heavy change proposal, I 
just think it fits better

other example of proposed writing:
<wd:group type-def="Address">
   <wd:widget id="Name">
   <wd:widget id="Street">
   <wd:widget id="Zip">
   <wd:widget id="City">

<wd:widget id="to" type-base="Address" >
<wd:widget id="to" type-base="Address" >

while the current-style syntax requires:
<wd:class id="address">
   <wd:widget id="Name">
   <wd:widget id="Street">
   <wd:widget id="Zip">
   <wd:widget id="City">

<wd:struct id="to">
   <wd:new id="address" />

<wd:struct id="from">
   <wd:new id="address" />

I think this is more then just matter of taste, or not?

>>if you need namespacing you would need the 'struct' (for which group 
>>would be a more sensible name indeed) concept...
>>if it needs to be reused or not is in a different dimension, and to be 
>>done by adding an optional type-def attribute:
>><wd:struct id="group-name" type-def="asdf">
>>   ... his members here
> Ok, struct (or "group") working as normal.
>>on the reuse-side there is some extra argumentation for this approach by 
>>the introduction of the 'deriving'
>>if we don't do deriving then
>>- reuse can be with a generic wd:widget wrapper:
>>   <wd:widget type-ref="adsf"> (in stead of wd:new, so no big win)
> 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

that is precisely what I was saying:
if you don't do deriving then even if the prototype-definition looks like:

<wd:group type-ref="asdf" >
   <wd:widget id="qwerty" >
   <wd:widget id="zxcv" >

then you could just use that by just:

<wd:widget type-ref="asdf" />

so yes, in terms of re-use without extension (ie deriving)
the <wd:widget> should function as a generic wrapper for the prototype 
it's based upon

> should not have to reuse like this: <wd:aggregatefield type-ref="asdf"/>
> On the other hand, this could be a (possibly weak) argument to change
> widget definitions to look like this:
>   <wd:widget id="hjkl" type="aggregatefield"...>
> It is a little more wordy, and using <wd:widget type-ref="asdf"/> to
> reuse a class containing more than one widget still looks funny because
> "wd:widget" is singular but would be refering to multiple widgets.

I've always found the <common type="actual"> pattern a bad substitute to 
<actual>... of course if you get into <common type="actualType" 
id="actualId"> then you can start a discussion if it really is that much 
better to choose some <actualType id="actualId"> over <actualId 
type="actualType">... in thise case I think history made the choice, we 
should just add the new stuff in an elegant way

>>if we do provide it, then
>>- the (see copy-constructor idea) define-reuse widgets will need to 
>>match so depending on the wd:TYPE that was used for the type-def, you 
>>would need a matching wd:TYPE for reuse, supposing you had a struct, and 
>>you want to derive to reuse and add a field:
>>   <wd:struct type-ref="asdf>
>>     .. more children here
>>   </wd:struct>

again, if you do want to extend (derive) then you have to make sure that 
the to be added features match the type of the prototype, no?

so using the prototype while adding a field to the group:
<wd:group type-base="asdf" id="n" >
   <wd:widget id="poiuy" >

or just deriving to a new prototype:
<wd:group type-base="asdf" type-ref="extended-asdf" >
   <wd:widget id="poiuy" >

or doing both at once:
<wd:group type-base="asdf" type-ref="extended-asdf" id="n">
   <wd:widget id="poiuy" >

> Again we would need a wrapping element (currently provided by wd:class)
> to be able to also implement a non-namespaced version of this example of
> derived reuse.

as said before, non-namespaced seems dangerous without adding funtionality

>>hm, that last sample makes me think we should maybe change @type-ref to 
>>@type-base... but before getting in those details , we should allign on 
>>the concepts first...
> Yes, using "base" in the name would parallel datatype syntax.
> --Tim Larson

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

View raw message