> > 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:
<order>
<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:
<xform:instance>
<order>
<firstname><mapper:bean name="orderBean" /></firstname>
<lastname><mapper:bean name="orderBean" /></lastname>
</order>
</xform:instance>
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 :)
Thank!
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
