struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luis Arias" <l...@elysia.com>
Subject Re: [PROPOSAL] New Struts Configuration File Format
Date Sun, 10 Sep 2000 12:49:04 GMT

----- Original Message -----
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
To: <struts-dev@jakarta.apache.org>
Sent: Friday, September 08, 2000 6:53 PM
Subject: Re: [PROPOSAL] New Struts Configuration File Format

>
> That's certainly an interesting approach to the problem.  I can see that
the
> "design time" stuff might be going overboard, but see below.
>

Sure, its a more complex approach, but it fits in with the way I see
projects being
built, at least here...  There is an impedence problem between web design
and web
application...

> By the way, do current generation browsers do the right thing if you send
them
> XHTML right now?
>

Craig, I'm no expert on this but I tested this with a fairly
graphics oriented web site using tools like w3c's HtmlTidy and the results
are encouraging.  I had no problems with the xhtml code in either IE5 or
NS4.7...

>
> There is one element of form beans that sort of overlaps "design time"
versus
> "run time", and that is when we start talking about specifying
validations.  We
> need something at run time so that the action servlet knows what
validations to
> enforce automatically, and so that the custom tags can (optionally)
generate
> appropriate JavaScript code to do client side checks as well when that is
> feasible.  And, at a minimum, we need to know the Java class name so we
can
> instantiate the correct bean.
>
> How do we provide this sort of information if we totally banish form beans
from
> the config file?

I think the answer to this depends on the way client-side or server-side
validation
will take place.  I agree that what would be very cool would be a process
similar to
JSP page compilation on the fly.  So in that case you would effectively need
a description
of this at run-time.  If you think about this on a conceptual level, there
is another
of "navigational constraints" that it would be cool to specify, i.e., an
order on
the way pages are brought up (I must have gone to page A before going to B).
 There are probably many others, for instance there may be a relationship
between
some form fields for which you would want to generate client-side code to
enforce.
Let's say some input field shoudl always be the total of two others,
something like that.

What would be really cool is to have the possibility to use different
languages to
specify these constraints by using a language attribute in the tag.  For
instance, java
or javascript for server-side constraints, javascript for client-side, OCL
(object
constraint language) for server-side or client-side constraints that could
be
automatically generated in java or javascript, etc...

I recently saw on the argo/uml site that there is an OCL to java generator
written in java that
is open-source (I don't remember what license).  This is an interesting
possibility
since it could mean the possibility of accepting input from UML modeling
tools as
far as these type of constraints are concerned.

I think we need to find a format that could withstand changes with respect
to these type
of evolutions, even if they are not likely to be integrated into the
framework any time soon
(well, who knows... ;-).  Maybe simply separating these interface-type
constraints from the
description of the dynamics of the site (action.xml) would be warranted
(validation.xml ?).
But I'm not sure....

Luis.


Mime
View raw message