> > > 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.
>
Ok, I get you.
So for data exchange between instances you are going to define a new mapper
namespace? We are going to implement such mapping in our equivalent of your
selection logicsheet. Anyway, you are right, this is not an XForm concern.
> > > - 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...
I am trying to implement setValue() and addValue() and I'm faced a problem
with XPath API. I am trying to find out is there a possibility for node
insertion by an XPath expression. It seems that it's not possible with XPath
API.
Setting values is a simpler task: the node can be selected first then you
can set its value by setNodeValue(). But what if the node is not present in
the document? Say, you want to set a value by xpath 'a/b/c', but if you
don't have 'a' and 'b' and 'c' node in your instance Document object then
you have to parse XPath expression then iterate from root to the child and
create every absend node.
Maybe somebody knows an easier solution?
>
> > > - 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.
>
Yes. We need to provide at least an error message. In more advanced cases we
will need also to have an error type: warning, info, etc. (This can result
in a different styling or an error image for the input field).
> > 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...
Don't quite understand this: > The client will provide the error
information!?
As I understand this, validation can be done on the client side (browser,
with JavaScript) and in the application on the server side.
1. For the JavaScript validation we can generate some call to JavaScript
functions when we are generating the page. Information about the validation
rules can be taken from description of XForms models.
E.g., on the field of type 'date' we can generate in resulting HTML this
tag:
<form onsubmit="validate-fields()" name="activeForm">
<input type="text" name="date-of-birth" class="input-field">
</form>
and the contents of validate-fields() JS function can be generated
dynamicaly:
<script>
function validate-fields() {
// generated by an XForm transformer or a logicsheet + stylesheet
(for HTML)
is_valid = validate_date(document.activeForm.dateOfBirth.value);
return is_valid;
}
</script>
2. Server validation can be done when the user submits data and some actions
are called. Actions can add error information to the instance data (as I
described before) then the renderer (a transformer or an XSLT stylesheet)
can use field-id attributes to set the appropriate styling and error
message.
Maybe an additional instance data can be used to separate the error messages
(view information) from user input data?
>
> > > 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...
>
You can do it in an application specific Action and bind with xform:submit
in sitemap. Am I right?
> > 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 :)
Ok.
Sometimes my English is hard to understand, though :)
> Thank!
> --
> Torsten
>
Konstantin.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
