cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject Re: latest xform
Date Tue, 24 Jul 2001 16:35:46 GMT
Hi!

I was thinking of implementing XForms in Cocoon for several months but
unfortunately hadn't time to do it. I had something similar in Cocoon 1.
Just want to add my <i18n:currency value="0.02" />:

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

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

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

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

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.

>
> Well, anyway to keep you guys up-to-date...
> Here are the current files...
> --
> Torsten
>
>
Best regards,

Konstantin Piroumian
Software engineer

Protek Flagship LLC
Phone: + 7 095 795 0520 (add. 1288)
Fax: + 7 095 795 0525
E-mail: kpiroumian@flagship.ru
http://www.protek.com


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message