Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 58225 invoked from network); 8 Jan 2004 13:37:28 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 8 Jan 2004 13:37:28 -0000 Received: (qmail 88871 invoked by uid 500); 8 Jan 2004 13:37:18 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 88822 invoked by uid 500); 8 Jan 2004 13:37:18 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 88496 invoked from network); 8 Jan 2004 13:37:15 -0000 Received: from unknown (HELO smtp1.xs4all.be) (195.144.64.135) by daedalus.apache.org with SMTP; 8 Jan 2004 13:37:15 -0000 Received: from outerthought.org (otsrv1.iic.ugent.be [157.193.121.51]) (authenticated bits=0) by smtp1.xs4all.be (8.12.9/8.12.9) with ESMTP id i08DbDWg004826 for ; Thu, 8 Jan 2004 14:37:13 +0100 Message-ID: <3FFD5D08.3060501@outerthought.org> Date: Thu, 08 Jan 2004 14:37:12 +0100 From: Marc Portier Organization: Outerthought User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [cforms] Forwarding: Explanation of "dynamic stuff in form model" References: <20040107140210.95943.qmail@web41902.mail.yahoo.com> In-Reply-To: <20040107140210.95943.qmail@web41902.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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 earlier... > >>>"class" nor "new" currently wrap any namespacing around the widget >>>definitions that are retrieved from the class via "new". That is: >>> >>> >>> >>> >>>is functionally equivalent to: >>> >>>and *not* to: >>> >>> >>> >>> >>>(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 >> > >> > >> > >> >>would become >> > > > 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 --> classic use, create widget --> prototype-only (ie equivalent of wrapping with wd:class ) --> 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: > > > > > > which should be functionally equivalent to: > > > 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: then using this: 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: while the current-style syntax requires: 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: >> >> >> ... 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: >> (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: then you could just use that by just: so yes, in terms of re-use without extension (ie deriving) the should function as a generic wrapper for the prototype it's based upon > should not have to reuse like this: > On the other hand, this could be a (possibly weak) argument to change > widget definitions to look like this: > > It is a little more wordy, and using 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 pattern a bad substitute to ... of course if you get into then you can start a discussion if it really is that much better to choose some over ... 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: >> or just deriving to a new prototype: or doing both at once: > 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/ mpo@outerthought.org mpo@apache.org