cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: Flow and XMLForm
Date Tue, 21 May 2002 12:46:41 GMT

----- Original Message -----
From: "Ovidiu Predescu" <ovidiu@apache.org>
To: "Ivelin Ivanov" <ivelin@apache.org>
Cc: <cocoon-dev@xml.apache.org>
Sent: Tuesday, May 21, 2002 1:04 AM
Subject: Re: Flow and XMLForm

> > Just a note in regard to client/server side validation.
> > New generation browsers support XSLT.
> > Which means that Schemtron validation can be run on the client as well.
> > Haven't tried it myself.
>
> Yes, but that doesn't solve the problem for current browsers that
> don't support XSLT (Opera, Konqueror? etc.), or for older browsers,
> which support JavaScript only, or WAP, iMode, and many other browsers
> integrated in small devices. IMO Cocoon should be able to reach these
> not so mainstream browsers as well. And do a good job at supporting
> them, by providing the their users with the best possible user
> experience.

True.
You probably remember that some weeks ago we discussed the strategic
direction for XMLForm.
There were 2 options. To provide a full implementation of XForms including
validation and events
or to provide a subset which can be implemented on the server side.
There were 2 complete implementations known, both of which were relying on
heavy JavaScript use.
The script that the browser loads and runs for every XForms page was so big
that only a handful of
power browsers could deal with it.
This is why we opted for a server side subset which will be client agnostic,
although not as responsive
as a solution which uses all available browser capabilities.
Jakarta Struts is an example of a big and successful project (which XMLForm
borrows ideas from),
which is a server side implementation only. There is a pending task on the
Struts todo list for over a year
now for implementing validation rules which can be rendered on the client.
The fact that implementation is still not provided probably means that this
is a task too hard to take on
and solve in a framework.

>
> > I am speculating that XML standards will be better supported in the long
run
> > than ECMAScript based languages.
>
> Supporting standards usually takes a very long time, you cannot assume
> everybody will support the latest standards. Even then, you still have
> to support older browsers that don't adhere to the latest
> standards. Just look at how many JavaScript versions and variations
> are in today's Web browsers; it's a total mess! Nevertheless, good
> service providers try to support them all.

Also True. I am just assuming (maybe wrong) that XSLT support will be more
consistent than
JavaScript, when its there.


Cheers,

Ivelin


>
>
> Regards,
> --
> Ovidiu Predescu <ovidiu@apache.org>
>
> >>> I'm in the job market again, check out my resume and qualifications
at:
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other
stuff)


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


Mime
View raw message