You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Luis Arias <lu...@elysia.com> on 2000/09/10 10:25:58 UTC
Localized default values in form beans...
Hello !
I am confronted with the following problem in using struts for which I have
identified a possible solution. I would like the community's comments on
this and any suggestions on other alternatives.
The problem is that I would like to be able to show localized default values
for form properties the first time a user brings up a particular page. I
would like to do this using a straightforward mechanism that integrates
appropiately into the framework.
The reason why it is difficult to do this now, is because there is currently
no relationship between an ActionForm and the user's session. Furthermore,
the bean is instanciated automagically by the ActionServlet using a noarg
constructor when handling a form submission. This makes it difficult to
have form property values that are localized since the form bean does not
have a handle on the user's locale.
One solution to this would be to decide that ActionForm's must be
instanciated using a constructor that accepts the user's locale as an
argument, and implement this behavior with the accessor methods in an
ActionFormBase abstract class. The createFormInstance() method in
ActionMappingBase would have to be modified to call the appropiate
constructor using reflection instead of simply calling newInstance(). This
way, an ActionForm could count on having access to a "locale" instance
variable when retrieving localized content.
The reason for doing this in the constructor is in order not to interfere
with the
population of the form bean's properties, although this may not be an issue
since the locale instance variable would not be of type String. An
alternative
would be to define a setLocale(Locale locale) method in the ActionForm
interface which would be implemented in the ActionFormBase class.
Both of these solutions raise compatibility issues with existing code...
It also comes across my mind that there might be a general need for
different parts of the framework to access others, so it might be worthwhile
to think about a StrutsContext convenience class (kind of like a PageContext
for jsp's) which could be used to pass this sort of stuff around (locale,
session, request, etc...) in a simple uniform manner.
I'm ready to implement the "locale" solution, but will need some help in
designing a StrutsContext if that is what needs to be done. What should we
do here ? Are there any other alternatives which I haven't seen ?
Thanks,
--
Luis Arias
Elysia - http://www.elysia.com
1, rue de Stockholm
75008 PARIS
FRANCE
+33 1 44 70 70 90
+33 1 44 70 72 09 fax
+33 6 14 20 87 93 mobile
Re: Localized default values in form beans...
Posted by Luis Arias <lu...@elysia.com>.
Richard,
I really like the Validator abstraction... That sounds like a necessary
step to me in order to
be able to introduce client or server side validation in various programming
languages.
I think if you really wanted to have an extensible form validation mechanism
though, part of your xml could look a bit more like this:
<form name="testForm" formClass="nz.co.sew.test.TestForm"
attribute="testForm" scope="request">
<validator ref="password" field="passwordTest"/>
<validator ref="nullable-integer" field="nullInteger"/>
</form>
That is, really restrict yourself to a description of how to validate the
form by, for instance, leaving out fields which are not involved in
validation. A way to setup the date field validation could go something
like this:
<form>
<validator ref="ThreePartDateValidator" dayField="dayOfBirth"
monthField="monthOfBirth" yearField="yearOfBirth"/>
</validator>
</form>
or
<form>
<validator ref="MandatoryValidator">
<field name="firstName"/>
<field name="lastName"/>
<field name="email"/>
</validator>
</form>
What would be really cool would be to be able to write the validators
(anonymous ?) in some programming language like in Craig's proposal:
<form>
<validator language="javascript" tier="client">
if (form.email.value.length == 0) {
alert("email is mandatory.");
return false;
}
return true;
</validator>
</form>
Even further, specify the contraint in a general constraint language (ocl ?,
xschema ?)
and have the code be generated by struts:
<form>
<validator language="ocl" tier="client">
self.email.length() = 0
</validator>
</form>
So should we plan on doing something like this ? Craig ?
Luis.
----- Original Message -----
From: "Richard Vowles" <rv...@sew.co.nz>
To: <st...@jakarta.apache.org>
Sent: Sunday, September 10, 2000 11:22 AM
Subject: Re: Localized default values in form beans...
>
> I have decided to handle this differently in my struts variant. Given our
> conversations about struts and some I had with my own local discussion
group
> (www.esperanto.org.nz) we modified the mechanism.
>
> Currently struts does something like this
>
> request -> actionservlet
> -> populate bean
> -> (maybe) call validate on the validating form,
redirect
> to input form if bad
> -> call action
> -> call jsp
>
> We now do the following
>
> request -> actionservlet
> -> for each field specified in the form, call the validator with the
> request object
> -> if no errors call action object
> -> redirect to jsp
>
> The validator has three methods:
> checkvalid
> getdisplayname
> getfieldname
>
> (the entire framework now outputs everything in XML rather than HTML and
has
> XSL post-processing capability, or is at least on the way towards it!)
>
> the validators are passed the field, the form, the locale and so forth.
when
> they do checking, they do it as per the locale rules.
>
> each validator can have extra parameters which can be set up in the XML
> allowing one validator to meet many needs. It will eventually support
> javascript as well (only so much time in a day!). The data type of the
field
> is stored in the validator rather than the field - making the validator
more
> like a type than a validator i suppose. fields can be listed as mandatory,
> and thus enforced to have a value.
>
> The other point about the validator getting passed the request object -
this
> is because i wanted the validator to be able to support an arbitrarily
> complex object. For example, if you wanted to create a
> ThreePartDateValidator - which actually created and validated three fields
> as a single unit, then the validator has that capability. I haven't
written
> one to test out how well it works <sigh>. The idea is to also deal with
> lists but that is also a planned thing. Validators also receive the error
> object and can output the fact that a particular field is in error and
what
> the error message was that was associated with that field (error messages
> are locale resolved before putting them into the error messages object so
> they can support parameters).
>
> I have also made the decision that jsp's are all centralised in one thing
> called a View and everything is accessed by that now - this also means
there
> is a special taglib for links that includes the session state if requested
> as part of the framework. It is just a decision at the moment!
>
> Its a bit icky at the moment as it is designed to be part of a seminar,
but
> i'm happy to share ideas as I go along the route.
>
> But the validator concept takes care of my locale problems by validating
> according to the locale.
>
> The action.xml now looks a little like:
>
> <action-mappings>
> <view name="v_Test2" path="/test2.jsp"/>
> <view name="v_Test" path="/test.jsp"/>
>
> <validator name="nullable-integer"
> validatorClass="nz.co.sew.synkronicity.validator.IntegerValidator">
> <validator-property property="defaultValue" value="0"/>
> <validator-property property="emptyIfZero" value="true"/>
> </validator>
>
> <validator name="password"
> validatorClass="nz.co.sew.synkronicity.validator.BasicStringValidator">
> <validator-property property="fieldType" value="PASSWORD"/>
> </validator>
>
> <form name="testForm" formClass="nz.co.sew.test.TestForm"
> attribute="testForm" scope="request">
> <field id="textTest" size="30"/>
> <field id="passwordTest" size="20" validator="password"/>
> <field id="nullInteger" size="10" validator="nullable-integer"/>
> </form>
>
> <action actionName="testFormAction" path="testFormAction"
> actionClass="nz.co.sew.test.TestAction"
> formName="testForm" inputView="v_Test">
> <forward name="success" view="v_Test2"/>
> </action>
>
> </action-mappings>
>
> ----- Original Message -----
> From: "Luis Arias" <lu...@elysia.com>
> To: <st...@jakarta.apache.org>
> Sent: Sunday, September 10, 2000 8:25 PM
> Subject: Localized default values in form beans...
>
>
> > Hello !
> >
> > I am confronted with the following problem in using struts for which I
> have
> > identified a possible solution. I would like the community's comments
on
> > this and any suggestions on other alternatives.
> >
> > The problem is that I would like to be able to show localized default
> values
> > for form properties the first time a user brings up a particular page.
I
> > would like to do this using a straightforward mechanism that integrates
> > appropiately into the framework.
> >
> > The reason why it is difficult to do this now, is because there is
> currently
> > no relationship between an ActionForm and the user's session.
> Furthermore,
> > the bean is instanciated automagically by the ActionServlet using a
noarg
> > constructor when handling a form submission. This makes it difficult to
> > have form property values that are localized since the form bean does
not
> > have a handle on the user's locale.
>
>
Re: Localized default values in form beans...
Posted by Richard Vowles <rv...@sew.co.nz>.
I have decided to handle this differently in my struts variant. Given our
conversations about struts and some I had with my own local discussion group
(www.esperanto.org.nz) we modified the mechanism.
Currently struts does something like this
request -> actionservlet
-> populate bean
-> (maybe) call validate on the validating form, redirect
to input form if bad
-> call action
-> call jsp
We now do the following
request -> actionservlet
-> for each field specified in the form, call the validator with the
request object
-> if no errors call action object
-> redirect to jsp
The validator has three methods:
checkvalid
getdisplayname
getfieldname
(the entire framework now outputs everything in XML rather than HTML and has
XSL post-processing capability, or is at least on the way towards it!)
the validators are passed the field, the form, the locale and so forth. when
they do checking, they do it as per the locale rules.
each validator can have extra parameters which can be set up in the XML
allowing one validator to meet many needs. It will eventually support
javascript as well (only so much time in a day!). The data type of the field
is stored in the validator rather than the field - making the validator more
like a type than a validator i suppose. fields can be listed as mandatory,
and thus enforced to have a value.
The other point about the validator getting passed the request object - this
is because i wanted the validator to be able to support an arbitrarily
complex object. For example, if you wanted to create a
ThreePartDateValidator - which actually created and validated three fields
as a single unit, then the validator has that capability. I haven't written
one to test out how well it works <sigh>. The idea is to also deal with
lists but that is also a planned thing. Validators also receive the error
object and can output the fact that a particular field is in error and what
the error message was that was associated with that field (error messages
are locale resolved before putting them into the error messages object so
they can support parameters).
I have also made the decision that jsp's are all centralised in one thing
called a View and everything is accessed by that now - this also means there
is a special taglib for links that includes the session state if requested
as part of the framework. It is just a decision at the moment!
Its a bit icky at the moment as it is designed to be part of a seminar, but
i'm happy to share ideas as I go along the route.
But the validator concept takes care of my locale problems by validating
according to the locale.
The action.xml now looks a little like:
<action-mappings>
<view name="v_Test2" path="/test2.jsp"/>
<view name="v_Test" path="/test.jsp"/>
<validator name="nullable-integer"
validatorClass="nz.co.sew.synkronicity.validator.IntegerValidator">
<validator-property property="defaultValue" value="0"/>
<validator-property property="emptyIfZero" value="true"/>
</validator>
<validator name="password"
validatorClass="nz.co.sew.synkronicity.validator.BasicStringValidator">
<validator-property property="fieldType" value="PASSWORD"/>
</validator>
<form name="testForm" formClass="nz.co.sew.test.TestForm"
attribute="testForm" scope="request">
<field id="textTest" size="30"/>
<field id="passwordTest" size="20" validator="password"/>
<field id="nullInteger" size="10" validator="nullable-integer"/>
</form>
<action actionName="testFormAction" path="testFormAction"
actionClass="nz.co.sew.test.TestAction"
formName="testForm" inputView="v_Test">
<forward name="success" view="v_Test2"/>
</action>
</action-mappings>
----- Original Message -----
From: "Luis Arias" <lu...@elysia.com>
To: <st...@jakarta.apache.org>
Sent: Sunday, September 10, 2000 8:25 PM
Subject: Localized default values in form beans...
> Hello !
>
> I am confronted with the following problem in using struts for which I
have
> identified a possible solution. I would like the community's comments on
> this and any suggestions on other alternatives.
>
> The problem is that I would like to be able to show localized default
values
> for form properties the first time a user brings up a particular page. I
> would like to do this using a straightforward mechanism that integrates
> appropiately into the framework.
>
> The reason why it is difficult to do this now, is because there is
currently
> no relationship between an ActionForm and the user's session.
Furthermore,
> the bean is instanciated automagically by the ActionServlet using a noarg
> constructor when handling a form submission. This makes it difficult to
> have form property values that are localized since the form bean does not
> have a handle on the user's locale.