[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [C2] actions, forms, etc.
From:       giacomo <giacomo () apache ! org>
Date:       2001-05-31 18:36:26
[Download RAW message or body]

On Thu, 31 May 2001, Piroumian, Konstantin wrote:

> > > I started to look at the C2 framework, to see if it was finally getting
> to
> > > the state where I could start porting some of my existing webapps over
> to
> > > C2. And I'm a bit confused about the current state of the Action
> > > framework...
> > >
> > <snip/>
> > > So, to work around this problem, I would propose to inverse the
> structure of
> > > the sitemap in the case of form validation:
> > >           <map:act type="check for form values">
> > >             <!-- form values not ok, redirect back to form. error
> > > information is passed in with the objectmodel -->
> > >           </map:act>
> > >           <!-- form values ok, save the data-->
> > >
> > > What do you think? Does this approach have any disadvantages?
> > > If not, then I would propose to convert the current examples to this new
> > > approach (I can help also, if needed).
> > >
> > actually we have previously came to another point. You are true that
> validator
> > actions now return nothing when validation fails, this will be changed so
> that
> > action will return special configurable param to the sitemap indicating
> what
> > the result of validation was and which parameters where wrong (this param
> can
> > later be used in param-selector), this way we
> > just need to figure out how these wrong parameters propagate nicely back
> to
> > the form, an XSP solution would be great but how to pass action's Map
> object
> > to XSP efectively ??
>
> Why not to use request attributes and place a HashMap with error messages
> there?
> My approach is this:
>
> 1. Form validator action validates posted data, creates some object (some
> XML 'instance data' if it's not present yet) and places error messages (or
> only error codes) there. Then that 'instance data' is added to the request
> attributes.
>
> 2. A form navigator action checks the result (some error flag in the
> objectModel) and depending on the result returns a 'nextpage' param.

I'd suggest not using the objectModel for any application purpose. The
are other objects specially made for this (Session, Request, Context).
This is why I've proposed to make the objectModel read-only.

> 3. Every form is processed by a FormTransformer which replaces special
> output tags (e.g.: <output ref="errors/error[@id='password']'" />)  by the
> error message from the 'instance data' according to the 'ref' attribute.
>
> 4. ??? Who must remove/clean instance data?

If they are in the Request object forget about it. If they are in the
Session object you need to do it on the next request.

> (Some ideas was taken from the W3C XForm Specification)
>
> >
> >
> > > Neeme
> >
> > martin
>
> Any comments on this approach?

We've used this approach in an e-shop we've realized 4 month ago. It
looks like being a predecessor to a flowmap which is still not mature
ATM. The problem is that you cannot see your flow of control (I mean
page to page flow) neither in the sitemap nor in any other
"configuration" file. It is hard coded into an Action (yes, of course
you can externalize this information into a configuration and use the
AbstractComplementaryConfigurableAction as a base having something like
a flowmap but doing it in a standardized and well designed way take
time to develop)

Another approach we've thought about was a general one.

1. have an Action that can build a "Command" object out of the
Request/Session etc. data. You can have different implementations of
this Action for different request types (GET/POST, SOAP request, ...)

2. have an Action that can dispatch those commands to real actors (ie.
FormaValidator, DBUpdater, DataCreator). This could be as well be
specified in a configuration file as well to map a Command to actors.
And this approach makes this Action/actors independant of the
surrounding environment. They only work with real objects (no XML, no
HTTP, no SOAP, only OO)

3. have an XSP page that can serialize the Data (ie. a Beans) from step
2 into SAX events.

4. the rest is usually known (transforming, styling, serializing)

Giacomo


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

[prev in list] [next in list] [prev in thread] [next in thread]