cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: [RT] Revisiting Woody's form definition
Date Tue, 29 Jul 2003 15:50:59 GMT
On Tue, 2003-07-29 at 17:23, Sylvain Wallez wrote:
> <snip/>
> >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.

> <snip/>
> >
> >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 <label> 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.


Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message