Sorry, for the late follow up guys. I am in bed with a bad cold...
First off: I like say some more words on XForms topic...
Please guys!! Be aware of the fact that XForms is heavily client centric!
I'm not quite sure (any longer) if a server implementation is really that
easy to come up with, intended or possible at all.
It makes me also a bit upset hearing people saying "That's not XForms
complient" but on the other hand saying "Struts is great". (Don't mean
anyone specificly) AFACS it does not need a W3C spec to build a good form
handling framework that people associate with attributes like "elegance".
AFAIK Struts does not conform to any W3C spec either. Of course it would
be even better if we could make if conform such a spec but last commits to
exFormular are almost a year from now. I doubt this will change in the
near future. And my company wants a form handling sollution for cocoon
*now* and not in in 3 years. Otherwise they want me to build a homegrown
one again. I am happy they support my current cocoon-only work...
If we decide on using a server side xforms implementation then I ask those
people moaning about XForms conformance to help. That's no peace of cake
for sure..
Another alternative would be to talk to the Struts people and help
bringing them the missing XSLT/XML support and with that the integration
with Cocoon.
As for the syntax: of course the syntax will be near XForms since it
stears the same direction. But not for migration reasons! We are in a XML
world here... creating a stylesheet for migration is no big deal.
Now back to the discussion...
----
<snip/>
> >>what do mean by "object model of the form"? I actually don't
> >>want to have
> >>always beans behind my forms. Is this what you are at?
> >
> >Yes, that was the idea. Anyway, we need to know, as you've said, what to
> >expect from the current request. There are two possibilities: create a
> >separate description (say, phases) or use the form description itself. If we
> >create an object model of the form (not only UI, but also bindings) then we
> >can simply iterate through form fields, validate according values from
> >request against a schema, then we can validate request against binding
> >contraints.
First of all: not everyone (e.g. our company) wants beans in the
background. We have done this in our last project but found it not that
comfortable... (you need people who can program java, you need always to
compile on changes - same reasons why we moved away from the compiled
sitemap to the interpreted one - thanx Sylvain :)
It's not that clear to me what you mean by "form description itself". I
actually don't see another possibility instead of specifing the expected
request parameters for indirect population either as xpaths or as phases
(which are a collection of xpaths)
> >We can use 'visible', 'relevant' attributes of bindings (maybe also some
> >other means) to find out which params from request are relevant. Seems to me
> >not very complicated, although requires a bunch of classes for every
> >possible element: input, select*, output, binding, etc.
Hm... I cannot see how this helps on populating.
> >>Well, the preceptor should know about it... it defines what
> >>is required
> >>and what is optional.
> >Hm... So, what are the all tasks that are performed by the preceptor?
Hm... seems I didn't make the idea that clear... ok, let me explain:
INSTANCE: The instance is the most simple, xpath based interface to a XML
document implementation. It should be possible to implement it for beans,
DOMs, even a XML file. Taking the latest comments into account it could
look like:
interface Instance {
void setNodeValue( String xpath, String value);
void String getNodeValue( String xpath );
void removeNode( String xpath );
}
This interface provides all you need to edit an instance. Adding is not
necessary because setNode automagically creates missing nodes. If we don't
like it we could provide a pointer-like node for this and the interface
could look like this:
interface Instance {
Node createNode ( String xpath );
void removeNode ( String xpath );
Node getNode ( String xpath );
}
interface Node {
void setValue( String value );
String getValue();
}
PRECEPTOR: (the name: thought since we have a "janitor" this might be ok
;-) but maybe we can change the name after the dicussion. util now I'd
like to keep it so we don't mix it up and always know what we are talking
about) The preceptor defines how the instance is allowd to look like.
Preferable in structure as in content. It will read from a pipeline and
"compiled" into an object holding structural information as well as all
the constraints. (So *if* the pipeline always reveals the same data (is
cachable) it is even sufficient to have a threadsafe preceptor)
interface Preceptor {
boolean isValidNode( String xpath );
Constraints[] getConstraints( String xpath );
Constraints[] validate( Instance i, String xpath, Context context);
}
> >Hm... Not very intuitive. I'd design it in a little different way, say:
> >return a collection of ValidationViolation objects and each of them can be
> >of different types or have a field indicating the violation type. E.g.:
> >incorrect data format, required contraint violation, etc. Then we can use
> >the violation type to select the appropriate error message (this also takes
> >into account i18n of errors).
Could it be a simpler validation interface? Taking into account the
comments on the validate: It might be unusual to return a *constraint*
instead of a constraint violation but this saves us quite some object
creations. If we would rename "validate" it maybe makes more sense:
interface Preceptor {
boolean isNodeAllowedInInstance( String xpath );
Constraint[] getAssignedConstraints( String xpath );
Constraint[] getViolatedConstraints( Instance i, String xpath, Context context);
}
interface Constraint {
boolean isSatisfiedBy( String value, Context context );
String getId();
}
The question is if the constraint itself should really take care about
i18n. IMHO - NO! SoC! The constraint should have unique identifier that
then will be translated into the i18n error message by the i18n
transformer.
For the failfast operation we could add another method to the interface.
Constraint getFirstViolatedConstraint( Instance i, String xpath, Context context);
> >>>Flow controller also should determine that the process is
> >>finished and
> >>>perform some business logic calls with collected data,
> >>isn't it? After that
> >>>some default (success page) should be displayed.
> >>>
> >>why finished?? can you elaborate a bit more, please?
> >>
> >
> >What happens when user has entered all the required feedback information
> >then wishes to click on the final 'Submit' (or 'Done' or 'Send') button? The
> >flow process should be finished after the data is stored somewhere and some
> >notification should be displayed to the user after that. Am I wrong?
Well, true, but I wouldn't see it as "finished". I would see it as: we
want to be able to bind indiviual actions onto buttons. Well, and the last
button does what is necessary at "the end". Please have brief look into
the PreceptorDemoAction.
> >I the flow descriptor or where?
> >I'd prefer dynamic navigation buttons in future. I'd implemented something
> >like that with C1 and buttons appeard depending on the user position in
> >wizard. This can be easily added after we implement everything with static
> >buttons.
Hm... interessting... In your C1 implementation where did you get your
captions etc. from?
> >Yes. We can have a stub (maybe hard coded) for everything that needs a flow
> >controller and first of all implement form
> >population/validation/presentation parts.
please elaborate a bit more...
> >In XForms bindings. E.g.:
> ><bind ref="customer/car-info/issue-year" relevant="customer/has-car='true'"
> >required="true" />
> >
> >You should have seen this in my XForms sample.
Don't have this one at hand.. could you send it again? maybe off the list.
> >After we have any validation we will have the community power to optimize it
> >;)
hopefully ;) I have been thinking about the always-full-validation more
and more lately...
This would make more preceptor implementations available in short amount
of time...
> >Speaking frankly, I don't like the phase idea at all. It adds another
> >configuration file that should be supported and kept in sync with form
> >descriptors.
you know what... I don't like it either ;) This mainly comes from our
Schematron integration tries. Although you also can see on the
PreceptorDemoAction - as soon as we use indirect population we probably
need something like that *sigh*
There are two diffrent options:
1) go back to direct population. which is ugly because of the hidden
fields
2) let a transformer collect the phase information from the view. which is
also ugly because a phase does not necessarily match the controls needed
for population and validation.
> >Let's find answer on this: is form description (descriptor) itself enough to
> >determine the phase or simply the request params that should be taken into
> >account during validation and instance update? Or: are the phase and
> >relevant params the same thing?
you come up with a new term here... what do you mean *exactly* by the form
descriptor... the preceptor? actually there shouldn't be any form
description other than that one... with the precept approach we reduce a
form to an XML fragment (the instance) and the validity information
(preceptor)
Phase is not the same as relevance... A phase is meant to be some sort of
a NodeList. Relevance can be important for constraints that are not always
applicable. (Relevance should be part of the "Context" (see interface))
> >Also, IIRC you've mentioned that validation should be two phase operation
> >(again those phases ;) ):
> > - data types validation
> > - contraint validation
> >The second phase should be skipped for those fields that didn't pass the
> >first one. So, we will need at least two types of objects indicating an
> >invalid state of data.
No, I didn't say that... Actually I think there are no two phases for
validation. I see data types as nothing but a strictly defined collection
of constraints. So every data type can be expressed with a common set of
simple constraints. Am I wrong here?
> A small input for this particular design point (didn't have the time to
> read all this however interesting stuff)...
I wish you had the time to look closer :)
...as well as others ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
