--- Marc Portier <[EMAIL PROTECTED]> 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 earlier...
"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 conflicts
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 prototypeso 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"/>
</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?
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:group>
<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:class>
<wd:struct id="to"> <wd:new id="address" /> </wd:struct>
<wd:struct id="from"> <wd:new id="address" /> </wd:struct>
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 </wd:struct>
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" > </wd:group>
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" > </wd:group>
or just deriving to a new prototype: <wd:group type-base="asdf" type-ref="extended-asdf" > <wd:widget id="poiuy" > </wd:group>
or doing both at once: <wd:group type-base="asdf" type-ref="extended-asdf" id="n"> <wd:widget id="poiuy" > </wd:group>
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
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
