Re: "`javascript' is not supported as a JSP scripting language."

I think you raise some interesting points, and with the rise of
client-side javascript it might be worth it for Caucho to resurrect
its server-side impl.

In the meantime, I can think of two alternatives you might have a look
at.  have you looked at XForms?  There's a truly amazing product
called Orbeon:

 http://www.orbeon.com/ops/

which is putting together a server-side XForms based framework.  You
can write an entire application declaratively, as it were, by defining
XML processing pipelines and hooking them up on the front end to an
XForms processor.

I took a look at it a while back and was impressed.  But it's pretty
much an all or nothing deal.  You use OPS instead of a "normal" app
framework, rather than in addition to it.  There are probably ways (I
got about 60% of the way there, I think, before I punted) to integrate
OPS into a standard J2EE webapp, but it's not straightforward.

The other alternative of course is Cocoon.  They actually do include a
server side javascript interpreter, and they use it not just for
validation (in fact, I don't know that it's used at all for
validation) but for flow control through the webapp.

JavaJosh <[email protected]> writes:

> Mattias Jiderhamn wrote:
>> JavaJosh wrote:
>>> This is changing with the rise of 'AJAX' websites. ... My goal is
>>> to execute the same form validation code on the client and on the
>>> server.
>> The point with AJAX is that you call the server code (Java) from the
>> client side, rather than using the client side code (JavaScript) on
>> the server.
>
> Consider a hypothetical application that consists purely of a set of
> URLs, each of which which take an XML request and return
> something. These endpoints should not trust that the caller is
> correctly sending those XML requests, and therefore each requires
> validation checking. It is valuable to tell the client that an error
> is being committed as soon as possible, so we move that logic closer
> to the client. Currently this consists of writing validation code in
> two languages(or 3 or 4 or 5 if you consider XML Schema or DTDs or
> custom validation markup to be languages) each of which must be
> independently maintained. It would be valuable to use the same code
> insofar as possible in both places. In a perfect world that code would
> be in Java, but we must make due for the least common denominator:
> JavaScript.
>
> An alternative is to use a 3rd validation rule representation which
> can be used to generate code in the desired target language. AFAIK
> this is the idea behind the Eclipse Modeling Framework. As neat as
> this sounds, it seems like a better idea is to use the ubiquity of
> JavaScript.
>
>
>
>

-- 

joe