cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <>
Subject RE: latest xform
Date Wed, 25 Jul 2001 11:57:58 GMT
> > here is where we are at:
> >
> > - on the first view the XSP page passes the SAX events
> >   to a new DOMObject. This holds the instance data of
> >   the XForm.
> What, if we need to show data from another form? Say, in a sequence of
> forms: Person registration, Sell services. On the Sale form we need to show
> the name of the person which was entered on the first form. We are using an
> instance data which is shared by all forms in a process. This way you can
> get any data you need.

Just having one instance is not what I understood from the XForm spec.
I think this is also mixing concerns. I would propose to use the
mapping facility that we will have. So you could maybe do:

    <firstname><mapper:xform id="otherform" ref="/root/node" readonly="true"/></firstname>

This would initially fill the firstname from a different form.

> > - all XForm elements are registerd inside a PostRegistry
> >   (this circumvents the checkbox problem)
> >   FIXME: the PostRegistry is declared ThreadSafe. I haven't
> >   checked that so far..
> > - the XForm instances are saved inside the session
> > - the XForm instance data are inserted into the XSP page via XMLFragment
> interface
> > - getValue( String XPath ) returns a text node's string representation
> >   FIXME: right now the XPath must end on /text() since this is the full
> XPath.
> >   Should this be changed?
> > - setValue( String XPath ) set a the value of a text node (see getValue)
> >   FIXME: same as above and needs to insert a text node if there is none
> >   already. (happens on immediat close of tags: <firstname/>)
> > - DOMObject is now an interface AbstractDOMObject is the implementation
> > - now we have a DOMObjectOutputWrapper that opens
> >   the door for backend mapping like beans or whatever.
> > - FIXME: the DOMObject interface has to be extended. Only "setValue" and
> >   "getValue" cannot handle multiple values of a "selectMany"
> I can propose to add two methods to the DOMObject interface:
> addValue(xpath, value); - adds a node to the xpath, for multy-select fields.
> removeValue(xpath); - removes all values (if you can select values, then
> must be able to deselect them too)
> removeValue(xpath, index); - for convenience (is equal to
> removeValue("path/item[$index]"); )

Looks fine...

> > - the first (raw) version of the XFormAction is working. Post values
> >   already find their way back into the instance
> >
> > I was thinking about the validation constraints issue.. Why is the
> > validation in the XForm spec bound to the XForm elements and not
> > to the xform:instance?! Just a thought...
> I think, that because elements can be bound to different instance datas and
> validation rules in XForms cover also dependency constraints. You can have
> fields in one instance that must be validated with other fields in another
> instance data.
> > Should we put the validation constrains and the error handling into
> > another namespace not to break XForm compatibiliy? (And contact the
> > XForm group...)
> Validation constraints are supported by XForms, we can just use them. See
> how bindings are organized.

Hm... all I saw was the "validate" attribute which may hold a boolean
expression. Of course this might hold a complex validation. But I don't
see how set an error other than "valid" or "invalid". Nice would be
to have more information about the error.

> Error handling is another matter. As I remember,
> XForms does not specify how the data must be processed - it's the task of
> the application. And the application can place error codes and error
> messages directly in the instance:
> <xform:instance>
>     <errors>
>         <error field-id="password">
>             <code>-101</code>
>             <message>Password incorrect<message>
>         </error>
>     </errors>
>     ...
> </xform:instance>

The client will provide the error information!? Hm.. So error setting
needs to happen while the "validate" expression is evaluated then, right?!
This would be pretty hard to implement...

> > I also need an interface to pass some information to mapped backends.
> > E.g. we need to be able to tell a bean - process this order now!
> This can be done with xform:submit. Data can be submitted to a Cocoon
> action, which will perform business operation, such as order processing.

Yes, but let's assume we have mapped a bean:

      <firstname><mapper:bean name="orderBean" /></firstname>
      <lastname><mapper:bean name="orderBean" /></lastname>

How do we tell the mapped _bean_ to process the order!
Somewhere we need to define the connection between the
xform:submit and the a bean method...

> This was my suggestions and you are free to accept, critisize or just ignore
> them, but I'll be glad to help you in developing a common form processing
> mechanism and share my experience with you.

Please keep it on suggesting :)

To unsubscribe, e-mail:
For additional commands, email:

View raw message