Return-Path: Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 40428 invoked by uid 500); 29 Jul 2003 15:54:43 -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 40336 invoked from network); 29 Jul 2003 15:54:42 -0000 Received: from dobit2.ugent.be (HELO dobit2.rug.ac.be) (157.193.42.8) by daedalus.apache.org with SMTP; 29 Jul 2003 15:54:42 -0000 Received: from allserv.UGent.be (allserv.ugent.be [157.193.40.42]) by dobit2.rug.ac.be (8.12.8/8.12.8) with ESMTP id h6TFshll000651 for ; Tue, 29 Jul 2003 17:54:44 +0200 (MEST) Received: from otsrv1.iic.rug.ac.be (otsrv1.iic.ugent.be [157.193.121.51]) by allserv.UGent.be (8.12.8/8.12.8) with ESMTP id h6TFshZS015995 for ; Tue, 29 Jul 2003 17:54:43 +0200 (MEST) Received: from yum.ot (host102 [192.168.123.102]) by otsrv1.iic.rug.ac.be (8.11.6/8.11.6) with ESMTP id h6TFshx20646 for ; Tue, 29 Jul 2003 17:54:43 +0200 Subject: Re: [RT] Revisiting Woody's form definition From: Bruno Dumon To: dev@cocoon.apache.org In-Reply-To: <3F26918E.2060802@anyware-tech.com> References: <3F258456.50406@anyware-tech.com> <1059487511.22841.256.camel@yum.ot> <3F26918E.2060802@anyware-tech.com> Content-Type: text/plain Organization: Outerthought Message-Id: <1059493859.22840.287.camel@yum.ot> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 29 Jul 2003 17:50:59 +0200 Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 2003-07-29 at 17:23, Sylvain Wallez wrote: > > > >Currently it is not checked that the value comming from the request is > >actually in the list. So the list is more of an input-aid then an > >enum-type. > > > >That's also one of the reasons I've moved it out of the datatype, > >together with making it possible to replace the selectionlist from the > >FieldDefinition on the Field-instance-level. > > > > This comes to another topic I had in mind : open vs closed enumerations. > There are cases where the enumeration must be closed, because the > possible values are in a finite set, and other cases where enumeration, > as you say, are an input-aid. It actually popups vs combo-boxes, and I > think both are needed. > yep, that's right. > > > > >Does it still make sense to allow formats (converters) to be defined as > >part of the datatype? I'd leave them out completely. > > > > The purpose is reduced verbosity and increased consistency : if you > define a format on the "date" type, then you just have to define a field > of this type and automatically have the same formatting application-wide > wherever this type is used. ah ok, didn't think of that. > > > >About Treeprocessor parallels: one difference between how the > >treeprocessor builds its nodes and how Woody does it is that Woody > >builds them from DOM elements rather than Avalon configuration objects. > > > > Yep. I guess it's needed because elements such as can contain > mixed content, which is not allowed by the Avalon configuration. I'm > always a bit reluctant to using DOM, but it's ok here since it's > occuring only at the first use of a form (unless it's dynamic) and doing > it using SAX would be more difficult. What about pull parsing ? the idea crossed my mind. Still, it's more complicated then using DOM. You need to process things in the order in which they are written in the XML file. Each builder would need to read up to but not any further than the closing tag of its configuration. And in order to store the contents of a wi:label tag, something would have to be made (now we're benefitting from the NamespaceNormalizingDOMStreamer which assures we have a nicely stand-alone SAX-fragment). > >Sylvain says: > > > > > >>Inspiration could however be taken from the component handling, since > >>currently Woody widgets aren't components (no logger, no access to CM, > >>context, etc) while TreeProcessor nodes are, thus giving them far more > >>potential power. > >> > >> > > > >Indeed, currently only the builders are components. I haven't > >experienced the need yet for full-component power (which might then also > >require proper disposing of forms). Giving them a logger shouldn't be > >problem though. > > > > I'm sure we'll have very soon some complex widgets that will need access > to either the object model, Sources, input-modules... yep, I can imagine that. > > As for disposal, the TreeProcessor maintains a list of all Disposable > nodes created by the builders that are disposed when the sitemap itself > is disposed (BTW, thanks Carsten for finding that nodes should be > disposed in reverse order !) The problem I saw with disposal was related to form-instances (more the when than the how), but now I realize it's probably only the *Definition objects that would need to become components, no? > > I think the first item is to define the allowed content in the various > files in order to reach ASAP a stable version of the file formats. This > will allow to build on these foundations without harming compatibility. > I'll formulate this in the wiki with some examples. great. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center bruno@outerthought.org bruno@apache.org