cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject Re: 4 New Classes
Date Tue, 17 Apr 2001 10:23:33 GMT
> > The HAFormProcessor has to be able to completely replace the output
> > document.
>
> Why that?
>
> > I could not find a way to do that and to navigate the
> > entire input document at the same time.
>
> <form>
> <hidden> ... </hidden>
> <inputfield> ... </inputfield>
> </form>
>
> Then transform that in XSLT to produce HTML forms.
>
> > on the POST each field is validates.  user_name must have a value, and
> > the user_email if it has a value must pass the "email" validation.
> > Once that is done the following document would be produced:
>
> What is the validation based on? XML-Schema?

The Schema validation is not enough for real use. There is no dependency
checks, constraints (like readonly) and some other things that are essential
in commercial products. I think, that must be possibility to use a special
class for validation, e.g.: <form
validator="com.some.company.ValidateCustomerData" />.
>From the other point of view, a Schema can be used to generate code (in
JavaScript) for client-side validation: data format checks (date, email,
string, integer).

>
> > <haform:root>
> > <user_name>What ever the user entered</user_name>
> > <user_email>The user email as entered</user_email>
> > </haform:root>
> >
> > The haform:root could be renamed to something else using the
> > haform:name attribute.  In addition processing instructions can be
> > added to the resulting document.
> >
> > If the form fails the validation the original document is modified to
> > add haform:error attributes that describe the error and text nodes are
> > added that contain the input values from the POST.
>
> I think this forms stuff is very important and I've been thinking about
> it for a long time. What you did as a solution is hard-code the
> functionality that you need into a processor. It would be better to have
> it in an XSP taglib, because then it would be easier to extend it (and
> port it to Cocoon2). Your functionality sounds pretty cool, but it is
> IMHO far from complete. But putting this stuff in an XSP taglib is only
> a better solution, not a good solution, which is why I have never
> produced such a taglib. Even though I have very complicated workflows
> and forms to support, but doing it manually is still easier to manage
> than a half-baked packaged solution.

> What we really need is XML-Schema support for the data model and
> validation and some kind of model to represent workflows, UIs and
> perhaps applications. The current XForms W3C proposal doesn't address
> this. Cocoon2 tries to provide some answers, but when the going gets
> tough it makes everything proprietary (sitemap, flowmap(?), linkmap(?)).

XForms goes far than XML-Schema for the data model representation. As I said
before the XML Schema is not enough for it. Also, XForms have a good
extendable UI description mechanism and it is quite enough in most cases.
What it does not address is the workflow and application representations.
But it is not the XForms purpose.
One thing is bad with XForms - it has no implementations (or maybe I don't
know?).

>
> Every time this discussion comes up I mention Schemox, these guys are
> doing the right thing in spirit. In practice I think their
> implementation is (at this point) too complicated to use, but I'm sure
> that, given some time, this will be a great product.

I don't like SchemoX in its current state - it's too complicated to use and
requires a lot of programming while several things could be done
declaratively. But they have workflows and application. And they have a
working implementation.

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


---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message