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.
- 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"
- 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...
Should we put the validation constrains and the error handling into
another namespace not to break XForm compatibiliy? (And contact the
XForm group...)
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!
Well, anyway to keep you guys up-to-date...
Here are the current files...
--
Torsten
xform.zip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
