springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Code format tools Part II

[William G. T. Jr. <wg...@rc...>]

William G. Thompson, Jr. wrote:
> Tony Falabella wrote:
> 
>> BTW - I've tried to put hooks into CVS to have it run a program (using 
>> a filter like *.java) prior to commits to it.  While the hook appears 
>> to be there (and you'll see mention of being able to do this in the 
>> documentation for CVS), the code within CVS has actually been 
>> commented out.  What will happen is you'll get an error like 
>> "Unimplemented in this version of CVS, consult the reference guide."
>> Apparently they added this functionality to CVS, found it was too 
>> buggy for some platforms/files/etc. so rather than take it out they 
>> just now return that msg above.  Someone has a workaround for it, but 
>> it doesn't seem recommended.  Thus my ANT suggestion.
>>
> 
> Folks,
> 
> some suggestions:
> 1) agree on source formating and post the eclipse settings
> 2) agree to _not_ reformat other ppls code just for the sake of 
> reformatting
> 3) let social mechanisms or our benefical dictator take care of source 
> formating issues
I really mean let social mechanisms or our beneficial dictator take care 
of enforcement. (as opposed to some software imposed mechanism that will 
complicate the process)

> 4) keep it simple ;)
> 
> Cheers,
> Bill
> 

Re: [Springframework-developer] Code format tools Part II

[William G. T. Jr. <wg...@rc...>]

Tony Falabella wrote:
> BTW - I've tried to put hooks into CVS to have it run a program (using a 
> filter like *.java) prior to commits to it.  While the hook appears to 
> be there (and you'll see mention of being able to do this in the 
> documentation for CVS), the code within CVS has actually been commented 
> out.  What will happen is you'll get an error like "Unimplemented in 
> this version of CVS, consult the reference guide." 
> 
> Apparently they added this functionality to CVS, found it was too buggy 
> for some platforms/files/etc. so rather than take it out they just now 
> return that msg above.  Someone has a workaround for it, but it doesn't 
> seem recommended.  Thus my ANT suggestion.
> 

Folks,

some suggestions:
1) agree on source formating and post the eclipse settings
2) agree to _not_ reformat other ppls code just for the sake of reformatting
3) let social mechanisms or our benefical dictator take care of source 
formating issues
4) keep it simple ;)

Cheers,
Bill

-- 
William G. Thompson, Jr.
Associate Director of New Technologies
Administrative Computing Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wth...@ac...

Re: [Springframework-developer] Code formatting tools

[Tony F. <ton...@ya...>]

Yes, this can also be done with Jalopy, and it use variable substitution in the creation of it.  It also has features to get rid of headers that are currently out there if you know some key word to look for in the old headers.  
Example header from Jalopy is:

//==============================================================================// file :       $fileName$// project:     $project$//// last change: date:       $Date$//              by:         $Author$//              revision:   $Revision$//------------------------------------------------------------------------------// copyright:   BSJT Software License (see class documentation)//==============================================================================

Send over the new header file to the group and I'll incorporate it in the Jalopy format file. 
 Rod Johnson <rod...@in...> wrote:Tony,

Could we use this to put in a new standard header, as the existing one is
out of date?

Yann is producing a new header.

Regards,
Rod

----- Original Message -----
From: "Tony Falabella" 
To: "Rod Johnson" ;

Sent: Friday, February 28, 2003 3:59 PM
Subject: Re: [Springframework-developer] Code formatting tools


>
> I will make a beautify template and change Ant script to incorporate
formatting to our template. Should have this done by early week (hopefully
Monday).
> Rod Johnson wrote:Tony,
>
> Using such a beautifier would definitely be valuable. One of the most
> important benefits would be that diffs are guaranteed to be meaningful, as
> you point out. Also each developer could reformat files they work on in
> their IDE to their preferred conventions before committing in our standard
> way.
>
> All developers should run Ant before doing a CVS check in to ensure that
the
> test suite succeeds, so I think it's fine to have the formatting applied
via
> Ant.
>
> I haven't used Jalopy. However, I did look around online a couple of weeks
> ago for work and it seemed like a good tool.
>
> Would you like to try to produce a Jalopy config file and send it too me
> with a modified build.xml so that I can look at the results?
>
> Yann is producing a coding conventions document, but I imagine
> beautification will only affect things we already all agree on. Basically
I
> would like to keep the canonical version of the source formatted as now.
>
> My preferences:
> - Formatting with { on same line, but a new line for a catch, as presently
> in source code
> - ordering and delimitation as described in chapter 4 and applied in most
> source. //-----------Implementation of X interface might be hard to do,
> though. I assume if the developer had already put that in Jalopy wouldn't
> necessarily completely reorder the file?
> - I prefer tabs but most people prefer spaces, so I guess Jalopy could
> settle on (3?) spaces, as they're allegedly better for CVS diffs
>
> In general I think we should follow ordering conventions as we write code,
> so maybe we don't want Jalopy to change that.
>
> I think CVS triggers are generally agreed not to work.
>
> Regards,
> Rod
>
> > Just wanted to bounce this off of you and the group. What do you think
of
> the developers using a code beautification tool before checking anything
> into the repos?
> >
> > One of the things I'm struggling with is I am very carefree when I code
> with my indentation. Why? I use a code beautifier before I save my code.
> When making modifications to the framework however, it is not a good idea
to
> run classes I'm changing through a code beautifier because it will shuffle
> things around from what they were so much that it will be difficult to see
> the small diffs that might have been made to a file.
> >
> > Here's my suggestion. Integrate Jalopy
> (http://sourceforge.net/projects/jalopy) into the ANT build scripts either
> when a build is done, or when the tests are run. Jalopy is opensource, is
> very configurable, and has pluggins for all the major IDEs and ANT. A very
> nice feature is that you can save the formatting configuration you like
for
> it in an XML file that you would then distribute with the build file.
> Assuming all developers run ANT before checking things into CVS, their
files
> will all conform to the format you like. (It also allows for putting
> separator lines for things like constructors, static vars, instance vars,
> etc - as you seem to advocate in your book).
> >
> > This will make it a lot easier to see minor changes that are made from
> each iteration of code checked in.
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Validation usage examples and questions

[John C. <oo...@ro...>]

Hey everyone,

I have a class called NewUserRegistrationRequest which is a simple
javabean that will transport the data submited by a user from a webpage
(not implemented yet) to my business object. My business object has a
method called registerUser(NewUserRegistrationRequest request) which
handles this use case.

My dilema is how to handle syntatic and semantic validation for this
particular use case which will most likelly dictate how I handle things
in other use cases.

The validations that I need are
1) making sure the Request object is properlly initiallized and that
none of the properties are null
2) making sure that username is unique
3) making sure that email address is unique
4) username and password length rules
5) making sure that an email address looks like an email address
6) making sure that a default user access level is assigned to this new
user
7) * allow for futher rules to be defined without a huge impact in the
application. For example, I may want to have a rule which sends out an
email to the new user in order to validate the registration at a later
date.

The way I see it, 1,4 and 5 are syntatic rules and 2,3, and 6 are
semantic rules (to use the terms in the book)

Some other requirments would be to allow for internatiolization of
messages, and it would be nice to also have javascript generated or
associated with this validation, so that both client side and server
side validation could be done if wanted. With this last requirement,
it's not really something I desire. I personaly do not trust client side
validation, so I usualy do all validation on the server side. So if I
don't get to that, its no big deal.

These validations should hopefully only occour in once place. But what
is that place? The validator interface looks like it's where I should
start but I don't completly understand how it should work overall.
Should I invoke this validator in my business method? My thoughts tell
me yes that that's what I should be doing. But what about sending errors
out from the validator back to calling code without "poluting" my
business interfaces? How would that work?

Any ideas suggestions or comments would be greatly appriciated.

Thanks,
John

Re: [Springframework-developer] Code formatting tools

[Rod J. <rod...@in...>]

Tony,

Could we use this to put in a new standard header, as the existing one is
out of date?

Yann is producing a new header.

Regards,
Rod

----- Original Message -----
From: "Tony Falabella" <ton...@ya...>
To: "Rod Johnson" <rod...@in...>;
<spr...@li...>
Sent: Friday, February 28, 2003 3:59 PM
Subject: Re: [Springframework-developer] Code formatting tools


>
> I will make a beautify template and change Ant script to incorporate
formatting to our template.  Should have this done by early week (hopefully
Monday).
>  Rod Johnson <rod...@in...> wrote:Tony,
>
> Using such a beautifier would definitely be valuable. One of the most
> important benefits would be that diffs are guaranteed to be meaningful, as
> you point out. Also each developer could reformat files they work on in
> their IDE to their preferred conventions before committing in our standard
> way.
>
> All developers should run Ant before doing a CVS check in to ensure that
the
> test suite succeeds, so I think it's fine to have the formatting applied
via
> Ant.
>
> I haven't used Jalopy. However, I did look around online a couple of weeks
> ago for work and it seemed like a good tool.
>
> Would you like to try to produce a Jalopy config file and send it too me
> with a modified build.xml so that I can look at the results?
>
> Yann is producing a coding conventions document, but I imagine
> beautification will only affect things we already all agree on. Basically
I
> would like to keep the canonical version of the source formatted as now.
>
> My preferences:
> - Formatting with { on same line, but a new line for a catch, as presently
> in source code
> - ordering and delimitation as described in chapter 4 and applied in most
> source. //-----------Implementation of X interface might be hard to do,
> though. I assume if the developer had already put that in Jalopy wouldn't
> necessarily completely reorder the file?
> - I prefer tabs but most people prefer spaces, so I guess Jalopy could
> settle on (3?) spaces, as they're allegedly better for CVS diffs
>
> In general I think we should follow ordering conventions as we write code,
> so maybe we don't want Jalopy to change that.
>
> I think CVS triggers are generally agreed not to work.
>
> Regards,
> Rod
>
> > Just wanted to bounce this off of you and the group. What do you think
of
> the developers using a code beautification tool before checking anything
> into the repos?
> >
> > One of the things I'm struggling with is I am very carefree when I code
> with my indentation. Why? I use a code beautifier before I save my code.
> When making modifications to the framework however, it is not a good idea
to
> run classes I'm changing through a code beautifier because it will shuffle
> things around from what they were so much that it will be difficult to see
> the small diffs that might have been made to a file.
> >
> > Here's my suggestion. Integrate Jalopy
> (http://sourceforge.net/projects/jalopy) into the ANT build scripts either
> when a build is done, or when the tests are run. Jalopy is opensource, is
> very configurable, and has pluggins for all the major IDEs and ANT. A very
> nice feature is that you can save the formatting configuration you like
for
> it in an XML file that you would then distribute with the build file.
> Assuming all developers run ANT before checking things into CVS, their
files
> will all conform to the format you like. (It also allows for putting
> separator lines for things like constructors, static vars, instance vars,
> etc - as you seem to advocate in your book).
> >
> > This will make it a lot easier to see minor changes that are made from
> each iteration of code checked in.
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] New stuff in CVS

[<jue...@we...>]

Hi Springies,

I've finally committed some changes and enhancements that I've proposed:

- BeanFactory inheritance instead of ApplicationContext inheritance, =
mainly to allow for bean references to application context beans in =
controller servlet config files;

- reworked validation, now one Errors instance per bind object + empty =
Errors instance even for form view + global errors + multiple errors per =
field + rewritten tags + the new BindUtils class for simple retrieving =
in JSP expressions;

- reworked BaseCommandController + FormController + =
SessionFormController, for easier and more flexible form controller =
implementations;

- defaultParentView property in ResourceBundleViewResolver (+ according =
defaultParentBean property in AbstractBeanFactory) that allows for =
specifying a default parent instead of mentioning "viewname.parent=3D" =
for every view mapping (e.g. the parent can specify a view class that =
gets used for all views that do not override it, in case of one dominant =
view type);

- more flexible startup: refactored ContextLoader + ContextLoaderServlet =
+ ContextLoaderListener, default context class, no message prerequisite;

- LocaleResolver for explicit locale setting, with implementations for =
accept header, session, and cookie;

- JstlView implementation, exposing Spring's message source and user =
locale to JSTL tags;

- modified build script, using individual J2EE interface libraries in =
lib/j2ee instead of a J2EE RI now.

I encourage everyone to download the current version, and try and check =
the new stuff. Feedback is very welcome! :-)

My next steps will be 2 more of my proposals:

- multipart request handling aka file upload: MultipartResolver + =
implementations for Jason Hunter's COS and Jakarta's Commons FileUpload;

- adding a utility class for HTML escaping, and appropriate support =
within Spring's web functionality (e.g. message output, form values, =
form errors).

Regards,
Juergen

[Springframework-developer] HTML escaping

[<jue...@we...>]

Does anyone know about restrictions concerning HTML escaping? AFAIK, any =
text written to JSPs or Velocity templates that produce HTML content =
needs to get escaped. Thus, Spring's JSP tags could escape implicitly =
when returning messages, form values, and form errors - in case of =
content type HTML.

I wonder how we could ease things for JSP expressions and Velocity =
templates, in terms of implicit escaping. The model itself should be =
HTML-agnostic, so we need a solution specific to HTML views. Maybe wrap =
the WebApplicationContext and Errors instances accordingly, in an HTML =
view implementation? Any thoughts?

Juergen

Re: [Springframework-developer] Code formatting tools

[Tony F. <ton...@ya...>]

I will make a beautify template and change Ant script to incorporate formatting to our template.  Should have this done by early week (hopefully Monday).
 Rod Johnson <rod...@in...> wrote:Tony,

Using such a beautifier would definitely be valuable. One of the most
important benefits would be that diffs are guaranteed to be meaningful, as
you point out. Also each developer could reformat files they work on in
their IDE to their preferred conventions before committing in our standard
way.

All developers should run Ant before doing a CVS check in to ensure that the
test suite succeeds, so I think it's fine to have the formatting applied via
Ant.

I haven't used Jalopy. However, I did look around online a couple of weeks
ago for work and it seemed like a good tool.

Would you like to try to produce a Jalopy config file and send it too me
with a modified build.xml so that I can look at the results?

Yann is producing a coding conventions document, but I imagine
beautification will only affect things we already all agree on. Basically I
would like to keep the canonical version of the source formatted as now.

My preferences:
- Formatting with { on same line, but a new line for a catch, as presently
in source code
- ordering and delimitation as described in chapter 4 and applied in most
source. //-----------Implementation of X interface might be hard to do,
though. I assume if the developer had already put that in Jalopy wouldn't
necessarily completely reorder the file?
- I prefer tabs but most people prefer spaces, so I guess Jalopy could
settle on (3?) spaces, as they're allegedly better for CVS diffs

In general I think we should follow ordering conventions as we write code,
so maybe we don't want Jalopy to change that.

I think CVS triggers are generally agreed not to work.

Regards,
Rod

> Just wanted to bounce this off of you and the group. What do you think of
the developers using a code beautification tool before checking anything
into the repos?
>
> One of the things I'm struggling with is I am very carefree when I code
with my indentation. Why? I use a code beautifier before I save my code.
When making modifications to the framework however, it is not a good idea to
run classes I'm changing through a code beautifier because it will shuffle
things around from what they were so much that it will be difficult to see
the small diffs that might have been made to a file.
>
> Here's my suggestion. Integrate Jalopy
(http://sourceforge.net/projects/jalopy) into the ANT build scripts either
when a build is done, or when the tests are run. Jalopy is opensource, is
very configurable, and has pluggins for all the major IDEs and ANT. A very
nice feature is that you can save the formatting configuration you like for
it in an XML file that you would then distribute with the build file.
Assuming all developers run ANT before checking things into CVS, their files
will all conform to the format you like. (It also allows for putting
separator lines for things like constructors, static vars, instance vars,
etc - as you seem to advocate in your book).
>
> This will make it a lot easier to see minor changes that are made from
each iteration of code checked in.
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Code formatting tools

[Rod J. <rod...@in...>]

Tony,

Using such a beautifier would definitely be valuable. One of the most
important benefits would be that diffs are guaranteed to be meaningful, as
you point out. Also each developer could reformat files they work on in
their IDE to their preferred conventions before committing in our standard
way.

All developers should run Ant before doing a CVS check in to ensure that the
test suite succeeds, so I think it's fine to have the formatting applied via
Ant.

I haven't used Jalopy. However, I did look around online a couple of weeks
ago for work and it seemed like a good tool.

Would you like to try to produce a Jalopy config file and send it too me
with a modified build.xml so that I can look at the results?

Yann is producing a coding conventions document, but I imagine
beautification will only affect things we already all agree on. Basically I
would like to keep the canonical version of the source formatted as now.

My preferences:
- Formatting with { on same line, but a new line for a catch, as presently
in source code
- ordering and delimitation as described in chapter 4 and applied in most
source. //-----------Implementation of X interface might be hard to do,
though. I assume if the developer had already put that in Jalopy wouldn't
necessarily completely reorder the file?
- I prefer tabs but most people prefer spaces, so I guess Jalopy could
settle on (3?) spaces, as they're allegedly better for CVS diffs

In general I think we should follow ordering conventions as we write code,
so maybe we don't want Jalopy to change that.

I think CVS triggers are generally agreed not to work.

Regards,
Rod

> Just wanted to bounce this off of you and the group.  What do you think of
the developers using a code beautification tool before checking anything
into the repos?
>
>  One of the things I'm struggling with is I am very carefree when I code
with my indentation.  Why?  I use a code beautifier before I save my code.
When making modifications to the framework however, it is not a good idea to
run classes I'm changing through a code beautifier because it will shuffle
things around from what they were so much that it will be difficult to see
the small diffs that might have been made to a file.
>
> Here's my suggestion.  Integrate Jalopy
(http://sourceforge.net/projects/jalopy) into the ANT build scripts either
when a build is done, or when the tests are run.  Jalopy is opensource, is
very configurable, and has pluggins for all the major IDEs and ANT.  A very
nice feature is that you can save the formatting configuration you like for
it in an XML file that you would then distribute with the build file.
Assuming all developers run ANT before checking things into CVS, their files
will all conform to the format you like.  (It also allows for putting
separator lines for things like constructors, static vars, instance vars,
etc - as you seem to advocate in your book).
>
> This will make it a lot easier to see minor changes that are made from
each iteration of code checked in.
>

[Springframework-developer] Code format tools Part II

[Tony F. <ton...@ya...>]

BTW - I've tried to put hooks into CVS to have it run a program (using a filter like *.java) prior to commits to it.  While the hook appears to be there (and you'll see mention of being able to do this in the documentation for CVS), the code within CVS has actually been commented out.  What will happen is you'll get an error like "Unimplemented in this version of CVS, consult the reference guide."  

Apparently they added this functionality to CVS, found it was too buggy for some platforms/files/etc. so rather than take it out they just now return that msg above.  Someone has a workaround for it, but it doesn't seem recommended.  Thus my ANT suggestion.

[Springframework-developer] Code formatting tools

[Tony F. <ton...@ya...>]

Rod,

I am a few days away from checking in the ErrorCoded stuff.  I've made a few changes, and incorporated your feedback into what I have.  My changes will include now allowing Exceptions to be generated either from a "string" (already "resolved"), or from an errorCode +errorArgs+locale.  I will email you all code to review before making any changes in the repos.

Just wanted to bounce this off of you and the group.  What do you think of the developers using a code beautification tool before checking anything into the repos? 

 One of the things I'm struggling with is I am very carefree when I code with my indentation.  Why?  I use a code beautifier before I save my code.  When making modifications to the framework however, it is not a good idea to run classes I'm changing through a code beautifier because it will shuffle things around from what they were so much that it will be difficult to see the small diffs that might have been made to a file.

Here's my suggestion.  Integrate Jalopy (http://sourceforge.net/projects/jalopy) into the ANT build scripts either when a build is done, or when the tests are run.  Jalopy is opensource, is very configurable, and has pluggins for all the major IDEs and ANT.  A very nice feature is that you can save the formatting configuration you like for it in an XML file that you would then distribute with the build file.  Assuming all developers run ANT before checking things into CVS, their files will all conform to the format you like.  (It also allows for putting separator lines for things like constructors, static vars, instance vars, etc - as you seem to advocate in your book).

This will make it a lot easier to see minor changes that are made from each iteration of code checked in.

[Springframework-developer] BeanFactory / ApplicationRegistry / Arrays

[Trevor C. <tc...@in...>]

Is it possible to load a bean which has an object array property?  If so,
are there any examples?  A simple example of the type of thing I'd like to
do (based on the books TestBean example from pg400) is to give Rod kids :).
Create a child-bean with only nam and age properties, and give Rod an array
of them.  Then populate Rod with 3 kids using the bean factory (as shown on
pg403).  I've been playing with this for quite a while, and am hitting a
brick wall.

Thanks for any help,
Trevor D. Cook


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Struts (and Re: ErrorCoded/MessageSource)

[<jue...@we...>]

> I agree, there's lots of stuff there, and things we can learn
> from. However, wrt the dispatch action, our=20
> com.interface21.web.servlet.mvc.multiaction.MultiActionControl
> ler does the same thing but is much more powerful.

I'm perfectly aware, of course :-)

What I meant regarding dispatch actions was that Struts 1.1 allows for =
form handling within dispatch actions, i.e. "someAction(request, =
response, form)"-like method signatures. We currently only support the =
"someAction(request, response)"-style, accompanied by =
"someHandler(request, response, exception)-style exception handlers. The =
drawback of Struts 1.1 is that it actually enforces form handling with =
dispatch actions, just like it generally treats every request as a form.

I rather look at Struts in terms of different approaches. For example, =
we don't really need "modules", as we support multiple =
ControllerServlets anyway, which I consider significantly clearer and =
more flexible. It's just that there might be some special functionality =
in Struts that Spring can't provide currently, even if the basic issue =
is addressed.

On the other hand, no new feature should sacrify Spring's clear =
architecture, just for the sake of convenience. We should try to find a =
balance in that respect.

Juergen

RE: [Springframework-developer] Changes to jdbc.object.StroredPro cedure class

[Trevor C. <tc...@in...>]

I'd prefer the first method ("isFunction") since there is already a
SqlFunction class so StoredFunction could get confusing.  It's good you
caught that (since Postgres is my primary db).  

With the SQLExceptionTranslator, I'm curious what you have planned,
especially with Postgres (since it doesn't use sqlstate / error codes).

I've been working on the jdbc.object test cases.  I can commit them tonight
and then fire off an email.

Trevor D. Cook


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: February 24, 2003 3:32 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Changes to
jdbc.object.StroredProcedure class


Guys,

I'm impressed with what Thomas has been doing, and I think he should be the
lead on the JDBC stuff. However, I know other people have contributions in
this area, so it's important we coordinate.

Yann, can you please drop a quick email to Thomas when you check your JDBC
stuff in? Maybe just forward one of your old emails to the P2P list?

Regards,
Rod

----- Original Message -----
From: "Thomas Risberg" <tri...@tr...>
To: <spr...@li...>
Sent: Monday, February 24, 2003 8:16 PM
Subject: [Springframework-developer] Changes to jdbc.object.StroredProcedure
class


> Hi guys,
>
> I have just joined the group and I'm really looking forward to working
> on this framework.  Great stuff so far.  I have e-mailed Rod with a few
> suggestions for the SQLExceptionTranslater functionality, we should be
> able to add some of the new features to CVS real soon.
>
> While testing the changes to the SQLTranslation logic on different
> databases I ran across a problem with using the StoredProcedure class
> from the jdbc.object package.
>
> It currently only supports the "{call my_proc(?, ?)}" syntax and this
> worked fine for procedures but not for stored functions.  With functions
> you have to use the following call syntax "{? = call my_func(?)}". Since
> all stored procedures in Postgres are declared as functions (CREATE
> FUNCTION ...) it was a problem.
>
> I came up with two solutions, and would like to know which one you would
> prefer.
>
> 1.  Add a boolean instance variable isFunction = false to the
> StoredProcedure.  This could be set to true if the call is to a function
> or left false if it is to a procedure.  Then the StoredProcedure could
> use the correct syntax while it is "compiling" the callString
>
> 2.  Create a StoredFunction class that does the same thing the current
> StoredProcedure does, except for the call syntax.  We could use
> sub-classing to avoid code duplication
>
> The first solution is simpler and less code, but maybe not as clear as
> the second one.
>
> This would be a good feature not only for Postgres, but for any database
> that supports the CREATE FUNCTION feature - Oracle, MS SQL, DB2 ...
>
> Let me know what you think.
>
> Also - is anybody working on any other parts of the jdbc package?  I'd
> be interested to look at other issues, but I don't want to solve/fix
> something that someone else is already looking at.
>
>
>  -- Thomas
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Changes to jdbc.object.StroredProcedure class

[Rod J. <rod...@in...>]

Guys,

I'm impressed with what Thomas has been doing, and I think he should be the
lead on the JDBC stuff. However, I know other people have contributions in
this area, so it's important we coordinate.

Yann, can you please drop a quick email to Thomas when you check your JDBC
stuff in? Maybe just forward one of your old emails to the P2P list?

Regards,
Rod

----- Original Message -----
From: "Thomas Risberg" <tri...@tr...>
To: <spr...@li...>
Sent: Monday, February 24, 2003 8:16 PM
Subject: [Springframework-developer] Changes to jdbc.object.StroredProcedure
class


> Hi guys,
>
> I have just joined the group and I'm really looking forward to working
> on this framework.  Great stuff so far.  I have e-mailed Rod with a few
> suggestions for the SQLExceptionTranslater functionality, we should be
> able to add some of the new features to CVS real soon.
>
> While testing the changes to the SQLTranslation logic on different
> databases I ran across a problem with using the StoredProcedure class
> from the jdbc.object package.
>
> It currently only supports the "{call my_proc(?, ?)}" syntax and this
> worked fine for procedures but not for stored functions.  With functions
> you have to use the following call syntax "{? = call my_func(?)}". Since
> all stored procedures in Postgres are declared as functions (CREATE
> FUNCTION ...) it was a problem.
>
> I came up with two solutions, and would like to know which one you would
> prefer.
>
> 1.  Add a boolean instance variable isFunction = false to the
> StoredProcedure.  This could be set to true if the call is to a function
> or left false if it is to a procedure.  Then the StoredProcedure could
> use the correct syntax while it is "compiling" the callString
>
> 2.  Create a StoredFunction class that does the same thing the current
> StoredProcedure does, except for the call syntax.  We could use
> sub-classing to avoid code duplication
>
> The first solution is simpler and less code, but maybe not as clear as
> the second one.
>
> This would be a good feature not only for Postgres, but for any database
> that supports the CREATE FUNCTION feature - Oracle, MS SQL, DB2 ...
>
> Let me know what you think.
>
> Also - is anybody working on any other parts of the jdbc package?  I'd
> be interested to look at other issues, but I don't want to solve/fix
> something that someone else is already looking at.
>
>
>  -- Thomas
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Changes to jdbc.object.StroredProcedure class

[Rod J. <rod...@in...>]

> 1.  Add a boolean instance variable isFunction = false to the
> StoredProcedure.  This could be set to true if the call is to a function
> or left false if it is to a procedure.  Then the StoredProcedure could
> use the correct syntax while it is "compiling" the callString
> 
> 2.  Create a StoredFunction class that does the same thing the current
> StoredProcedure does, except for the call syntax.  We could use
> sub-classing to avoid code duplication
> 
> The first solution is simpler and less code, but maybe not as clear as
> the second one.


I vote for 1. Simple and backward compatible.

Thanks for raising the issue.

Rod

[Springframework-developer] Changes to jdbc.object.StroredProcedure class

[Thomas R. <tri...@tr...>]

Hi guys,

I have just joined the group and I'm really looking forward to working
on this framework.  Great stuff so far.  I have e-mailed Rod with a few
suggestions for the SQLExceptionTranslater functionality, we should be
able to add some of the new features to CVS real soon.

While testing the changes to the SQLTranslation logic on different
databases I ran across a problem with using the StoredProcedure class
from the jdbc.object package.  

It currently only supports the "{call my_proc(?, ?)}" syntax and this
worked fine for procedures but not for stored functions.  With functions
you have to use the following call syntax "{? = call my_func(?)}". Since
all stored procedures in Postgres are declared as functions (CREATE
FUNCTION ...) it was a problem.  

I came up with two solutions, and would like to know which one you would
prefer.

1.  Add a boolean instance variable isFunction = false to the
StoredProcedure.  This could be set to true if the call is to a function
or left false if it is to a procedure.  Then the StoredProcedure could
use the correct syntax while it is "compiling" the callString

2.  Create a StoredFunction class that does the same thing the current
StoredProcedure does, except for the call syntax.  We could use
sub-classing to avoid code duplication

The first solution is simpler and less code, but maybe not as clear as
the second one.

This would be a good feature not only for Postgres, but for any database
that supports the CREATE FUNCTION feature - Oracle, MS SQL, DB2 ...

Let me know what you think.

Also - is anybody working on any other parts of the jdbc package?  I'd
be interested to look at other issues, but I don't want to solve/fix
something that someone else is already looking at.


 -- Thomas
 

Fw: [Springframework-developer] Struts (and Re: ErrorCoded/MessageSource)

[Rod J. <rod...@in...>]

Damn this reply-to!

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "jürgen höller [werk3AT]" <jh...@we...>
Sent: Monday, February 24, 2003 6:57 PM
Subject: Re: [Springframework-developer] Struts (and Re:
ErrorCoded/MessageSource)


> > Concerning Struts: Despite all of its shortcomings, Struts does have a
lot
> of features. I've had a detailed look at Struts 1.1b3 recently, especially
> analyzing Struts' way of doing things. There are some things worth looking
> at: dispatch actions, dynamic forms, error message handling, request
tokens,
> declarative validation, multipart request processing, "modules", Tiles
> integration.
>
> I agree, there's lots of stuff there, and things we can learn from.
However,
> wrt the dispatch action, our
> com.interface21.web.servlet.mvc.multiaction.MultiActionController does the
> same thing but is much more powerful.
>
> Rod
>

[Springframework-developer] File upload aka multipart request handling

[<jue...@li...>]

Hi everybody,

I'd like to communicate an idea that I've been thinking about for quite a
while. Currently hanging around at home being a bit sick, this is a good way
to use the time... ;-) Anyway, I've already raised the topic of utility
libraries on the Wrox forum some time ago, and I've done some research
since. The main issue is file upload aka multipart request handling.

There are currently 2 noteworthy reusable upload libraries:
- Jason Hunter's COS (com.oreilly.servlet): the classic, under Jason's "buy
my book" license;
- Jakarta's Commons FileUpload (currently 1.0 beta): a new alternative,
under the Apache license.

The latter is now the default implementation of Struts 1.1's
MultipartRequestHandler (alternatively, Struts still has the old 1.0
implementation, the simple DiskMultipartRequestHandler). COS may be older
and better tested, but Commons FileUpload is more sophisticated: For
example, it can keep uploaded files smaller than a specified threshold in
memory instead of writing everything temporarily to disk.

My goal is to support file upload within Spring's web package, in a
straightforward and pluggable way. The obvious way would be some multipart
check in ControllerServlet's doService method that exchanges the standard
HttpServletRequest with a wrapping MultipartServletRequest (an interface
derived from HttpServletRequest) if it detects a multipart request.
Controller implementations can check for a multipart request via "request
instanceof MultipartServletRequest", or simply cast to the class if they
expect one.

The following proposal for Spring's multipart handler interfaces is
obviously inspired by both COS' MultipartRequest and Commons FileUpload's
FileItem classes, so don't blame me! ;-) It should be easy to write
implementations for COS and Commons FileUpload that we could include out of
the box. Of course, we are only allowed to include Commons FileUpload in a
Spring distribution, in terms of license. Whoever wants to use COS could
simply download it, add it to his web app libraries, and configure affected
Spring controller servlets accordingly.

The MultipartServletRequest interface needs to support getParameter and
associated methods, to be able to handle simple parameters in a multipart
request transparently, just like when dealing with a normal request. For
file handling, I propose to add the following methods beyond
HttpServletRequest, analogous to parameter handling:
- MultipartFile getFile(String name)... returning a file descriptor for the
specified file, or null
- Map getFileMap()... returning a Map with file names as keys and
MultipartFile instances as values
- clearFileResources()... clearing all temporary file resources
(automatically called by ControllerServlet after Controller processing)

MultipartFile is an interface with the following methods:
- InputStream getInputStream()... returning an input stream with the
contents of the file
- String getFileName()... returning the original file name given by the
client
- String getContentType()... returning the content type given by the client

These should allow for both simple implementations and simple usage by
custom controller implementations. The interfaces could even be used by
JSPs, as the wrapped request will also be used when forwarding, although
that is not recommended practice. Normally, a custom upload controller will
evaluate the uploaded files and parameters, and transfer them to some
application-specific storage location that could be a filesystem or a
database. For application programmers, it is not important where the files
are stored temporarily or if they are stored on disk at all, therefore the
interfaces do not cover such aspects. Essentially, multipart handling should
be as easy and transparent as possible.

Finally, how will a ControllerServlet retrieve a MultipartServletRequest
instance, using the toolkit of the application's choice? A straightforward
Spring way would be to define a standard bean name "multipartResolver"
(analogous to "viewResolver" and "localeResolver") that needs to implement
the interface MultipartResolver:
- MultipartServletRequest createMultipartRequest(HttpServletRequest
request)... creating a wrapper
- boolean hasMultipartContent(HttpServletRequest request)... checking the
content type

Of course, ControllerServlet should simply ignore multipart handling when
there's no "multipartResolver" bean, maybe log a warning on initialization.

What do you think? If we settle on the proposal, I could implement it
promptly (right after locale resolution). I definitely consider file upload
a 1.0 issue, as both Struts and WebWork have built-in support for it.

Juergen


P.S.:

Concerning 2 other utility issues:

For FTP and other Internet protocols that are not supported with J2SE,
there's a new alternative too: Jakarta's Commons Net. I guess we won't need
special support for it withing Spring.

HTML escaping/unescaping: This is so fundamental and yet so simple that I've
always wondered about the lack of standard support for it. Not even Struts
1.1 does include a respective utility class. So everyone seems to write his
own... I'd like to include a HtmlUtils class providing static htmlEscape and
htmlUnescape methods in Spring's web.util package, if no one objects.

RE: [Springframework-developer] Explicit locales

[<rod...@in...>]

Trevor,

I agree that we don't need to let backward compatibility 
cause us to end up with a sub-optimal result for 1.0.

Regards,
Rod

RE: [Springframework-developer] Explicit locales

[Trevor C. <tc...@in...>]

What you wrote sounded right, and I think I understand what you are planning
now, and it should workwell.  Its just a much different implementation than
what I was thinking, so my own preconceived ideas were clouding my ability
to see your idea.  Anyway, the working code should reveal all. :)

On a more general note:
>>BTW, the time before 1.0 is still our greatest chance to get 
>>it right, without the burden of backward compatibility.
I totally agree, but want to make sure that everyone is on the same page.
My understanding is that whatever we choose for our "0.8" or "early access"
release is not guarenteed to be compatible with our 1.0 release.  We
obviously want to encourage people to start developing with it, but we won't
be burdened by backwards compatibility to support it.  If, for example, we
discover a glaring hole in the code, we can change it for 1.0 even if it
breaks any applications coded against 0.8.  Is this correct?

Trevor D. Cook


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Explicit locales

[<jh...@we...>]

VHJldm9yLA0KDQo8cXVvdGU+DQpXaGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgYW4gaW1wbGVtZW50
YXRpb24gYXMgZm9sbG93czogDQoNCnB1YmxpYyBpbnRlcmZhY2UgTG9jYWxlUmVzb2x2ZXIgeyAN
CiAgICAgICAgDQogICAgLy8gZ2V0IHRoZSBjdXJyZW50bHkgcmVzb2x2ZWQgbG9jYWxlIA0KICAg
IExvY2FsZSBnZXRMb2NhbGUoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QpOyANCg0KICAgIC8v
IHNldCB0aGUgbG9jYWxlIGZyb20gdGhlIGFwcGxpY2F0aW9uIGNvZGUgDQogICAgdm9pZCBzZXRM
b2NhbGUoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QsIEh0dHBTZXJ2bGV0UmVzcG9uc2UgcmVz
cG9uc2UsIExvY2FsZSBsb2NhbGUpOyANCg0KICAgIC8vIHJlc29sdmUgdGhlIGN1cnJlbnQgbG9j
YWxlIA0KICAgIHZvaWQgcmVzb2x2ZUxvY2FsZShIdHRwU2VydmxldFJlcXVlc3QgcmVxdWVzdCwg
SHR0cFNlcnZsZXRSZXNwb25zZSByZXNwb25zZSwgTG9jYWxlIGxvY2FsZSk7IA0KfQ0KPC9xdW90
ZT4NCg0KSSdtIG5vdCBzdXJlIHdoYXQgdGhlIHJlc29sdmVMb2NhbGUgbWV0aG9kIGlzIGZvci4g
WW91ciBnZXRMb2NhbGUgKD0gcmV0cmlldmVMb2NhbGUgaW4gbXkgbGF0ZXN0IHByb3Bvc2FsKSBy
ZXRyaWV2ZXMgdGhlIGN1cnJlbnQgbG9jYWxlLCBubyBtYXR0ZXIgaWYgc2V0IGluIGEgcHJldmlv
dXMgcmVxdWVzdCBvciBzZXQgZHVyaW5nIHByb2Nlc3NpbmcgdGhlIGN1cnJlbnQgcmVxdWVzdCBi
eSBhIHNldExvY2FsZSBjYWxsLiBzZXRMb2NhbGUgaXMgZXhhY3RseSBmb3IgY2hhbmdpbmcgdGhl
IHVzZXIncyBsb2NhbGUgdG8gYSBuZXcgbG9jYWxlIGluIGFwcGxpY2F0aW9uIGNvZGUsIGkuZS4g
aW4gYSBjdXN0b20gY29udHJvbGxlciBpbXBsZW1lbnRhdGlvbi4gQXMgZ2V0TG9jYWxlIHdpbGwg
cmV0dXJuIGEgbmV3IGxvY2FsZSBzZXQgZHVyaW5nIHByb2Nlc3NpbmcgdGhlIGN1cnJlbnQgcmVx
dWVzdCwgSSBzZWUgbm8gbmVlZCBmb3IgYW4gYWRkaXRpb25hbCByZXNvbHZlTG9jYWxlIG1ldGhv
ZCB3aXRoIDMgcGFyYW1ldGVycy4NCg0KPHF1b3RlPg0KVGhlIHByb2JsZW0gSSBzZWUgd2l0aCB0
aGlzIGlzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGlzIGZvcmNlZCB0byB1c2Ugd2hhdGV2ZXIgbWV0
aG9kIHdlIGRlZmluZSBpbiBvcmRlciB0byBjaGFuZ2UgbG9jYWxlcy4gIEZvciBleGFtcGxlLCB0
aGV5IHdvdWxkIGJlIHJlcXVpcmVkIHRvIGhhdmUgYSBxdWVyeSBwYXJhbWV0ZXIgbGlrZSAiP2xv
Y2FsZT1mckNBIi4NCjwvcXVvdGU+DQoNCldlIHJlYWxseSBtaWdodCBtaXN1bmRlcnN0YW5kIGVh
Y2ggb3RoZXIuIE5vLCB3ZSB3b3VsZG4ndCBuZWVkIHN1Y2ggYSBzdGFuZGFyZCBxdWVyeSBwYXJh
bWV0ZXIgb3IgdGhlIGxpa2UgYXQgYWxsLiBDdXN0b20gY29udHJvbGxlciBpbXBsZW1lbnRhdGlv
bnMgY2FuIGNhbGwgTG9jYWxlUmVzb2x2ZXIuc2V0TG9jYWxlIGFueSB0aW1lIHRoZXkgd2FudCwg
b24gd2hhdGV2ZXIgb2NjYXNpb24gdGhhdCBkZW1hbmRzIGl0LCBkdWUgdG8gd2hhdGV2ZXIgcGFy
YW1ldGVyIHRoZXkgY29uc2lkZXIgZml0LiBBbiBleGFtcGxlOg0KDQpwdWJsaWMgY2xhc3MgTG9j
YWxlQ2hhbmdlQ29udHJvbGxlciBpbXBsZW1lbnRzIENvbnRyb2xsZXIsIExvY2FsZVJlc29sdmVy
QXdhcmUgew0KDQogICAgcHJpdmF0ZSBMb2NhbGVSZXNvbHZlciBsb2NhbGVSZXNvbHZlcjsNCg0K
ICAgIHB1YmxpYyBMb2NhbGVSZXNvbHZlciBnZXRMb2NhbGVSZXNvbHZlcigpIHsNCiAgICAgICAg
cmV0dXJuIHRoaXMubG9jYWxlUmVzb2x2ZXI7DQogICAgfQ0KDQogICAgLy8gcHJvcGFnYXRlZCB0
byB0aGlzIGNvbnRyb2xsZXIgYnkgQ29udHJvbGxlclNlcnZsZXQgdmlhIEhhbmRsZXJBZGFwdGVy
DQogICAgcHVibGljIHZvaWQgc2V0TG9jYWxlUmVzb2x2ZXIoKSB7DQogICAgICAgIHRoaXMubG9j
YWxlUmVzb2x2ZXIgPSBsb2NhbGVSZXNvbHZlcjsNCiAgICB9DQoNCiAgICBwdWJsaWMgTW9kZWxB
bmRWaWV3IGhhbmRsZVJlcXVlc3QoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QsIEh0dHBTZXJ2
bGV0UmVzcG9uc2UgcmVzcG9uc2UpIHsNCiAgICAgICAgU3RyaW5nIG5ld0xhbmd1YWdlID0gcmVx
dWVzdC5nZXRQYXJhbWV0ZXIoIm5ld0xhbmd1YWdlIik7DQogICAgICAgIGdldExvY2FsZVJlc29s
dmVyKCkuc2V0TG9jYWxlKHJlcXVlc3QsIHJlc3BvbnNlLCBuZXcgTG9jYWxlKG5ld0xhbmd1YWdl
LCAiIikpOw0KICAgIH0NCn0NCg0KQWZ0ZXIgZXhlY3V0aW9uIG9mIHN1Y2ggYSBDb250cm9sbGVy
IGluc3RhbmNlLCBDb250cm9sbGVyU2VydmxldCB3aWxsIGluIHR1cm4gY2FsbCB0aGUgTG9jYWxl
UmVzb2x2ZXIncyByZXNvbHZlTG9jYWxlKHJlcXVlc3QpIG1ldGhvZCB0byBkZXRlcm1pbmUgdGhl
IHZpZXcgbG9jYWxlIC0gYW5kIGNvcnJlY3RseSBwaWNrIHVwIHRoZSBuZXcgbG9jYWxlLiBCZWZv
cmUgaXRzIGV4ZWN1dGlvbiwgcmVzb2x2ZUxvY2FsZShyZXF1ZXN0KSB3b3VsZCByZXN1bHQgaW4g
dGhlIG9sZCBsb2NhbGUsIG9mIGNvdXJzZSAtIGJ1dCB0aGVyZSdzIG5vIG5lZWQgdG8gcmVzb2x2
ZSB0aGUgbG9jYWxlIHNvIGVhcmx5Lg0KDQo8cXVvdGU+DQpJJ20gbm90IHN1cmUgaWYgd2UgYXJl
IHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgdGhpbmcgYW5kIG5vdCB1bmRlcnN0YW5kaW5nIGVhY2gg
b3RoZXIsIG9yIGlmIHdlIGFyZSBhY3R1YWxseSB0YWxraW5nIGFib3V0IGRpZmZlcmVudCB0aGlu
Z3MuICBIb3dldmVyLCBJIHRoaW5rIHRoZSBvbmx5IHdheSBlaXRoZXIgb2YgdXMgY2FuIGJlIG1v
cmUgY2xlYXIgaXMgd2l0aCB3b3JraW5nIGNvZGUuICBZb3Ugc2VlbSB0byB1bmRlcnN0YW5kIHRo
ZSBpc3N1ZXMsIHNvIGp1c3QgY29kZSBpdCBob3cgeW91J3JlIHBsYW5uaW5nLiAgV29yc3QgY2Fz
ZSwgd2UganVzdCByZWZhY3RvciBhbnkgcHJvYmxlbXMgbGF0ZXIuDQo8L3F1b3RlPg0KDQpHb29k
IGlkZWEsIHdvcmtpbmcgY29kZSBpcyBwcm9iYWJseSBzdGlsbCB0aGUgYmVzdCB0aGluZyB0aGF0
IGRldmVsb3BlcnMgY2FuIGRpc2N1c3MgYWJvdXQhIEknbGwgaW1wbGVtZW50IGlzIEFTQVAgKE1v
bmRheSBvciBUdWVzZGF5LCBpZiBJIGRvbid0IGZhbGwgaWxsIC0gSSBkb24ndCBmZWVsIGdvb2Qg
Y3VycmVudGx5KSwgYW5kIHdlJ2xsIHNlZSB3aGVyZSB0aGUgZ2FwcyBhcmUsIGlmIGFueS4gTWF5
YmUgdGhlIGVsYWJvcmF0aW9uIGFib3ZlIGhhcyBoZWxwZWQsIGVsc2Ugd2UgcmVzb3J0IHRvIGNv
ZGUuIEJUVywgdGhlIHRpbWUgYmVmb3JlIDEuMCBpcyBzdGlsbCBvdXIgZ3JlYXRlc3QgY2hhbmNl
IHRvIGdldCBpdCByaWdodCwgd2l0aG91dCB0aGUgYnVyZGVuIG9mIGJhY2t3YXJkIGNvbXBhdGli
aWxpdHkuDQoNCkp1ZXJnZW4NCg0K

RE: [Springframework-developer] Explicit locales

[Trevor C. <tc...@in...>]

>>I've just been confused by your remarks quoted above: The first paragraph 
>>talks about a setLocale method without a locale parameter, and the third 
>>paragraph proposes a setLocale method with exactly a locale parameter.

What I was proposing was an implementation as follows:

public interface LocaleResolver {
	
	// get the currently resolved locale
	Locale getLocale(HttpServletRequest request);

	// set the locale from the application code
	void setLocale(HttpServletRequest request, HttpServletResponse
response, Locale locale);

	// resolve the current locale
	void resolveLocale(HttpServletRequest request, HttpServletResponse
response, Locale locale);
}


>>CookieLocaleResolver.resolveLocale has to look for such a request 
>>attribute before looking for a cookie. Thus, it will retrieve the 
>>new locale even if the request still contains the old locale cookie.
The problem I see with this is that the application is forced to use
whatever method we define in order to change locales.  For example, they
would be required to have a query parameter like "?locale=frCA".


I'm not sure if we are talking about the same thing and not understanding
each other, or if we are actually talking about different things.  However,
I think the only way either of us can be more clear is with working code.
You seem to understand the issues, so just code it how you're planning.
Worst case, we just refactor any problems later.

Trevor D. Cook

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Explicit locales

[<jh...@we...>]

VHJldm9yLA0KDQo8cXVvdGU+DQoNCkludGVyZmFjZSAtIHJlYWxseSBnb29kLCBidXQgSSBkb24n
dCB0aGluayBpdCdzIG5lY2Vzc2FyeSB0byBoYXZlIGxvY2FsZSBhcyBhIHBhcmFtZXRlciBvZiBz
ZXRMb2NhbGUsIHNpbmNlIHRoYXQgbWV0aG9kIHdpbGwgYmUgZGV0ZXJtaW5pbmcgdGhlIGFjdHVh
bCBsb2NhbGUuIFdoYXQgdmFsdWUgYmUgcGFzc2VkIGJ5IHRoZSBDb250cm9sbGVyU2VydmxldCBm
b3IgdGhpcyBwYXJhbWV0ZXI/ICBNYXliZSBpdCB3b3VsZCBiZSBsZXNzIGNvbmZ1c2luZyB0byBt
YWtlIHRoZSBzaWduYXR1cmU6DQoNCkxvY2FsZSByZXNvbHZlTG9jYWxlKEh0dHBTZXJ2bGV0UmVx
dWVzdCByZXF1ZXN0LCBIdHRwU2VydmxldFJlc3BvbnNlIHJlc3BvbnNlKTsgDQpUaGUgc2lnbmF0
dXJlIG5vdyBtYWtlcyBpdCBjbGVhciB0aGF0IHdlIGFyZSBub3QgInNldHRpbmcgaXQiIHNvIG11
Y2ggYXMgYXNraW5nIHRoZSBtZXRob2QgdG8gZGV0ZXJtaW5lIGhvdyBpdCBzaG91bGQgYmUgc2V0
LiAgSXQgYWxzbyBtYXRjaGVzIHRoZSB2aWV3UmVzb2x2ZXIgdXNhZ2UuIEFuIGFkZGl0aW9uYWwg
InNldExvY2FsZSIgbWV0aG9kIHdpdGggdGhlIHNpZ25hdHVyZSB5b3UgcHJvdmlkZWQ6DQoNCnZv
aWQgc2V0TG9jYWxlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0LCBIdHRwU2VydmxldFJlc3Bv
bnNlIHJlc3BvbnNlLCBMb2NhbGUgbG9jYWxlKTsgDQpjb3VsZCBiZSB1c2VkIHRvIGV4cGxpY2l0
bHkgb3ZlcnJpZGUgdGhlIExvY2FsZSBkZXRlcm1pbmVkIGJ5IHRoZSByZXNvbHZlTG9jYWxlIG1l
dGhvZC4gIFRoaXMgd291bGQgYmVuZWZpdCBDb250cm9sbGVyIHNwZWNpZmljIG92ZXJyaWRlcyAo
YWRkcmVzc2VkIGJlbG93KS4gIEFzIHlvdSBub3RlZCwgdGhlIHJlc3BvbnNlIGlzIG5lY2Vzc2Fy
eSBmb3IgY29va2llLWJhc2VkIGltcGxlbWVudGF0aW9ucyAoZ29vZCBjYXRjaCkuDQoNCjwvcXVv
dGU+DQoNCkkgYmVsaWV2ZSB3ZSBtZWFuIHRoZSBzYW1lIHRoaW5nLCBhYnNvbHV0ZWx5LiBJJ20g
cGVyZmVjdGx5IGF3YXJlIHRoYXQgd2UgbmVlZCBhIHNldExvY2FsZSBtZXRob2QgdG8gYmUgYWJs
ZSB0byBjaGFuZ2UgdGhlIGN1cnJlbnQgbG9jYWxlIGluIGFuIExvY2FsZVJlc29sdmVyLWltcGxl
bWVudGF0aW9uLWFnbm9zdGljIHdheSwgdGhhdCB3YXMgbXkgb3JpZ2luYWwgaW50ZW50LiBJJ3Zl
IGp1c3QgYmVlbiBjb25mdXNlZCBieSB5b3VyIHJlbWFya3MgcXVvdGVkIGFib3ZlOiBUaGUgZmly
c3QgcGFyYWdyYXBoIHRhbGtzIGFib3V0IGEgc2V0TG9jYWxlIG1ldGhvZCB3aXRob3V0IGEgbG9j
YWxlIHBhcmFtZXRlciwgYW5kIHRoZSB0aGlyZCBwYXJhZ3JhcGggcHJvcG9zZXMgYSBzZXRMb2Nh
bGUgbWV0aG9kIHdpdGggZXhhY3RseSBhIGxvY2FsZSBwYXJhbWV0ZXIuDQoNCkNvbmNlcm5pbmcg
eW91ciBpc3N1ZSBvZiB3aGljaCBsb2NhbGUgZ2V0cyB1c2VkIGZvciB0aGUgY3VycmVudCByZXF1
ZXN0IGlmIHRoZSBjb250cm9sbGVyIHByb2Nlc3NpbmcgdGhlIHJlcXVlc3QgY2hhbmdlcyB0aGUg
bG9jYWxlLiBMZXQncyBzdGljayB0byBhIExvY2FsZVJlc29sdmVyIGludGVyZmFjZSBsaWtlIHRo
ZSBvbmUgYmVsb3cgKGFuYWxvZ291cyB0byBteSBvcmlnaW5hbCBwcm9wb3NhbCwganVzdCBhZGFw
dGVkIG5hbWluZyk6DQoNCnB1YmxpYyBpbnRlcmZhY2UgTG9jYWxlUmVzb2x2ZXIgew0KDQogIExv
Y2FsZSByZXNvbHZlTG9jYWxlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0KTsNCg0KICB2b2lk
IHNldExvY2FsZShIdHRwU2VydmxldFJlcXVlc3QgcmVxdWVzdCwgSHR0cFNlcnZsZXRSZXNwb25z
ZSByZXNwb25zZSwgTG9jYWxlIGxvY2FsZSk7DQoNCn0NCg0KSSB1bmRlcnN0YW5kIHRoYXQsIHdp
dGggYSBDb29raWVMb2NhbGVSZXNvbHZlciwgaWYgeW91IHNldCBhIG5ldyBsb2NhbGUgY29va2ll
IG9uIHRoZSByZXNwb25zZSBpbiB0aGUgY3VycmVudCByZXF1ZXN0LCB0aGUgbG9jYWxlIHJlc29s
dXRpb24gZm9yIHRoZSBjdXJyZW50IHJlcXVlc3Qgd2lsbCBzdGlsbCByZXN1bHQgaW4gdGhlIGZv
cm1lciBvbmUgd2l0aG91dCBzcGVjaWFsIHRyZWF0bWVudC4gQlRXLCB0aGlzIHByb2JsZW0gY2Fu
bm90IG9jY3VyIHdpdGggc2Vzc2lvbi1iYXNlZCByZXNvbHV0aW9uLCBhcyB0aGUgcmVzb2x2ZUxv
Y2FsZSBtZXRob2Qgd291bGQgZmV0Y2ggdGhlIGZyZXNoIG5ldyBsb2NhbGUgZnJvbSB0aGUgc2Vz
c2lvbiBldmVuIGFmdGVyIGEgcHJlY2VkaW5nIHNldExvY2FsZSBjYWxsIGluIHRoZSBzYW1lIHJl
cXVlc3QuDQoNCkJ1dCBuZXZlcnRoZWxlc3MsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBwcm9k
dWNlIGNvcnJlY3QgYmVoYXZpb3Igd2l0aCBjb29raWUtYmFzZWQgcmVzb2x1dGlvbiBpbiB0aGlz
IGNhc2UuIFRvIGFjaGlldmUgdGhpcywgQ29va2llTG9jYWxlUmVzb2x2ZXIuc2V0TG9jYWxlIGhh
cyB0byBhZGQgYSByZXNwZWN0aXZlIGNvb2tpZSB0byB0aGUgcmVzcG9uc2UgYW5kIGEgcmVzcGVj
dGl2ZSBhdHRyaWJ1dGUgdG8gdGhlIHJlcXVlc3QgKHRoZSBuZXcgTG9jYWxlIHdpdGggYSBzcGVj
aWZpYyBhdHRyaWJ1dGUgbmFtZSkuIENvb2tpZUxvY2FsZVJlc29sdmVyLnJlc29sdmVMb2NhbGUg
aGFzIHRvIGxvb2sgZm9yIHN1Y2ggYSByZXF1ZXN0IGF0dHJpYnV0ZSBiZWZvcmUgbG9va2luZyBm
b3IgYSBjb29raWUuIFRodXMsIGl0IHdpbGwgcmV0cmlldmUgdGhlIG5ldyBsb2NhbGUgZXZlbiBp
ZiB0aGUgcmVxdWVzdCBzdGlsbCBjb250YWlucyB0aGUgb2xkIGxvY2FsZSBjb29raWUuDQoNCkV4
YW1wbGU6IEEgY29udHJvbGxlciBzZXRzIGEgbmV3IGxvY2FsZS4gTGF0ZXIgaW4gcHJvY2Vzc2lu
ZyB0aGUgc2FtZSByZXF1ZXN0LCBhZnRlciBleGVjdXRpb24gb2YgdGhlIGNvbnRyb2xsZXIgdGhh
dCBqdXN0IGNoYW5nZWQgdGhlIGxvY2FsZSwgQ29udHJvbGxlclNlcnZsZXQgY2FsbHMgcmVzb2x2
ZUxvY2FsZSB0byBkZXRlcm1pbmUgdGhlIHZpZXcgbG9jYWxlLiBJdCB3aWxsIHJldHJpZXZlIHRo
ZSBjb3JyZWN0IGxvY2FsZSwgYmVjYXVzZSByZXNvbHZlTG9jYWxlIHdpbGwgZmluZCBhIHJlcXVl
c3QgYXR0cmlidXRlIGNvbnRhaW5pbmcgdGhlIG5ldyBsb2NhbGUgYW5kIG5vdCBldmVuIGNoZWNr
IGNvb2tpZXMuDQoNCkkgaG9wZSBJIHVuZGVyc3Rvb2QgeW91ciByZXF1aXJlbWVudCBjb3JyZWN0
bHkuIElNTyB0aGUgYWJvdmUgbWVudGlvbmVkIGFsZ29yaXRobSB3aWxsIGxlYWQgdG8gY29ycmVj
dCByZXN1bHRzIGluIGFueSBjYXNlLiBCVFcsIEkgY29uc2lkZXIgdGhlIGFic3RyYWN0aW9uIGZh
aXJseSBwb3dlcmZ1bDogQ29udHJvbGxlciBpbXBsZW1lbnRhdGlvbnMgZG8gbm90IGhhdmUgdG8g
a25vdyB0aGUgbG9jYWxlIHJlc29sdXRpb24gbWVjaGFuaXNtIGF0IGFsbCwgdGhleSBkbyBub3Qg
aGF2ZSB0byBjYXJlIGFib3V0IHN1Y2ggdHJpY2tzLiBBbmQgdGhhbmtzIHRvIHRoZSBiZWFuIGZh
Y3RvcnksIExvY2FsZVJlc29sdmVyIGltcGxlbWVudGF0aW9ucyBjYW4gZWFzaWx5IGhhdmUgY29u
ZmlndXJhdGlvbiBwcm9wZXJ0aWVzLCBsaWtlIHRoZSBuYW1lIG9mIHRoZSBsb2NhbGUgY29va2ll
Lg0KDQpKdWVyZ2VuDQoNCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0g
DQoJVm9uOiBUcmV2b3IgQ29vayBbbWFpbHRvOnRjb29rQGludGVycHJpc2Vzb2Z0d2FyZS5jb21d
IA0KCUdlc2VuZGV0OiBTYSAyMi4wMi4yMDAzIDIxOjMwIA0KCUFuOiBTcHJpbmcgRGV2ZWxvcGVy
cyAoRS1tYWlsKSANCglDYzogDQoJQmV0cmVmZjogUkU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyXSBFeHBsaWNpdCBsb2NhbGVzDQoJDQoJDQoNCglUaGUgcmVhc29uIEkgaGFkIHNldExvY2Fs
ZSB3YXMgdG8gYWxsb3cgYSBDb250cm9sbGVyIGFjY2VzcyB0byBjaGFuZ2UgdGhlIGV4cGxpY2l0
IGxvY2FsZS4gIEkgdGhpbmsgdGhlIGVhc2llc3Qgd2F5IHRvIGV4cGxhaW4gdGhpcyBpcyB3aXRo
IG15IHVuZGVyc3RhbmRpbmcgb2YgaG93IHRoaXMgc2hvdWxkIHdvcmsgd2l0aCBhICJjb29raWUi
IGltcGxlbWVudGF0aW9uLg0KDQoJV2hlbiBhIHJlcXVlc3QgaXMgbWFkZSwgaXQgZ29lcyBpbnRv
IHRoZSBDb250cm9sbGVyU2VydmxldC4gIFRoZSBDb250cm9sbGVyU2VydmxldCB0aGFuIGNhbGxz
IHRoZSBDb29raWVMb2NhbGVSZXNvdmxlciByZXNvbHZlTG9jYWxlLiAgSW4gdGhlIHJlc29sdmUg
bWV0aG9kLCBpdCBsb29rcyBmb3IgYSBjb29raWUuICBJZiBpdCBleGlzdHMsIGl0IHNldHMgdGhl
IGxvY2FsZSB0byB0aGUgdmFsdWUgZnJvbSB0aGUgY29va2llLiAgSWYgaXQgZG9lc24ndCBleGlz
dCwgaXQgdXNlcyB0aGUgZGVmYXVsdCAoYnJvd3NlcikgbG9jYWxlIChmcm9tIHRoZSByZXF1ZXN0
IG9iamVjdCkuICBIb3dldmVyLCB0aGlzIG9ubHkgd29ya3MgaWYgdGhlIGNvb2tpZSBpcyBBTFJF
QURZIFNFVC4gIElmIHRoZXJlIGlzIG5vIGNvb2tpZSBpdCByZXNvcnRzIHRvIHRoZSBkZWZhdWx0
IGxvY2FsZS4NCg0KCVRoaXMgYnJpbmdzIHVwIGhvdyB0byBzZXQgdGhlIGNvb2tpZS4gIEZvciBt
eSBhcHBsaWNhdGlvbiwgSSB3aWxsIHByb2JhYmx5IGhhdmUgYSBxdWVyeSBzdHJpbmcgcGFyYW1l
dGVyIGFkZGVkIHRvIHRoZSB1cmwgZm9yIHRoZSBjdXJyZW50IHBhZ2UuICBUaGlzIG1lYW5zIHRo
YXQgaWYgeW91IGFyZSBvbiB0aGUgImFib3V0IiBwYWdlIGFuZCBjbGljayB0aGUgImZyZW5jaCIg
YnV0dG9uLCB5b3UgcmVjZWl2ZSB0aGUgZnJlbmNoIGFib3V0IHBhZ2UuICBTb21lYm9keSBlbHNl
IG1heSBoYXZlIGFuIGV4cGxpY2l0ICJmcmVuY2giIHVybCB3aGljaCByZXR1cm5zIGEgcGFnZSBz
YXlpbmcgInRoYW5rcyBmb3IgY2hvb3NpbmcgZnJlbmNoIi4gIEJlY2F1c2UgZGlmZmVyZW50IGFw
cGxpY2F0aW9ucyBtaWdodCBoYXZlIGRpZmZlcmVudCBtZXRob2RzIG9mIGFsbG93aW5nIHRoZSB1
c2VyIHRvIHNlbGVjdCB0aGUgbG9jYWxlLCB0aGV5IG5lZWQgdG8gYmUgYWJsZSB0byBzZXQgdGhl
IGNvb2tpZSAob3Igc2V0IHRoZSBzZXNzaW9uIHZhcmlhYmxlIGZvciB0aGUgb3RoZXIgaW1wbGVt
ZW50YXRpb24pLiBUbyBwcmV2ZW50IHRoaXMgcHJvYmxlbSwgd2UgY291bGQgZm9yY2UgYXBwbGlj
YXRpb25zIHRvIHVzZSBhIHNpbmdsZSBtZXRob2Qgb2Ygc2V0dGluZyB0aGUgbG9jYWxlLCBidXQg
SSBkb24ndCB0aGluayB0aGlzIGlzIGZsZXhpYmxlIGVub3VnaCwgc28gdGhpcyBicmluZ3MgdXMg
dG8gaG93IGEgQ29udHJvbGxlciB3b3VsZCBzZXQgdGhlIGxvY2FsZS4NCg0KCUlmIHdlIGRvbid0
IGhhdmUgYSAic2V0TG9jYWxlIiBtZXRob2QsIHdlIG5lZWQgdG8gZXhwb3NlIGludGVybmFsIGlt
cGxlbWVudGF0aW9uIGRldGFpbHMuICBJZiB5b3UgdXNlIGEgY29va2llIHZlcnNpb24sIHlvdSBu
ZWVkIHRvIGtub3cgdGhlIGNvb2tpZSBuYW1lIHVzZWQgYnkgdGhlIHJlc29sdmVyLCBjcmVhdGUg
dGhlIGNvb2tpZSwgYW5kIG1ha2Ugc3VyZSB0aGF0IHRoZSBsb2NhbGUgZm9yIHRoZSBDVVJSRU5U
IFJFUVVFU1QgYmVpbmcgaGFuZGxlZCB3aWxsIGJlIHVwZGF0ZWQgKHNlZSBleHBsYW5hdGlvbiBv
ZiB0aGlzIGJlbG93KS4gIEhvd2V2ZXIsIGEgc2Vzc2lvbiBpbXBsZW1lbnRhdGlvbiB3aWxsIG5l
ZWQgdG8ga25vdyB0aGUgbmFtZSBvZiB0aGUgc2Vzc2lvbiBhdHRyaWJ1dGUgdXNlZCBieSBpdHMg
cmVzb2x2ZXIsIGFkZCB0aGUgbG9jYWxlIHRvIHRoZSBzZXNzaW9uLCBhbmQgYWdhaW4gZW5zdXJl
IHRoZSBjdXJyZW50IHJlcXVlc3QgbG9jYWxlLiAgQmVjYXVzZSB0aGVzZSAyIGltcGxlbWVudGF0
aW9ucyBoYXZlIGRpZmZlcmVudCB3YXlzIG9mIGJlaW5nIHNldCwgdGhlIGNvbnRyb2xsZXIgd2hp
Y2ggc2V0cyB0aGVtIGlzIHRoZW4gYm91bmQgdG8gdGhlIHNwZWNpZmljIGltcGxlbWVudGF0aW9u
IChjb29raWUgLyBzZXNzaW9uKS4NCg0KCUlmIHdlIGhhdmUgYSAic2V0TG9jYWxlIiBtZXRob2Qs
IHRoZSBDb250cm9sbGVyIHNpbXBseSBjYWxscyB0aGUgaW50ZXJmYWNlIHNldExvY2FsZSBtZXRo
b2QsIGFuZCB0aGUgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gc2V0cyB0aGUgYXBwcm9wcmlhdGUg
Y29va2llIC9zZXNzaW9uLiAgVGhpcyBoYXMgdGhlIGJlbmVmaXQgb2YgYWxsb3dpbmcgZWFjaCBh
cHBsaWNhdGlvbiB0byBkZWNpZGUgaG93IHRvIGFsbG93IHVzZXJzIHRvIGV4cGxpY2l0bHkgc2V0
IGEgbG9jYWxlLCBidXQgZG9lcyBub3QgdGllIHRoZSBDb250cm9sbGVyIHRvIGEgc3BlY2lmaWMg
aW1wbGVtZW50YXRpb24uICBUaGlzIGFsc28gYWxsb3dzIHRoZW0gdG8gY2hhbmdlIGZyb20gYSBj
b29raWUgcmVzb2x2ZXIgdG8gYSBzZXNzaW9uIHJlc29sdmVyIGJ5IG1vZGlmeWluZyB0aGUgY2xh
c3MgaW4gdGhlIGNvbmZpZyBmaWxlIHdpdGhvdXQgdG91Y2hpbmcgY29kZS4NCg0KCUkgbWF5IGJl
IG1pc3VuZGVyc3RhbmRpbmcgaG93IHlvdSBwbGFuIHRvIGltcGxlbWVudCBpdCwgYnV0IHRoZSB3
YXkgSSB3b3VsZCBpbXBsZW1lbnQgaXQgaGFkIHRoZSBwcm9ibGVtIEkndmUganVzdCBkZXNjcmli
ZWQsIHByb21wdGluZyB0aGUgdGhpcmQgInNldExvY2FsZSIgbWV0aG9kLg0KDQoJQWJvdmUgSSBt
ZW50aW9uZWQgIm1ha2Ugc3VyZSB0aGF0IHRoZSBsb2NhbGUgZm9yIHRoZSBDVVJSRU5UIFJFUVVF
U1QgYmVpbmcgaGFuZGxlZCB3aWxsIGJlIHVwZGF0ZWQiLiAgV2hlbiBJIGRpZCBteSBwcm90b3R5
cGUgaW1wbGVtZW50YXRpb24sIEkgZm91bmQgdGhhdCBJIHdvdWxkIHNldCB0aGUgY29va2llIGFu
ZCB0aGVuIHJldHVybiBhIHBhZ2UsIGJ1dCB0aGUgbGFuZ3VhZ2Ugd291bGRuJ3QgY2hhbmdlLiAg
T24gcmV2aWV3IEkgbm90aWNlZCB0aGUgZm9sbG93aW5nIHNlcXVlbmNlIG9mIGV2ZW50cy4NCg0K
CSAgICAgICAgLSByZXF1ZXN0IHNlbnQgdG8gc2VydmxldCBjb250cm9sbGVyIA0KCSAgICAgICAg
LSBzZXJ2bGV0Q29udHJvbGxlciBjaGVja3MgZm9yIGNvb2tpZSBhbmQgc2V0cyBsb2NhbGUgDQoJ
ICAgICAgICAtIGNvbnRyb2xsZXIgY2hlY2tzIGlmIGxvY2FsZSBpbiBxdWVyeSBzdHJpbmcgYW5k
IHNldHMgY29va2llIA0KCSAgICAgICAgLSBjb250cm9sbGVyIHJldHVybnMgcGFnZSANCglCZWNh
dXNlIHRoZSBzZXJ2bGV0Q29udHJvbGxlciBzZXQgdGhlIGxvY2FsZSBiZWZvcmUgY29udHJvbGxl
ciBwcm9jZXNzaW5nLCBzZXR0aW5nIHRoZSBjb29raWUgZGlkbid0IGNoYW5nZSB0aGUgbG9jYWxl
IGZvciB0aGUgY3VycmVudCByZXF1ZXN0LiAgSWYgSSBtb3ZlZCB0aGUgc2VydmxldENvbnRyb2xs
ZXIgY2hlY2sgYWZ0ZXIgdGhlIGNvbnRyb2xsZXIgaXMgZG9uZSwgaXQgaXNuJ3QgYWJsZSB0byBk
byBhbnkgcHJvY2Vzc2luZyBiYXNlZCBvbiB0aGUgZXhwbGljaXRseSBzZXQgbG9jYWxlLiAgVGhp
cyBwb2ludGVkIG91dCBteSBvdmVyc2lnaHQgdGhhdCB3aGVuIEkgc2V0IHRoZSBjb29raWUgSSBh
bHNvIG5lZWQgdG8gdG8gc2V0IHRoZSBjdXJyZW50IGxvY2FsZSAoZXZlbiB0aG91Z2ggdGhlIHNl
cnZsZXRDb250cm9sbGVyIHByZXZpb3VzbHkgbWFkZSB0aGUgY2hlY2spLiAgVGhpcyBhbGxvd3Mg
Y29udHJvbGxlcnMgdG8ga25vdyB3aGljaCBsb2NhbGUgd2FzIGV4cGxpY2l0bHkgc2V0LCBidXQg
YWxzbyBhbGxvd3MgdGhlbSB0byBjaGFuZ2UgdGhhdCB2YWx1ZS4gIFlvdSBndXlzIG1heSBoYXZl
IHRob3VnaHQgb2YgdGhpcyBwcm9ibGVtIGFscmVhZHksIGJ1dCBpdCBjYXVnaHQgbWUgb2ZmIGd1
YXJkIChhbmQgY29zdCBtZSAyMCBtaW4gdG8gZmluZCB0aGUgc291cmNlIDooICkuDQoNCglUcmV2
b3IgRC4gQ29vaw0KDQo=

RE: [Springframework-developer] Explicit locales

[Trevor C. <tc...@in...>]

The reason I had setLocale was to allow a Controller access to change the
explicit locale.  I think the easiest way to explain this is with my
understanding of how this should work with a "cookie" implementation.

When a request is made, it goes into the ControllerServlet.  The
ControllerServlet than calls the CookieLocaleResovler resolveLocale.  In the
resolve method, it looks for a cookie.  If it exists, it sets the locale to
the value from the cookie.  If it doesn't exist, it uses the default
(browser) locale (from the request object).  However, this only works if the
cookie is ALREADY SET.  If there is no cookie it resorts to the default
locale.

This brings up how to set the cookie.  For my application, I will probably
have a query string parameter added to the url for the current page.  This
means that if you are on the "about" page and click the "french" button, you
receive the french about page.  Somebody else may have an explicit "french"
url which returns a page saying "thanks for choosing french".  Because
different applications might have different methods of allowing the user to
select the locale, they need to be able to set the cookie (or set the
session variable for the other implementation). To prevent this problem, we
could force applications to use a single method of setting the locale, but I
don't think this is flexible enough, so this brings us to how a Controller
would set the locale.

If we don't have a "setLocale" method, we need to expose internal
implementation details.  If you use a cookie version, you need to know the
cookie name used by the resolver, create the cookie, and make sure that the
locale for the CURRENT REQUEST being handled will be updated (see
explanation of this below).  However, a session implementation will need to
know the name of the session attribute used by its resolver, add the locale
to the session, and again ensure the current request locale.  Because these
2 implementations have different ways of being set, the controller which
sets them is then bound to the specific implementation (cookie / session).

If we have a "setLocale" method, the Controller simply calls the interface
setLocale method, and the specific implementation sets the appropriate
cookie /session.  This has the benefit of allowing each application to
decide how to allow users to explicitly set a locale, but does not tie the
Controller to a specific implementation.  This also allows them to change
from a cookie resolver to a session resolver by modifying the class in the
config file without touching code.

I may be misunderstanding how you plan to implement it, but the way I would
implement it had the problem I've just described, prompting the third
"setLocale" method.

Above I mentioned "make sure that the locale for the CURRENT REQUEST being
handled will be updated".  When I did my prototype implementation, I found
that I would set the cookie and then return a page, but the language
wouldn't change.  On review I noticed the following sequence of events.
	- request sent to servlet controller
	- servletController checks for cookie and sets locale
	- controller checks if locale in query string and sets cookie
	- controller returns page
Because the servletController set the locale before controller processing,
setting the cookie didn't change the locale for the current request.  If I
moved the servletController check after the controller is done, it isn't
able to do any processing based on the explicitly set locale.  This pointed
out my oversight that when I set the cookie I also need to to set the
current locale (even though the servletController previously made the
check).  This allows controllers to know which locale was explicitly set,
but also allows them to change that value.  You guys may have thought of
this problem already, but it caught me off guard (and cost me 20 min to find
the source :( ).

Trevor D. Cook

-----Original Message-----
From: jürgen höller [werk3AT] [mailto:jh...@we...]
Sent: February 22, 2003 1:57 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Explicit locales


Trevor,
 
The name "LocaleResolver" is fine, and naming the retrieval method
"resolveLocale" too, analogous to ViewResolver. But I'm not sure what you
mean concerning the setLocale method and its Locale parameter: We need a way
of telling the resolver that the user has chosen a specific locale - just
like you note in your 4th paragraph. I.e. one resolution method and one
modification method.
 
I also prefer the "viewResolver" bean reference, looked up by the
ControllerServlet, without individual LocaleResolver instances per
controller. Of course, controllers need a way to both retrieve and set the
current locale. So we should probably propagate the ControllerServlet's
LocaleResolver instance via HandlerMapping to Controller instances that
implement LocaleResolverAware (as I've already proposed), analogous to
ApplicationContext and ApplicationContextAware.
 
Concerning LocaleResolver implementations: Maybe call the default
implementation "BrowserSettingLocaleResolver"? And yes, we should provide a
"SessionLocaleResolver" and a "CookieLocaleResolver" out of the box.
 
I like that locale resolution support: fairly sophisticated, but still
reasonably simple!
 
Juergen
 
 

	-----Ursprüngliche Nachricht----- 
	Von: Trevor Cook [mailto:tc...@in...] 
	Gesendet: Sa 22.02.2003 17:30 
	An: spr...@li... 
	Cc: 
	Betreff: RE: [Springframework-developer] Explicit locales
	
	

	Naming - I agree that LocaleHandler is confusing. I like
LocaleResolver, since it is consistent with the the ViewResolver classes. 

	Interface - really good, but I don't think it's necessary to have
locale as a parameter of setLocale, since that method will be determining
the actual locale. What value be passed by the ControllerServlet for this
parameter?  Maybe it would be less confusing to make the signature:

	        Locale resolveLocale(HttpServletRequest request,
HttpServletResponse response); 
	The signature now makes it clear that we are not "setting it" so
much as asking the method to determine how it should be set.  It also
matches the viewResolver usage. An additional "setLocale" method with the
signature you provided:

	        void setLocale(HttpServletRequest request,
HttpServletResponse response, Locale locale); 
	could be used to explicitly override the Locale determined by the
resolveLocale method.  This would benefit Controller specific overrides
(addressed below).  As you noted, the response is necessary for cookie-based
implementations (good catch).

	Configuration - I think that loading it as a bean reference (like
"viewResolver") makes the most sense.  If we provide an access method, this
would allow individual Controllers to get a reference to the resolver and
override the locale using the setLocale method mentioned above.  I think the
ControllerServlet should handle the locale resolution rather than a
"LocaleHandler-per-Controller".  If someone needs "normal" locale handling,
I think the per-Controller method would require too much cut-n-paste type
code.  However, the exposed setLocale method would allow those who need to
set it on a per-Controller basis the ability to do so.

	DefaultImplementation - I think "ClientLocaleHandler" is too
general, since all LocaleHandlers (or LocaleResolvers as I prefer :) ) are
making decisions based on the client.  The default will be using the
servlets default mechanism, so maybe "ServletLocaleResolver" or
"RequestLocaleResolver" (although again, too me they're too general - I
can't think of a really good name).  We should also create additional
implementations for distribution such as the cookie and session based
versions, rather than requiring each client to code one themselves (although
they will have the oppurtunity to do so).

	Great analysis Juergen! 


	Trevor D. Cook 
	
	---
	Outgoing mail is certified Virus Free.
	Checked by AVG anti-virus system (http://www.grisoft.com).
	Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
	  

NHY޵隊X'u'$ح"wzyN\jkz+jw_bnWמv+h*.quڲ׫
"Z0.fj+xTD}k$뉩p
%v+\oy+䩮)~{
+ׯzZ)zXX*kxŠuޖ^X(~zwilqzlX)ߣ))~{
+ׯzZ)

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03