cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: [RT] Revisiting Woody's form definition
Date Tue, 29 Jul 2003 14:05:27 GMT
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).

>  define the locale-dependent 
> conversions between a value and its string representation. This is where 
> e.g. date formats are defined. Currently, Woody defines converters 
> inside <datatype> which is inside <field>. But if we separate datatypes 
> as suggested above, do converters belong to fields or to datatypes ?
> 
> In my opinion, to neither and to both :
> - to neither, because just as datatypes are independent from fields, 
> convertors act on a particular base type (double, date, etc) and have no 
> relationships with the particular constraints defined by a datatype nor 
> with any particular form field. So just as for datatypes, we can thus 
> have a format catalogue reused by several forms and/or datatypes.
> - to both, because a datatype may have a "default" or "preferred" 
> converter, but still leave room for a particular field to use a special 
> custom format.

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.

<snip/>

> Selection list
> --------------
> 
> Selection lists define an enumeration in which the user has to choose a 
> value.
> 
> Selection lists currently can be defined in datatypes, but it may make 
> sense for fields to also allow selection lists, thus restricting the 
> values allowed by their datatypes. If both the datatype and the field 
> define selection lists, the field's list must be a restriction of the 
> datatype's list (note that this can be enforced automatically since the 
> datatype will check it's list before the field does the same).

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.

> 
> Visual elements
> ---------------
> 
> These are the widget's label, hint, help, hotkey, and any other 
> information that will come around the widget in the produced page. This 
> information is field-specific (doesn't make sense for a datatype).
> 
> But this information can also be considered as template-specific, since 
> visual elements belong to the view. So what about allowing them in the 
> template also, e.g. :
> <wt:widget id="foo">
>   <wt:label>My label</wt:label>
> </wt:label>
> 
> Of course, one may consider that the label content should simply replace 
> a <wi:widget-label>, but I'm considering here the case where the 
> template totally delegates the form layout (including label placement) 
> to the formatting stylesheets (like XMLForm does).

This all makes sense to me.

> 
> Styling data
> ------------
> 
> A Woody template can contain foreign markup inside <wt:field>, which is 
> copied as is by the WoodyTransformer, encapsulated in a <wi:styling>.
> 
> This clearly belongs to the view. Or do we want to be able to specify a 
> default rendering style in the field definition ?

I don't think that will be needed either.

> 
> Binding
> -------
> 
> Binding defines the process or filling a form with application data and 
> later writing the form data back to application data. This is currently 
> a separate file that maps every widget of the form to the application.
> 
> What's currently missing is a way for the binding to enforce more 
> validation controls related to data not present in the form. A kind of 
> Schematron mixing form data and application data. This would require the 
> ability to set widgets violations externally, but Bruno already talked 
> about adding this.

correct

> Of course, there's still the possibility to open the "java code box", 
> but XPath expressions mixing form and application data can fill most of 
> the needs.

I have no direct need for it, but it seems like a useful addition.

(a bit later) while re-reading my response I'm beginning to realize that
I could actually use this...

> 
> Also wouldn't it be less verbose if the binding was written in the form 
> definition itself ? This mixing would only cause problems if we want to 
> have several bindings on a single form, but I'm not sure this case will 
> arise often.
> 
>                 +---------------------------+
>                 |     Change proposals      |
>                 +---------------------------+
> 
> 
> Datatypes and format dictionaries
> ---------------------------------
> 
> Allowing separation of datatypes and formats from form definitions will 
> reduce their verbosity and increase reusability and consistency. Adding 
> these two files may be though of as increased complexity, but they will 
> in fact greatly simplify form definition.
> 
> The problem is how these files should be referenced from the sitemap 
> and/or the form. IMO, such catalogues can be considered as 
> application-wide, and therefore be declared in the Woody component 
> configuration, thus avoiding some more parameters in the sitemap itself.

agreed with these changes.

(and for that matter, also with validation-rule chaining and other stuff
described earlier).

> 
> Identification of concerns
> --------------------------
> 
> The above analysis contains some "micro-proposals" for each item, which 
> may seem like a big mixing of all concerns. I think this reorganisation 
> is important to ensure minimal verbosity and hassle when writing forms, 
> while still allowing people to choose their preferred way of working 
> (most often, a single person is in charge of many of the concerns).
> 
> Now the question is : are element's concerns identified by the file 
> they're written in or by their namespace ? I found somewhat confusing 
> when I discovered Woody that a given data (e.g. a <label>) is copied 
> unchanged from the form definition to the form instance but has its 
> namespace changed from "wd:" to "wi:". IMO, the label being a concern of 
> the form instance, it should be written <wi:label> whatever file it is 
> in. So why don't we use the namespace to identify the concerns and allow 
> mixing these namespaces in configuration files ?
> 
> This would give e.g.
> <wd:field id="foo">
>   <wi:label>The label for foo</wi:label>
> </wd:field>
> 
> 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.

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

and selection lists

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

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.

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.

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

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

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message