cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Revisiting Woody's form definition
Date Tue, 29 Jul 2003 15:23:58 GMT
Bruno Dumon wrote:

>On Mon, 2003-07-28 at 22:15, Sylvain Wallez wrote:
><snip/>
>  
>
>>Convertors
>>----------
>>
>>Convertors (or should it be "converters" ?)
>>    
>>
>
>hmm, good point. They seem to be both valid. I seem to have a natural
>tendency to write "convertor", but I'm fine with both. I've noticed that
>later on in this mail you've switched to the word "formats" for the same
>concept (IIUC). Converters then seem to describe the concept somewhat
>better since they work both ways (formatting & parsing).
>

Actually, while writing, I needed different words to identify the 
component implementing the Convertor interface and it's particular 
instances defined using the <convertor> tag. So I ended up with 
"converter" for the component and "format" for the instances.

The same applies to datatypes : the base types (defined in xconf) are 
used to define datatypes which are more or less instances of the base 
type. So I guess we need different words to clearly know what we're 
talking about.

<snip/>

>It is a good idea to move converters out of datatypes, as I recently did
>with selection lists.
>
>The main motivation for making them part of the datatype was because the
>converter must match the basetype of the datatype. E.g. if the datatype
>is date-based, then the converter also has to be a date-converter, and
>the selection list should also produce a list containing dates. But this
>doesn't require them to be contained by the datatype; as long as the
>widget-builders make sure their basetypes match then everything's fine.
>

Yep. Furthermore, checking type compatibility must be enforced by the 
classes (I guess some of them already do).

<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.

<snip/>

>>We can then define which concern is allowed in which file and define the 
>>various configuration files as an "overriding chain" :
>>   format dictionary < datatype dictionary < form definition < form template
>>
>>Format dictionary contains : named formats
>>Datatype dictionary contains : named datatypes composed of base type, 
>>optional validations, optional (format reference or inline format)
>>    
>>
>
>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.

>>Form definition contains : widget definitions composed of (datatype 
>>reference or inline datatype), optional format, optional visual items, 
>>optional styling items,
>>    
>>
>
>and selection lists
>

Yep. Forgot that one.

>>Form template contains : widget references including optional visual 
>>items, optional styling items
>>
>>The binding is not mentioned here as it is orthogonal to this chain (can 
>>be either in a separate file on in the form definition file, but not in 
>>other files).
>>
>>                +---------------------------+
>>                |          The end          |
>>                +---------------------------+
>>
>>
>>Thanks for reading so far. I hope I was able to explain all this clearly 
>>and that most of this makes sense.
>>
>>Traditional question : what do you think ?
>>    
>>
>
>I think it all makes sense. More of an evolution than revolution. We had
>been thinking on some of these things already (the dictionaries), but it
>wasn't the highest priority for us.
>
>The double use of elements in different namespaces (such as label) had
>been annoying me but I hadn't thought of simply mixing the namespaces.
>
>Mixing in some other mails:
>
>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 ?

>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...

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

>Sylvain says:
>  
>
>>Since you seem to be globally ok with my proposals, with now have to 
>>organize collaborative developpement : do you have some uncommitted 
>>changes, who does what, etc.
>>    
>>
>
>All my stuff is in CVS.
>
>As for my planning, I first need to do "something else", will probably
>take some (2-3) days. After that I don't have much sight on planning
>yet, but I'll share all Woody-related plans. Anyhow, if you have things
>that you'd like to commit or start working on, go ahead.
>  
>

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.

>As for syncing our activities, we'll simply have to let each other now what we're up to.
>

Yep.

>Marc says:
>  
>
>>most important maybe is that we commit ourselves to promptly 
>>reply on this list the comming weeks so we're not too much 
>>blocking anyones thought-train?
>>    
>>
>
>I'll do my best. If Marc has too much work he offloads it to me, but I'm
>last in the line ;-)
>

Have you heard the message, Marc ? Don't overload Bruno ;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message