springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Spring sub-projects

[Ken K. <kk...@kk...>]

+1

Kopylenko, Dmitry wrote:

>Well, spring-rcp is a bit cryptic. How about spring-rich-client?
>
>-----Original Message-----
>From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
>Sent: Tuesday, February 17, 2004 8:04 AM
>To: spr...@li...
>Subject: RE: [Springframework-developer] Spring sub-projects
>
>
>Any opinions regarding the new module names? Else, I'll create "spring-r=
cp"
>and "spring-eclipse" in the course of this week.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf =
Of
>j=FCrgen h=F6ller [werk3AT]
>Sent: Monday, February 16, 2004 9:59 AM
>To: spr...@li...
>Subject: [Springframework-developer] Spring sub-projects
>
>
>Everybody,
>=20
>As recently discussed in private mails, I suggest to keep sub-projects t=
hat
>are close to the Spring core as separate modules in Spring's main CVS. T=
he
>first two candidates are:
>=20
>- Keith Donald's Spring Rich Client Platform
>- Torsten Juergeleit's Spring Eclipse Plugin
>=20
>Both Keith and Torsten are in favor of hosting them in our main CVS. So =
if
>noone objects, I will create new CVS modules "spring-rcp" and
>"spring-eclipse", and accordingly give Keith and Torsten commit rights f=
or
>the main CVS. As the module names cannot be changed easily, feel free to
>suggest different names!
>=20
>The rationale is to keep all projects that use "org.springframework" as
>package name in Spring's main CVS. Separate modules make sense to let th=
e
>sub-projects evolve independently; this way, they do not have to be rele=
ased
>in direct accordance with the Spring core. Of course, generic classes th=
at
>emerge can still go into the core.
>=20
>Consequently, both sub-projects should also get respective sections on o=
ur
>main website. We should definitely clarify all this before 1.0 final (Ma=
rch
>1st), as I expect quite a lot of media coverage at that time - we should=
n't
>miss that chance!
>=20
>Juergen
>=20
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> =20
>

Re: [Springframework-developer] ICQ

[<ad...@tr...>]

On 02-17-2004 9:41 +0000 Darren Davison <da...@da...> wrote:
>> Juergen, Thomas, Alef and I use Microsoft Messenger. It's good for audio
>> conversations, as well.
>
> indeed - assuming you use a micro$oft OS ;-)

Jabber! Jabber! Jabber! :-P

A.

-- 
Adam Sherman
Tritus CG Inc.
+1 (613) 797-6819
http://www.tritus.ca/

Re: [Springframework-developer] JdbcHelper

[Jonathan H. <jh...@ad...>]

Why not establish an interface that extends RowSet?

----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Monday, February 16, 2004 1:30 PM
Subject: Re: [Springframework-developer] JdbcHelper


> Thomas,
>
> Sounds great. With this there I'd be glad to get rid of JdbcHelper.
>
> Not sure about (3). I think this needs further thought. For 1.1 we could
add
> a true disconnected result set: not RowSet as it throws SQLException,
which
> we want to get away from.
>
> Also a convenience method returning int would be handy, for counts and the
> like. Please can I have this, despite Juergen's dislike of convenience
> methods :-)
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: <tri...@tr...>
> To: <spr...@li...>
> Sent: Monday, February 16, 2004 5:26 PM
> Subject: RE: [Springframework-developer] JdbcHelper
>
>
> > I can see the need to go beyond a single row/value type query.
> >
> > How about a new method for the JdbcTemplate:
> >
> > Object runSqlStatement(String)
> >
> > Based on the type of SQL passed in it would return:
> >
> > 1) An Integer containing the number of rows affected if it is an update
> statement
> >
> > runSqlStatement("update emp set salary = salary * 1.5") would return an
> Integer
> > with the update count
> >
> > 2) A single Object (Integer/Long/String) based on the value returned
from
> a
> > single value/single row query
> >
> > runSqlStatement("select last_name frmo emp where id = 2") would return a
> String
> > containing the last name
> >
> > 3) An ArrayList of ArrayLists containing a list of rows with a list of
> column
> > values returned by the query
> >
> > runSqlStatement("selecy id, last_name from emp") would return an
ArrayList
> > containing an ArrayList for each row.  The second list would contain an
> Integer
> > with the id and a String with the last_name.
> >
> >
> > Number 3 might be a stretch, but we would still have to check for this,
> since we
> > have no control over the SQL coming in.
> >
> > Thomas
> >
> >
> > Quoting rod...@in...:
> >
> > > I've actually just (yesterday) introduced into into a whole
> > > bunch of test cases at a client. Maybe we could put an
> > > improved runSQLFunction() method on JdbcTemplate? This is a
> > > very convenient one-liner, and basically the only reason I
> > > use JdbcTemplate.
> > >
> > > Regards,
> > > Rod
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > > Build and deploy apps & Web services for Linux with
> > > a free DVD software kit from IBM. Click Now!
> > > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Form View and Results View on same page issue.

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

>>I believe that the controller shouldn't have to be altered just because
it's returning to the same view
While this sounds good, the problem is there are 2 pieces, the model and
view.  You can use the same view by simply setting successView the same as
formView.  The issue is that other methods (like referenceData) are not
generating the model correctly.  While this is wrong in the scenario you
describe, generating the model for successView all the time would mean a
bloated model for the current usage where you are sending to a different
view.

Another simple way to handle this is to use "return showForm(...)" in the
onSubmit method.  I personally don't like this, mainly because you still
have extra baggage in the SimpleFormController that you aren't using.

I'll post my controller this afternoon.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of William Lyvers
Sent: February 17, 2004 8:40 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Form View and Results View on
same page issue.


First, you described the problem correctly.  The link you sent is the exact
scenario that I was describing.  When I first realized that
SimpleFormController wasn't going to support this type of page out of the
box, I looked at extended BaseCommandController as you have done.  I
resisted this mainly for 2 reasons.
1. As you mentioned, it was yet another FormController and I didn't thing it
was likely that it would be pulled back into Spring since there are already
about 5 flavors of controllers.  Arguably, there may already be too many
versions of controllers within the Framework.
2. Personally, I believe that the controller shouldn't have to be altered
just because it's returning to the same view.  I should be able to return a
success view string and not have to alter my subclass just because I am
reposting back to the same form.

In either case, this is such a common scenario I would hope that the Spring
Framework would support this out of the box by either another
CommandController as you have suggested or enhancing SimpleFormController as
I did in the first part of this thread.

Thanks,
Bill Lyvers

I would be very interested in seeing your SelfPostingFormController.  It is
probably a much simpler workflow since you know you are only working with
one view.


---------- Original Message ----------------------------------
From: "Trevor Cook" <tc...@in...>
Reply-To: spr...@li...
Date:  Mon, 16 Feb 2004 22:18:54 -0500

>It sounds like your problem is with the workflow of SimpleFormController.
>Before recommending an option, let me clarify what you are trying to do.
It
>sounds like it should be:
>
>- use posted bean to determine search params (if it exists - for "get" use
>default values of search-param bean)
>- return view with search results
>
>You don't need a "FormView"/"SuccessView", just a single view.  You also
>would need any "referenceData" like method to be called before returning
the
>view, regardless of get/post.  Is this a correct understanding of your
>problem?  If so, take a quick look at something I've implemented at
>http://www.fotosource.com/my_local_store.html .  Basically, the filters
>above the search results are constantly redisplayed with changing results
>underneath.  The form also works for an initial get request (with no search
>filters) and then successive posts (through the filter button).
>
>I implemented this by extending BaseCommandController
>(SimpleFormController's "grandfather").  You can probably simply implement
>what you're looking for by extending this class (or if necessary, step back
>another level to AbstractController).  I never contributed this class (I
>called it "SelfPostingFormController") because it was fairly simple to
>implement, and considering most custom apps functionality is "exactly like
>class X except for Y" I didn't want to bloat Spring.  Would this type of
>class be generally useful (or has another developer already snuck this in)?
>If multiple users want this I'll add it, otherwise I'll just post the code
>seperately for you to use.
>
>Trevor
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of wi...@ly...
>Sent: February 16, 2004 7:18 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Form View and Results View on
>same page issue.
>
>
>I posted this late last week but didn't get any bites -- maybe I'll try
>a different angle :).
>In short, I believe that the SimpleFormController should be enhanced to
>support posting results back to the originating form page.  The current
>implementation requires implementing classes to know they are returning
>back to the originating form page.  This limits the generic ability of
>wiring up views via IOC and getSuccessView() on SimpleFormHandler.
>Since this is such a common scenario, I was hoping this could be
>addressed prior to the 1.0 release.  Thoughts?
>
>Bill Lyvers
>
>
>wi...@ly... wrote:
>
>> I recently started using the web framework portion of Spring.  One
>> concept in particular has bitten me a couple of times and I have been
>> unable to determine a best practice.  The concept is how
>> SimpleFormHandler has a different workflow based on whether it is a
>> get request versus a post request.  This concept seemed very intuitive
>> and works fine if the post goes off to a result page.  However, below
>> is a scenario that I believe is quite common and SimpleFormHandler
>> doesn't seem to deal with it very elegantly.  The problem arises when
>> a page displays both a form and the results of a form post on the same
>> page.
>>
>> Scenario:
>> There is item search page with a item search form on the top and a
>> tabular view of the item search results below the search page.
>>
>> Example Controller:
>> public class ItemSearchController extends SimpleFormController {
>>    private ItemManager manager;
>>    public void setSearchManager(ItemManager manager) {
>>        this.manager = manager;
>>    }
>>    protected Map referenceData(HttpServletRequest request) throws
>> Exception {
>>        Map map = new HashMap();
>>        map.put( "itemTypes", manager.getItemTypes() );
>>        return map;
>>    }
>>    protected ModelAndView onSubmit(Object object) throws Exception {
>>        Item command = (Item)object;
>>        return new ModelAndView( getSuccessView(), "items",
>> manager.findItemsByExample( command ));
>>    }
>> }
>>
>> So, I request the page via /searchItem.htm which maps
>> ItemSearchController.  The "get" workflow works as usual --
>> referenceData gets called and the page displays fine.  The user
>> submits a search criteria which then goes through "post" workflow and
>> onSubmit gets called which returns a list of items via ModelAndView.
>> The successView now needs to return to the same page and this time the
>> results will be displayed below the form. However,
>>    1. If I forward back to /searchItem.htm, then I end up in an
>> infinite loop because the controller keeps processing it as a post.
>>    2. If I forward on to the jsp that displayed the form originally, I
>> will not go through the same workflow as when the page was first
>> loaded and referenceData won't get called. Not too mention that I'll
>> get an binding errors missing exception -- I saw that RC1 tried to
>> address this, but only if you don't override onsubmit.
>>
>> So, I decided to solve the problem with option 1 and cause the form to
>> realize that the post had already been handled and it must be a "get"
>> request being caused by a forward.  The main reason for this is that
>> the get workflow gets used when entering the page each.  To fix it, I
>> overrode isFormSubmission and set an attribute when a formSubmission
>> was recognized.  If this attribute already exists, it assumes that it
>> is a get request instead. Example:
>> protected boolean isFormSubmission(HttpServletRequest
>> httpServletRequest) {
>>        Object alreadySubmitted = httpServletRequest.getAttribute(
>> "formSubmission");
>>        if (alreadySubmitted != null) {
>>            return false;
>>        }
>>        boolean formSubmission =
>> super.isFormSubmission(httpServletRequest);
>>        if( formSubmission ) {
>>            httpServletRequest.setAttribute( "formSubmission",
>> Boolean.TRUE );
>>        }
>>        return formSubmission;
>> }
>>
>>
>> I am a surprised that SimpleFormController doesn't deal with this
>> scenario since it is so common or maybe I am missing something and it
>> does.   With the above code you can switch out the success view to go
>> to a seperate result page later by just changing the IOC
>> configuration.   Basically, your controller doesn't really need to
>> know that the results page is the same view as the form view.
>>
>> I am very curious on how others are dealing with this scenario and if
>> Spring deals with it and I have just overlooked it.
>>
>> Keep up the good work,
>> Bill Lyvers
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> Build and deploy apps & Web services for Linux with
>> a free DVD software kit from IBM. Click Now!
>> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] spring-rcp project

[Cameron B. <ca...@da...>]

Is there anywhere we can get this code from in the meantime.
 
I am really keen on having a look at the code for the rcp.
 
If not, I'll certainly check it out from the new module, when it arrives.
 
Thanks,
 
Cameron


  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Keith Donald
Sent: Tuesday, 17 February 2004 12:29 AM
To: spr...@li...
Subject: [Springframework-developer] spring-rcp project


There are several things initially I'd like to see the spring-rcp project
will provide:
 
- A way to build configurable, GUI-standards following Swing applications
faster by leveraging the Spring container and a rich library of UI factories
and support classes.
 
More specfically right now I have:
- A core action framework that allows for centralized configuration of Swing
actions and appropriate handler registration based on the current active
view.  Action configuration -- as well as action contribution policies (to
menus/toolbars), can be defined externally to the code as Spring bean
declarations.
- Multiple window support/management, page configuration, and view
management.  The ideas here are very much based on Eclipse's
perspective/view concepts.  Currently views can be defined in the Spring
container, associated with one or more pages, and a default page can be
configured to load at startup.
- Common support classes for various rich client requirements including:
dialogs, wizards, input validation, button bars, internationalization,
image/icon caching, progress monitoring, UI threading (aka classes promoting
responsive UIs), tree table/property sheet, table sorting/high-volume table
updates, GUI standards helpers, help/about, etc.
- Some basic support for persisting UI state and UI preferences (needs to be
developed further.)
 
I hope this provides some good background info on the project.  I see it
adding the most value to people needing to develop Swing applications and do
so in a way that promotes consistent, well-designed, configurable Swing
applications.  IMO Swing is more mature than Eclipse/SWT -- and does some
things better (for example, JTables can scale much better than SWT tables.)
I also think the old days of Swing apps 'not looking native' and not being
performant or web-accessible are gone with JDK 1.4.2 and 1.5 and webstart.
The main issue I see with Swing is there are a limited number of
higher-level abstractions/frameworks out there that assist in making the
toolkit simpler & easier to use, and a limited number of design best
practices.  The the goal of spring-rcp is to provide that.
 
Project dependencies to date:
- commons-lang
- jgoodies-forms
- TableLayout
- Spring (obviously) :-)
 
Keith
  

Re: [Springframework-developer] [PATCH] doc/reference/src/aop.xml

[Francois B. <fb...@us...>]

Hello Darren,

On Mon, 16 Feb 2004 23:14:51 +0000, "Darren Davison"
<da...@da...> said:
[snip]
> Don't mind applying the patch, but it will get overridden the next time=
=20
> anyone edits the file with XXE again and all the entity refs will
> re-appear=20
> which looks confusing if ever we need to track the CVS versioning.

Would you prefer that I resubmit a patch without the CDATA sections ?  I
can certainly do that.

Bye !
Fran=E7ois
Developer of Java Gui Builder
http://jgb.sourceforge.net/

RE: [Springframework-developer] Form View and Results View on same page issue.

[William L. <wi...@ly...>]

First, you described the problem correctly.  The link you sent is the exact scenario that I was describing.  When I first realized that SimpleFormController wasn't going to support this type of page out of the box, I looked at extended BaseCommandController as you have done.  I resisted this mainly for 2 reasons.
1. As you mentioned, it was yet another FormController and I didn't thing it was likely that it would be pulled back into Spring since there are already about 5 flavors of controllers.  Arguably, there may already be too many versions of controllers within the Framework. 
2. Personally, I believe that the controller shouldn't have to be altered just because it's returning to the same view.  I should be able to return a success view string and not have to alter my subclass just because I am reposting back to the same form. 

In either case, this is such a common scenario I would hope that the Spring Framework would support this out of the box by either another CommandController as you have suggested or enhancing SimpleFormController as I did in the first part of this thread.

Thanks,
Bill Lyvers

I would be very interested in seeing your SelfPostingFormController.  It is probably a much simpler workflow since you know you are only working with one view.


---------- Original Message ----------------------------------
From: "Trevor Cook" <tc...@in...>
Reply-To: spr...@li...
Date:  Mon, 16 Feb 2004 22:18:54 -0500

>It sounds like your problem is with the workflow of SimpleFormController.
>Before recommending an option, let me clarify what you are trying to do.  It
>sounds like it should be:
>
>- use posted bean to determine search params (if it exists - for "get" use
>default values of search-param bean)
>- return view with search results
>
>You don't need a "FormView"/"SuccessView", just a single view.  You also
>would need any "referenceData" like method to be called before returning the
>view, regardless of get/post.  Is this a correct understanding of your
>problem?  If so, take a quick look at something I've implemented at
>http://www.fotosource.com/my_local_store.html .  Basically, the filters
>above the search results are constantly redisplayed with changing results
>underneath.  The form also works for an initial get request (with no search
>filters) and then successive posts (through the filter button).
>
>I implemented this by extending BaseCommandController
>(SimpleFormController's "grandfather").  You can probably simply implement
>what you're looking for by extending this class (or if necessary, step back
>another level to AbstractController).  I never contributed this class (I
>called it "SelfPostingFormController") because it was fairly simple to
>implement, and considering most custom apps functionality is "exactly like
>class X except for Y" I didn't want to bloat Spring.  Would this type of
>class be generally useful (or has another developer already snuck this in)?
>If multiple users want this I'll add it, otherwise I'll just post the code
>seperately for you to use.
>
>Trevor
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of wi...@ly...
>Sent: February 16, 2004 7:18 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Form View and Results View on
>same page issue.
>
>
>I posted this late last week but didn't get any bites -- maybe I'll try
>a different angle :).
>In short, I believe that the SimpleFormController should be enhanced to
>support posting results back to the originating form page.  The current
>implementation requires implementing classes to know they are returning
>back to the originating form page.  This limits the generic ability of
>wiring up views via IOC and getSuccessView() on SimpleFormHandler.
>Since this is such a common scenario, I was hoping this could be
>addressed prior to the 1.0 release.  Thoughts?
>
>Bill Lyvers
>
>
>wi...@ly... wrote:
>
>> I recently started using the web framework portion of Spring.  One
>> concept in particular has bitten me a couple of times and I have been
>> unable to determine a best practice.  The concept is how
>> SimpleFormHandler has a different workflow based on whether it is a
>> get request versus a post request.  This concept seemed very intuitive
>> and works fine if the post goes off to a result page.  However, below
>> is a scenario that I believe is quite common and SimpleFormHandler
>> doesn't seem to deal with it very elegantly.  The problem arises when
>> a page displays both a form and the results of a form post on the same
>> page.
>>
>> Scenario:
>> There is item search page with a item search form on the top and a
>> tabular view of the item search results below the search page.
>>
>> Example Controller:
>> public class ItemSearchController extends SimpleFormController {
>>    private ItemManager manager;
>>    public void setSearchManager(ItemManager manager) {
>>        this.manager = manager;
>>    }
>>    protected Map referenceData(HttpServletRequest request) throws
>> Exception {
>>        Map map = new HashMap();
>>        map.put( "itemTypes", manager.getItemTypes() );
>>        return map;
>>    }
>>    protected ModelAndView onSubmit(Object object) throws Exception {
>>        Item command = (Item)object;
>>        return new ModelAndView( getSuccessView(), "items",
>> manager.findItemsByExample( command ));
>>    }
>> }
>>
>> So, I request the page via /searchItem.htm which maps
>> ItemSearchController.  The "get" workflow works as usual --
>> referenceData gets called and the page displays fine.  The user
>> submits a search criteria which then goes through "post" workflow and
>> onSubmit gets called which returns a list of items via ModelAndView.
>> The successView now needs to return to the same page and this time the
>> results will be displayed below the form. However,
>>    1. If I forward back to /searchItem.htm, then I end up in an
>> infinite loop because the controller keeps processing it as a post.
>>    2. If I forward on to the jsp that displayed the form originally, I
>> will not go through the same workflow as when the page was first
>> loaded and referenceData won't get called. Not too mention that I'll
>> get an binding errors missing exception -- I saw that RC1 tried to
>> address this, but only if you don't override onsubmit.
>>
>> So, I decided to solve the problem with option 1 and cause the form to
>> realize that the post had already been handled and it must be a "get"
>> request being caused by a forward.  The main reason for this is that
>> the get workflow gets used when entering the page each.  To fix it, I
>> overrode isFormSubmission and set an attribute when a formSubmission
>> was recognized.  If this attribute already exists, it assumes that it
>> is a get request instead. Example:
>> protected boolean isFormSubmission(HttpServletRequest
>> httpServletRequest) {
>>        Object alreadySubmitted = httpServletRequest.getAttribute(
>> "formSubmission");
>>        if (alreadySubmitted != null) {
>>            return false;
>>        }
>>        boolean formSubmission =
>> super.isFormSubmission(httpServletRequest);
>>        if( formSubmission ) {
>>            httpServletRequest.setAttribute( "formSubmission",
>> Boolean.TRUE );
>>        }
>>        return formSubmission;
>> }
>>
>>
>> I am a surprised that SimpleFormController doesn't deal with this
>> scenario since it is so common or maybe I am missing something and it
>> does.   With the above code you can switch out the success view to go
>> to a seperate result page later by just changing the IOC
>> configuration.   Basically, your controller doesn't really need to
>> know that the results page is the same view as the form view.
>>
>> I am very curious on how others are dealing with this scenario and if
>> Spring deals with it and I have just overlooked it.
>>
>> Keep up the good work,
>> Bill Lyvers
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> Build and deploy apps & Web services for Linux with
>> a free DVD software kit from IBM. Click Now!
>> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
 

 

Re: Re [Springframework-developer] DTD versioning

[Colin S. <col...@ex...>]

I am ok with either one. I picked the variant I did before because it is 
what Sun uses, but if somebody likes the Hibernate-style better I am ok 
with that.

jürgen höller [werk3AT] wrote:

>Any opinions on the exact naming of the DTD file? I'd like to commit the change promptly :-)
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>Gesendet: Mo 16.02.2004 08:40
>An: spr...@li...
>Betreff: Re: [Springframework-developer] DTD versioning
>
>
>
>Colin, Rod,
>
>I've just adapted BeansDtdResolver to fall back to the default DTD file "spring-beans_1_0.dtd" if  "spring-beans.dtd" was specified, issuing a corresponding message at INFO level (not committed yet). I guess INFO is appropriate, as "spring-beans" can simply be considered a shortcut for "spring-beans_1_0" for the time being.
>
>If we agree on the exact naming that Colin proposed, I'll commit this and adapt all our bean definition declarations in the samples etc. The only alternative that I see is "spring-beans-1.0.dtd" as used by Hibernate's DTDs, while "_1_0" is the style used by Sun's DTDs.
>
>IMO, "spring-beans.dtd" should also stay available from the website, simply adding the versioned DTD file there.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Rod Johnson
>Gesendet: So 15.02.2004 17:18
>An: spr...@li...
>Betreff: Re: [Springframework-developer] DTD versioning
>
>
>
>Colin
>
>I agree about versioning, so long as we can avoid breaking people's
>definitions. We could have only the new URL on the web site and modify the
>entity resolver so that it produces a log warning on finding the old one
>(but still resolved it). This should provide a deprecation-style upgrade
>path.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Sunday, February 15, 2004 3:26 PM
>Subject: [Springframework-developer] DTD versioning
>
>
>  
>
>>I updated the DTD on the website, and this reminds me that we should
>>version the document. I propose naming it something like
>>
>>spring-beans_1_0.dtd
>>
>>with the doctype definition being:
>>
>><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
>>        "http://www.springframework.org/dtd/spring-beans_1_0.dtd">
>>
>>If everyone is in agreement, the only question is if we should keep the
>>old one around (ie keep both versions) for the 1.0 release. I would
>>favour having only the new version, to avoid future confusion, although
>>this would force everybody to update their definition documents.
>>
>>Regards,
>>Colin
>>
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>Build and deploy apps & Web services for Linux with
>>a free DVD software kit from IBM. Click Now!
>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>

RE: [Springframework-developer] Spring sub-projects

[Kopylenko, D. <dko...@ac...>]

Well, spring-rcp is a bit cryptic. How about spring-rich-client?

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Tuesday, February 17, 2004 8:04 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Spring sub-projects


Any opinions regarding the new module names? Else, I'll create =
"spring-rcp"
and "spring-eclipse" in the course of this week.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Monday, February 16, 2004 9:59 AM
To: spr...@li...
Subject: [Springframework-developer] Spring sub-projects


Everybody,
=20
As recently discussed in private mails, I suggest to keep sub-projects =
that
are close to the Spring core as separate modules in Spring's main CVS. =
The
first two candidates are:
=20
- Keith Donald's Spring Rich Client Platform
- Torsten Juergeleit's Spring Eclipse Plugin
=20
Both Keith and Torsten are in favor of hosting them in our main CVS. So =
if
noone objects, I will create new CVS modules "spring-rcp" and
"spring-eclipse", and accordingly give Keith and Torsten commit rights =
for
the main CVS. As the module names cannot be changed easily, feel free =
to
suggest different names!
=20
The rationale is to keep all projects that use "org.springframework" as
package name in Spring's main CVS. Separate modules make sense to let =
the
sub-projects evolve independently; this way, they do not have to be =
released
in direct accordance with the Spring core. Of course, generic classes =
that
emerge can still go into the core.
=20
Consequently, both sub-projects should also get respective sections on =
our
main website. We should definitely clarify all this before 1.0 final =
(March
1st), as I expect quite a lot of media coverage at that time - we =
shouldn't
miss that chance!
=20
Juergen
=20


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Spring sub-projects

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

Any opinions regarding the new module names? Else, I'll create =
"spring-rcp" and "spring-eclipse" in the course of this week.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Monday, February 16, 2004 9:59 AM
To: spr...@li...
Subject: [Springframework-developer] Spring sub-projects


Everybody,
=20
As recently discussed in private mails, I suggest to keep sub-projects =
that are close to the Spring core as separate modules in Spring's main =
CVS. The first two candidates are:
=20
- Keith Donald's Spring Rich Client Platform
- Torsten Juergeleit's Spring Eclipse Plugin
=20
Both Keith and Torsten are in favor of hosting them in our main CVS. So =
if noone objects, I will create new CVS modules "spring-rcp" and =
"spring-eclipse", and accordingly give Keith and Torsten commit rights =
for the main CVS. As the module names cannot be changed easily, feel =
free to suggest different names!
=20
The rationale is to keep all projects that use "org.springframework" as =
package name in Spring's main CVS. Separate modules make sense to let =
the sub-projects evolve independently; this way, they do not have to be =
released in direct accordance with the Spring core. Of course, generic =
classes that emerge can still go into the core.
=20
Consequently, both sub-projects should also get respective sections on =
our main website. We should definitely clarify all this before 1.0 final =
(March 1st), as I expect quite a lot of media coverage at that time - we =
shouldn't miss that chance!
=20
Juergen
=20


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re [Springframework-developer] DTD versioning

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

Any opinions on the exact naming of the DTD file? I'd like to commit the =
change promptly :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 16.02.2004 08:40
An: spr...@li...
Betreff: Re: [Springframework-developer] DTD versioning



Colin, Rod,

I've just adapted BeansDtdResolver to fall back to the default DTD file =
"spring-beans_1_0.dtd" if  "spring-beans.dtd" was specified, issuing a =
corresponding message at INFO level (not committed yet). I guess INFO is =
appropriate, as "spring-beans" can simply be considered a shortcut for =
"spring-beans_1_0" for the time being.

If we agree on the exact naming that Colin proposed, I'll commit this =
and adapt all our bean definition declarations in the samples etc. The =
only alternative that I see is "spring-beans-1.0.dtd" as used by =
Hibernate's DTDs, while "_1_0" is the style used by Sun's DTDs.

IMO, "spring-beans.dtd" should also stay available from the website, =
simply adding the versioned DTD file there.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: So 15.02.2004 17:18
An: spr...@li...
Betreff: Re: [Springframework-developer] DTD versioning



Colin

I agree about versioning, so long as we can avoid breaking people's
definitions. We could have only the new URL on the web site and modify =
the
entity resolver so that it produces a log warning on finding the old one
(but still resolved it). This should provide a deprecation-style upgrade
path.

Regards,
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Sunday, February 15, 2004 3:26 PM
Subject: [Springframework-developer] DTD versioning


> I updated the DTD on the website, and this reminds me that we should
> version the document. I propose naming it something like
>
> spring-beans_1_0.dtd
>
> with the doctype definition being:
>
> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
>         "http://www.springframework.org/dtd/spring-beans_1_0.dtd">
>
> If everyone is in agreement, the only question is if we should keep =
the
> old one around (ie keep both versions) for the 1.0 release. I would
> favour having only the new version, to avoid future confusion, =
although
> this would force everybody to update their definition documents.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: [Springframework-user] Mapping Exceptions with sql-error-codes.xm l

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

Thomas,
=20
SQLErrorCodesFactoryTests fails because of an unexpected call to =
getDriverVersion now - could this be a side-effect or your changes?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag von =
Thomas Risberg
Gesendet: Sa 14.02.2004 20:39
An: spr...@li...
Betreff: Re: [Springframework-user] Mapping Exceptions with =
sql-error-codes.xm l



Martin,

I have added thre additional error categories:
DataRetrievalFailureException, OptimisticLockingFailureException and
DataAccessResourceFailureException.

You can add any of the following if you need this transalation:
    <property
name=3D"dataRetrievalFailureCodes"><value>12345</value></property>
    <property
name=3D"optimisticLockingFailureCodes"><value>56789</value></property>
    <property
name=3D"dataAccessResourceFailureCodes"><value>12341</value></property>

The code is in CVS now and will be part of 1.0 final.

Thomas


Meier Martin wrote:

> Hi,
>=20
> I tried to map a stale connection error code to a
> DataAccessResourceFailureException, but this did not work:
>=20
>   <bean id=3D"Oracle"
> class=3D"org.springframework.jdbc.support.SQLErrorCodes">
>     <property
> =
name=3D"badSqlGrammarCodes"><value>900,903,904,917,936,942,17006</value><=
/property>
>     <property
> =
name=3D"dataIntegrityViolationCodes"><value>1,1400,1722,2291</value></pro=
perty>
>     <property
> =
name=3D"dataIntegrityViolationCodes"><value>1,1400,1722,2291</value></pro=
perty>
>     <property
> =
name=3D"dataAccessResourceFailureCodes"><value>17002</value></property>
>   </bean>
>=20
> As I saw in the class SQLErrorCodes only the
> methods setBadSqlGrammerCodes(...) and
> setDataIntegrityViolationCodes(...) are supported. How is it possible
> to map an error code to a dataAccessResourceFailureException with the
> sql-error-codes.xml?
>=20
> Cheers
> -Martin




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user

Re: [Springframework-developer] AbstractXsltView

[Darren D. <da...@da...>]

> Darren,
>
> I guess there is a semantic difference here: AbstractUrlBasedView and
> UrlBasedViewResolver assume to deal with views that are more or less
> completely defined through a URL.

yeah, I'd guessed that might be the reason it hadn't been changed; I can
see it from either point of view actually so I have no strong preference
either way.

Cheers,

--=20
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] ICQ

[Darren D. <da...@da...>]

> Juergen, Thomas, Alef and I use Microsoft Messenger. It's good for audi=
o
> conversations, as well.

indeed - assuming you use a micro$oft OS ;-)


--=20
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] Spring sub-projects

[Jozsa K. <dy...@on...>]

Do we have any public details of this rich client platform? If it's targeted
to Swing only, and if there's any need for getting it support SWT, I'd
consider working on the SWT part..

dyn

On Mon, Feb 16, 2004 at 01:12:42PM +0100, j??rgen h??ller [werk3AT] wrote:
> It's about Keith's support classes for Spring-based Swing applications. T=
hey were initially targeted at inclusion in the Spring 1.1 core, but turned=
 out more extensive then expected. Thus, I consider it reasonable to host t=
hem as a Spring sub-project rather than as part of the Spring core.
>=20
> It is *not* an Eclipse plugin or the like, it's a support platform for bu=
ilding rich client applications on Spring, currently focussing on Swing. I =
guess Keith himself is in a better position to describe the mission here...=
 And I assume that he's more than happy to get other rich client developers=
 on board :-)
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Dmitriy Kopylenko
> Sent: Monday, February 16, 2004 12:48 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Spring sub-projects
>=20
>=20
> +1. Btw, what is "Spring Rich Client Platform"?
>=20
> Dmitriy.
>=20
> ----- Original Message -----
> From: j??rgen h??ller [werk3AT] <jue...@we...>
> Date: Monday, February 16, 2004 3:58 am
> Subject: [Springframework-developer] Spring sub-projects
>=20
> > Everybody,
> >=20
> > As recently discussed in private mails, I suggest to keep sub-
> > projects that are close to the Spring core as separate modules in=20
> > Spring's main CVS. The first two candidates are:
> >=20
> > - Keith Donald's Spring Rich Client Platform
> > - Torsten Juergeleit's Spring Eclipse Plugin
> >=20
> > Both Keith and Torsten are in favor of hosting them in our main=20
> > CVS. So if noone objects, I will create new CVS modules "spring-
> > rcp" and "spring-eclipse", and accordingly give Keith and Torsten=20
> > commit rights for the main CVS. As the module names cannot be=20
> > changed easily, feel free to suggest different names!
> >=20
> > The rationale is to keep all projects that use=20
> > "org.springframework" as package name in Spring's main CVS.=20
> > Separate modules make sense to let the sub-projects evolve=20
> > independently; this way, they do not have to be released in direct=20
> > accordance with the Spring core. Of course, generic classes that=20
> > emerge can still go into the core.
> >=20
> > Consequently, both sub-projects should also get respective=20
> > sections on our main website. We should definitely clarify all=20
> > this before 1.0 final (March 1st), as I expect quite a lot of=20
> > media coverage at that time - we shouldn't miss that chance!
> >=20
> > Juergen
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> HS^?+,??????o$?y?R???b??.)??
> i??0=06??u??u?e?&????n???'=1E??+.)??=08????y??=0E?=1F?=06?zH?~?& =13=02?'=
$6?!??=7F??l??gr??i???]???e????~7
--=20
=2EDigital.Yearning.for.Networked.Assassination.and.Xenocide

Re: [Springframework-developer] AbstractXsltView

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

Darren,
=20
I guess there is a semantic difference here: AbstractUrlBasedView and =
UrlBasedViewResolver assume to deal with views that are more or less =
completely defined through a URL. AbstractXsltView on the other hand =
needs a concrete subclass that provides the DOM document; the =
"stylesheetLocation" just specifies the stylesheet to render that =
subclass-provided document with. So I guess it's arguably OK to keep the =
"stylesheetLocation" property and not derive from AbstractUrlBasedView. =
What do others think?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Darren Davison
Gesendet: Di 17.02.2004 03:08
An: spr...@li...
Betreff: [Springframework-developer] AbstractXsltView



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

is there any reason this class can't extend AbstractUrlBasedView and =
replace
the stylesheetLocation with a url property for consistency?  Only really
struck me as I'm just documenting/using it..  should have noticed before
RC1 really.

Traffic to the lists would suggest not masses of people using it so
potentially it could be changed for 1.0 final but it would break =
existing
view definition files.  I can commit this if no objections since I'm
working with it just now.
- --

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAMXeIKLMLAN01aw0RAjssAJ9HMQw33Rv3+jTrHND4CeWY3lD7OgCglIDy
Hbx8lai0N6Hje13TMNaP0ak=3D
=3DPFF7
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Simpler Web MVC Configuration Proposal

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

James,

I'll read your post in detail when I have more time.

In the meantime, have a look at the
org.springframework.web.servlet.handler.metadata package, and let me know
your thoughts. This uses source-level attributes in controllers to reduce
config. I'm currently writing documentation for it in the reference manual.

Regards,
Rod


----- Original Message -----
From: "James Cook" <jim...@do...>
To: <spr...@li...>
Sent: Monday, February 16, 2004 10:26 PM
Subject: [Springframework-developer] Simpler Web MVC Configuration Proposal


> I have previously developed web applications using WebWork (1 & 2), and I
> have been drawn to the Spring Framework because of its complete IOC
support
> and more so, its excellent data abstraction layer. Particularly of
interest
> to me on my current project is its Hibernate support and Transaction
> capabilities.
>
> At the moment however, I am focused on some of the web tier architecture.
It
> may not be for everyone, but I find myself longing for WebWork's simple
> configuration of the web tier. I realize that I could integrate Spring and
> WebWork and be done with it, but I don't use WebWork's taglib, nor do I
want
> to introduce another dependency if I don't have to. Right now, I am trying
> to get Spring's web MVC framework sorted out. I apologize in advance if I
> misstate any facts or statements regarding the Spring Framework's
> capabilities or implementation. I am a Spring-chicken at the moment. :-)
>
> I think I understand the various mapping files that must be configured,
and
> the two, three, or twelve optional variants of each. As I was going
through
> each of the classes that provide a view resolver (InternalViewResolver,
> ResourceBundleViewResolver and XmlViewResolver), I began to wonder if I
was
> the only person who would like a simplified configuration. I think the
> primary differentiation when comparing Spring or WebWork on the Web-tier
> alone, is WebWork's simpler and more cohesive configuration file. I don't
> think either framework's WEB MVC configuration provides any more general
> functionality than the other, but I would like an optional resolver class
> that allows a single configuration file to specify the Controllers, URL
> Mapping, View Resolvers and the parameters that each may take. I don't
think
> this would be difficult either because of Spring's pluggability.
>
> In Spring, in order to use a single controller I have to configure the:
>
> viewResolver / instance of ResourceBundleViewResolver, XmlViewResolver,
>                or InternalViewResolver.
>
>     Used by the dispatcher servlet to resolve the ModelAndView's view
>     name (and locale) to a View class.
>
>     This object is retrieved "by name" by the dispatcher servlet, hence
>     there is only one per servlet context.
>
> handlerMapping / instance of BeanNameUrlHandlerMapping or
>                  SimpleUrlHandlerMapping.
>
>     Used by the dispatcher to
>
>     There can be many url handlers in a single servlet context since the
>     dispatcher servlet searches for bean's in its context that implement
>     the HandlerMapping interface. They can also be sorted in order to
>     give one handler priority over another when there is a URL that
>     matches multiple HandlerMappings.
>
> controller / instance of the Controller interface. There are a bunch of
>              these, and this probably represents one of the more
>              confusing aspects of Spring.
>
>     Each controller provides different functionality from the next, but
>     it seems like the design suffers a bit here. For example,
>     AbstractController is extended by MultiActionController,
>     BaseCommandController and ParameterizableViewController. Since a
>     controller must pick a single subclass to extend, a developer can
>     only take advantage of the benefits of one of these controllers. I
>     preferred WebWork's use of interfaces (and IOC) to drive the capabi-
>     lities of the Controller. This a moot point however, since I am only
>     focused on configuration at the moment.
>
> Each of these three configuration areas (four if you count
> ExceptionResolvers, five if you count HandlerAdapters, etc.) are powerful
in
> their flexibility, but somewhat cumbersome for someone coming from WebWork
> (or Maverick). For many of us a simpler configuration would be a welcome
> augmentation to Spring, and because of Spring's configuration flexibility,
I
> don't imagine it would take away from any features.
>
> As an example for configuration, consider the following sample from the
> petclinic example application that ships with Spring.
>
> -----------------------------------------------------------------------
>
> petclinic-servlet.xml
> =====================
> <bean id="viewResolver"
> class="org.springframework.web.servlet.view.ResourceBundleViewResolver">
> <property name="basename"><value>views</value></property>
> </bean>
>
> <bean id="urlMapping"
> class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
> <property name="mappings">
> <props>
> <prop key="/welcome.htm">clinicController</prop>
> </props>
> </property>
> </bean>
>
> <bean id="clinicController"
> class="org.springframework.samples.petclinic.web.ClinicController">
> <property name="methodNameResolver">
> <ref local="clinicControllerResolver"/>
> </property>
> <property name="clinic">
> <ref bean="clinic"/>
> </property>
> </bean>
>
> <bean id="clinicControllerResolver"
>
>
class="org.springframework.web.servlet.mvc.multiaction.PropertiesMethodNameR
> esolver">
> <property name="mappings">
> <props>
> <prop key="/welcome.htm">welcomeHandler</prop>
> </props>
> </property>
> </bean>
>
> views.properties
> ================
>
> welcomeView.class=org.springframework.web.servlet.view.JstlView
> welcomeView.url=/WEB-INF/jsp/welcome.jsp
>
> -----------------------------------------------------------------------
>
> This is a lot of configuration information when compared to a similar
> WebWork configuration. It also is spread across two files, although I
> suppose that there is a Spring technique to declare viewResolver data in
the
> petclinic-servlet.xml file, perhaps by using an XmlViewResolver and
> embedding the XML data as an IOC property? Another unclear step is the
> knowledge the developer must possess that his
> ClinicController.welcomeHandler() method returns the view mapping named
> 'welcomeView'. It is this name that is looked up in the views.properties
> file. This is somewhat unintuitive and other examples have tried to combat
> this ambiguity by including the view mappings directly (sort of) in the
> Controller configuration.
>
> <bean id="findOwnersForm"
> class="org.springframework.samples.petclinic.web.FindOwnersForm">
> <property name="formView"><value>findOwnersForm</value></property>
> <property
> name="selectView"><value>selectOwnerView</value></property>
> <property name="successView"><value>ownerRedirect</value></property>
> </bean>
>
> This example demonstrates something us WebWork developers have used very
> effectively for some time. The view is always returned as a simple string
in
> WebWork and this maps to the actual view via configuration information.
The
> same thing is occurring in the Spring example, but in a slightly
backhanded
> way. The SimpleFormController defines formView and successView as String
> properties. If the controller completes successfully, it returns
> getSuccessView() as its view and this in turn returns 'ownerRefirect' as
the
> mapped view. The developer also introduced a new view result called
> 'selectView'. In order to support this new result view, the developer has
to
> implement the selectView property in their subclass. Very cumbersome when
> compared to WebWork's "always map" approach to view results.
>
> Thanks for sticking with this unintentionally long post. I guess I set all
> of this up to suggest an alternative approach to configuring Spring's web
> MVC that is more compact and easier for new developers. It is based
heavily
> on WebWork's configuration, so it should prove even easier for WebWork
> developers to migrate. I do realize that this configuration will ruffle
the
> feathers of some architects that laud Spring's separation of components,
but
> I appreciate the fact that a configuration change does not necessarily
> negate an architecture. In fact it is a testament to Spring's solid
> architecture that such a configuration may be made possible without
changing
> any of Spring's infrastructure.
>
> proposed configuration - controller.xml
> ==============================================
>
> <controller alias="/welcome.htm"
> class="org.springframework.samples.petclinic.web.ClinicController"
> method="welcomeHandler">
> <property name="clinic"><ref bean="clinic"/></property>
> <results>
> <result name="selectView"
>
> class="org.springframework.web.servlet.view.JstlView"
> url="/WEB-INF/jsp/welcome.jsp" />
> <result name="successView"
>
> class="org.springframework.web.servlet.view.RedirectView"
> url="owner.htm" />
> </results>
> </controller>
>
> These seven lines in a single file represent all of the configuration
> information found in the prior 23 lines spread across a couple files.
There
> are probably other Spring capabilities that I am not representing here in
> this small example, but this is at least 95 percent of the types of web
> controllers that I use. I also am not showing the new configuration bean
> that would have to be configured in the xxx-servlet.xml file.
>
> I believe this configuration data should exist in the xxx-servlet.xml file
> or loadable from a separate file. No matter where it exists, it should be
> loadable as an applicationContext object with full Spring IOC capability,
> including parameter substitution.
>
> If I was going to approach writing this new configuration support bean I
> would create a configuration bean that can read in the controller.xml file
> in a Spring IOC manner. I guess I would base this work on XmlViewResolver,
> although I am unsure if this includes all of the IOC benefits
automatically?
>
> <bean id="viewResolver"
> class="org.springframework.web.servlet.mvc.ControllerConfig">
> <property name="location">
> <value>/WEB-INF/controller.xml</value>
> </property>
> </bean>
>
> I would have to give the bean an id of "viewResolver" because that is the
> only property that the dispatcher loads by name. The dispatcher discovers
> the other configuration parameters by searching for interface
> implementations amongst all the configured beans.
>
> So org.springframework.web.servlet.mvc.ControllerConfig would read the
> controller.xml file and implement the following interfaces:
> - org.springframework.web.servlet.ViewResolver
> - org.springframework.web.servlet.HandlerExceptionResolver
> - org.springframework.web.servlet.HandlerMapping
>
> I'm not sure what the best approach for loading the XML configuration file
> is to get Spring's IOC support, including external bean references from
the
> applicationContext and servletContexts. Also it should be reloadable
during
> development through the use of a flag. Any ideas on where to start with
> that?
>
> Once the configuration is loaded, it seems like the interface
> implementations would be straightforward.
>
> Thanks for reading this far. Hopefully it wasn't a waste of your time!
> - jim cook
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] ICQ

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

Juergen, Thomas, Alef and I use Microsoft Messenger. It's good for audio
conversations, as well.

----- Original Message -----
From: "Dmitriy Kopylenko" <dko...@ru...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 2:02 AM
Subject: Re: [Springframework-developer] ICQ


> How about yahoo messenger?
>
> ----- Original Message -----
> From: Darren Davison <da...@da...>
> Date: Monday, February 16, 2004 7:57 pm
> Subject: [Springframework-developer] ICQ
>
> > just wondering.. do any of you guys use ICQ?
> >
> > --
> >
> > Darren Davison
> > Public Key: http://www.davison.uk.net/key.jsp
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] [PATCH] doc/reference/src/aop.xml

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

I use XMLMind and it's great! I sure won't be editing raw XML again.

I will be editing the aop reference again later in the week, as I have ti=
me
for doco now.

----- Original Message -----
From: "Darren Davison" <da...@da...>
To: <spr...@li...>
Sent: Monday, February 16, 2004 11:14 PM
Subject: Re: [Springframework-developer] [PATCH] doc/reference/src/aop.xm=
l


On Thursday 05 February 2004 15:00, Francois Beausoleil wrote:

> Another patch, against CVS HEAD, as of 8:30 AM EST.
>
> [[[
> * doc/reference/src/aop.xml:
>   Multiple textual corrections-duplicated words, wrong
>   or dubious usage of words, spelling mistakes, etc.
>
>   Replaced decimal entity references 34 and 39 with
>   their corresponding character.  This makes it easier
>   to read and edit the text.
>
>   Created CDATA sections for all examples, as this eases
>   the editing process.
> ]]]

Fran=E7ois,

I haven't seen anyone else pick this up, but I took a look at it.  I thin=
k
the entity references in CVS are caused by the XXE DocBook editor that Ro=
d
used to write the aop.xml file (I tried it myself and it did the same on =
my
files).

Don't mind applying the patch, but it will get overridden the next time
anyone edits the file with XXE again and all the entity refs will re-appe=
ar
which looks confusing if ever we need to track the CVS versioning.

Regards
--

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Form View and Results View on same page issue.

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

It sounds like your problem is with the workflow of SimpleFormController.
Before recommending an option, let me clarify what you are trying to do.  It
sounds like it should be:

- use posted bean to determine search params (if it exists - for "get" use
default values of search-param bean)
- return view with search results

You don't need a "FormView"/"SuccessView", just a single view.  You also
would need any "referenceData" like method to be called before returning the
view, regardless of get/post.  Is this a correct understanding of your
problem?  If so, take a quick look at something I've implemented at
http://www.fotosource.com/my_local_store.html .  Basically, the filters
above the search results are constantly redisplayed with changing results
underneath.  The form also works for an initial get request (with no search
filters) and then successive posts (through the filter button).

I implemented this by extending BaseCommandController
(SimpleFormController's "grandfather").  You can probably simply implement
what you're looking for by extending this class (or if necessary, step back
another level to AbstractController).  I never contributed this class (I
called it "SelfPostingFormController") because it was fairly simple to
implement, and considering most custom apps functionality is "exactly like
class X except for Y" I didn't want to bloat Spring.  Would this type of
class be generally useful (or has another developer already snuck this in)?
If multiple users want this I'll add it, otherwise I'll just post the code
seperately for you to use.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of wi...@ly...
Sent: February 16, 2004 7:18 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Form View and Results View on
same page issue.


I posted this late last week but didn't get any bites -- maybe I'll try
a different angle :).
In short, I believe that the SimpleFormController should be enhanced to
support posting results back to the originating form page.  The current
implementation requires implementing classes to know they are returning
back to the originating form page.  This limits the generic ability of
wiring up views via IOC and getSuccessView() on SimpleFormHandler.
Since this is such a common scenario, I was hoping this could be
addressed prior to the 1.0 release.  Thoughts?

Bill Lyvers


wi...@ly... wrote:

> I recently started using the web framework portion of Spring.  One
> concept in particular has bitten me a couple of times and I have been
> unable to determine a best practice.  The concept is how
> SimpleFormHandler has a different workflow based on whether it is a
> get request versus a post request.  This concept seemed very intuitive
> and works fine if the post goes off to a result page.  However, below
> is a scenario that I believe is quite common and SimpleFormHandler
> doesn't seem to deal with it very elegantly.  The problem arises when
> a page displays both a form and the results of a form post on the same
> page.
>
> Scenario:
> There is item search page with a item search form on the top and a
> tabular view of the item search results below the search page.
>
> Example Controller:
> public class ItemSearchController extends SimpleFormController {
>    private ItemManager manager;
>    public void setSearchManager(ItemManager manager) {
>        this.manager = manager;
>    }
>    protected Map referenceData(HttpServletRequest request) throws
> Exception {
>        Map map = new HashMap();
>        map.put( "itemTypes", manager.getItemTypes() );
>        return map;
>    }
>    protected ModelAndView onSubmit(Object object) throws Exception {
>        Item command = (Item)object;
>        return new ModelAndView( getSuccessView(), "items",
> manager.findItemsByExample( command ));
>    }
> }
>
> So, I request the page via /searchItem.htm which maps
> ItemSearchController.  The "get" workflow works as usual --
> referenceData gets called and the page displays fine.  The user
> submits a search criteria which then goes through "post" workflow and
> onSubmit gets called which returns a list of items via ModelAndView.
> The successView now needs to return to the same page and this time the
> results will be displayed below the form. However,
>    1. If I forward back to /searchItem.htm, then I end up in an
> infinite loop because the controller keeps processing it as a post.
>    2. If I forward on to the jsp that displayed the form originally, I
> will not go through the same workflow as when the page was first
> loaded and referenceData won't get called. Not too mention that I'll
> get an binding errors missing exception -- I saw that RC1 tried to
> address this, but only if you don't override onsubmit.
>
> So, I decided to solve the problem with option 1 and cause the form to
> realize that the post had already been handled and it must be a "get"
> request being caused by a forward.  The main reason for this is that
> the get workflow gets used when entering the page each.  To fix it, I
> overrode isFormSubmission and set an attribute when a formSubmission
> was recognized.  If this attribute already exists, it assumes that it
> is a get request instead. Example:
> protected boolean isFormSubmission(HttpServletRequest
> httpServletRequest) {
>        Object alreadySubmitted = httpServletRequest.getAttribute(
> "formSubmission");
>        if (alreadySubmitted != null) {
>            return false;
>        }
>        boolean formSubmission =
> super.isFormSubmission(httpServletRequest);
>        if( formSubmission ) {
>            httpServletRequest.setAttribute( "formSubmission",
> Boolean.TRUE );
>        }
>        return formSubmission;
> }
>
>
> I am a surprised that SimpleFormController doesn't deal with this
> scenario since it is so common or maybe I am missing something and it
> does.   With the above code you can switch out the success view to go
> to a seperate result page later by just changing the IOC
> configuration.   Basically, your controller doesn't really need to
> know that the results page is the same view as the form view.
>
> I am very curious on how others are dealing with this scenario and if
> Spring deals with it and I have just overlooked it.
>
> Keep up the good work,
> Bill Lyvers
>
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others

[Colin S. <col...@ex...>]

Nobody forces resource-ref declarations on you, lots of people run 
without them. They are a way to ensure that a particular component can 
actually be found in a know location as far as another component is 
concerned, given that the default binding location may be container 
specific. But for a lot of people it's easier to just configure for the 
specific location in the app server, instead of setting up all these 
resource-ref declarations...

What I don't like about it is the idea that a default setting is playing 
around with the path you feed the function, and short of adding the 
extra property you can't even override it with another path format, 
wheras the reverse is not true; if the default was off, even without 
setting the property to on you could still just use the full path to get 
the local binding.

The JBoss JMS queue is also bound without any prefix. I just took a look 
at an old config of mine from when I was running WebLogic, and my 
datasources were bound in the global namespace, e.g.
  jdbc/Certification
with no java: prefix. Same deal for the JMS queue, and same for the mail.

Probably the thing to do is pose a question on the user list and see how 
many people are even relying on the inContainer=true auto-prefixing...

Regards,
Colin


jürgen höller [werk3AT] wrote:

>I agree that such a double check is not too desirable - a bit too much magic behind the scenes.
>
>On second thought, I'm not sure if "inContainer" defaulting to true is so inappropriate after all. Standard J2EE requires <resource-ref> declarations in web.xml, expecting "jdbc/myds"-style names relative to "java:comp/env"; the default AbstractJndiLocator accepts the same name syntax. I can imagine that quite a few users consider this intuitive - and I tend to agree...
>
>Remember that if you use "xxx:"-style JNDI prefixes, you won't get the "inContainer" behavior in any case. So I'm not sure how many scenarios actually require setting "inContainer" to false currently. Even JBoss JNDI locations for JDBC DataSources (in "-ds.xml" files) are automatically relative to the "java:" prefix. So is it just about default EJB locations in JBoss?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Monday, February 16, 2004 1:44 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] AbstractJndiLocator should not
>assume java:comp/env prefix while not allowing others
>
>
>What I don't like about checking both locations is that you then end up 
>doing two checks every single time really, for one of the most common 
>cases. I'm also not sure it's that correct to check in two places when 
>you tell it one... It would certainly work though.
>
>I'm curious just how much existing usage would break. I don't think it's 
>much of an issue for EJB access. Most people don't map their EJBs to the 
>local namespace. For datasource access, JBoss puts those into 
>'java:xxxxx', not just 'xxxxx', no choice in the matter, so JBoss users 
>would not be affected at all. It's been a while since I've used WebLogic 
>so I don't remember where WebLogic datasources end up.
>
>It's unfortunate that it's this late in the game, since it's pretty 
>clear to me that the best default state for this optimization (default 
>adding of java:comp/env) is best off, if we didn't have the 
>compatibility concern... We could perhaps try to get an idea of how many 
>users actually have configs where they are relying on this. The answer 
>we get back would probably be scalable towards the whole user base....
>
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Colin,
>>
>>While I generally agree that it's more appropriate to have "inContainer" default to false, I'm a bit worried that such a change would break all bean definition files that currently rely on accessing container DataSources with that implicit prefix.
>>
>>A further option would be to change "inContainer"'s semantics to: check for "java:comp/env/myJndiName" first, then try "myJndiName" directly if the former was not found. That would catch both cases, being fully backward-compatible, with just minimal overhead at startup. "inContainer"  turned off would solely try the latter case.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>Gesendet: So 15.02.2004 23:44
>>An: jürgen höller [werk3AT]
>>Cc: spr...@li...
>>Betreff: Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others
>>
>>
>>
>>I think we should revisit the decision to make inContainer=true the
>>default for the AbstractJndiLocator.
>>
>>While most people will of course be running in a container, having a
>>default value of inContainer=true will not help them, and will make
>>their config work harder. inContainer=true helps only if by default your
>>code is something like an EJB or WebApp, and you want to save typing
>>'java:comp/env/' at the beginning of your resource names, _and_ you have
>>gone to the pain of doing a resource mapping to bring resources into the
>>local java:comp/env/ namespace, something that most people don't bother
>>doing.
>>
>>If I deploy an EJB in JBoss for example, it gets deployed into the
>>global (not even 'java:') namspace. Unless I do the resource-ref mapping
>>for the client code that needs to access it, it needs to be accessed via
>>the global namespace. Since there is no prefix at all, that's completely
>>impossible to do unless inContainer=false, otherwise the code will add
>>the java:comp/env/. That means that for every EJB proxy I need to add
>>inContainer=false as a property.
>>
>>If false was the default, then people accessing resources for which
>>there was a local resource mapping (again, people don't usually do this)
>>would still have the choice of either using the full
>> java:/comp/env/
>>prefix, and leaving inContainer unset, or just setting
>> inContainer=true.
>>
>>I think this change makes sense because locally mapped resources (to
>>java:/comp/env) are less common than non-mapped resources. What do you
>>think?
>>
>>Regards,
>>Colin
>>
>>jürgen höller [werk3AT] wrote:
>>
>> 
>>
>>    
>>
>>>Just fixed: inContainer=true does not prepend the container prefix if a scheme is given (i.e. a ":" contained).
>>>
>>>
>>>-----Original Message-----
>>>From: Colin Sampaleanu [mailto:col...@ex...]
>>>Sent: Friday, August 22, 2003 1:33 PM
>>>To: jürgen höller [werk3AT]
>>>Cc: spr...@li...
>>>Subject: Re: [Springframework-developer] AbstractJndiLocator should not
>>>assume java:comp/env prefix while not allowing others
>>>
>>>
>>>I somehow missed the inContainer property, even though I looked at the
>>>source!   I think it does make sense though to add the check for the
>>>scheme as per your and mine suggestion; even in a container you still
>>>need to be able to override this...
>>>
>>>Regards,
>>>Colin
>>>
>>>jürgen höller [werk3AT] wrote:
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>Hi Colin,
>>>>
>>>>AbstractJndiLocator only does so when the "inContainer" property is set to true (the default). Setting this property to false should result in looking up the JNDI name as is. It could make sense to add a check for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is true *and* the JNDI name does not contain a ":". What do you think?
>>>>
>>>>Juergen
>>>>
>>>>
>>>>    -----Ursprüngliche Nachricht-----
>>>>    Von: Colin Sampaleanu [mailto:col...@ex...]
>>>>    Gesendet: Fr 22.08.2003 05:43
>>>>    An: spr...@li...
>>>>    Cc:
>>>>    Betreff: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others
>>>>   
>>>>   
>>>>
>>>>    AbstractJndiLocator right now looks at the jndi name it is given, and if
>>>>    it doesn't start with
>>>>       java:comp/env
>>>>    prepends this value automatically. This behaviour is not correct.
>>>>    Somebody using the bean should be able to look up resources anywhere,
>>>>    and currently you can't. For example, in jboss, the main datasource by
>>>>    default is bound to
>>>>      java:DefaultDS
>>>>   
>>>>    As well, you may want to look up something on JNDI using another scheme
>>>>    entirely...
>>>>   
>>>>    What the code should probably do is see if the is a scheme
>>>>       xxxxx:
>>>>    at the beginning of the jndi name. If there isn't, then it is probably
>>>>    reasonable to assume 'java:comp/env. or 'java:' If there is a scheme, it
>>>>    should leave the name alone.
>>>>   
>>>>    I would have supplied a patch, but the fix is trivial, and I don't know
>>>>    how exactly you want to handle this, but it's pretty critical to me.
>>>>   
>>>>    Right now with JBoss it's pretty nasty. I can not use JBoss's naming
>>>>    alias service to alias
>>>>      java:comp/env/DefaultDS
>>>>    to
>>>>      java:DefaultDS
>>>>    because it apparently doesn't let you alias stuff under comp/env.  I can
>>>>    probably modify my resource entries in the war file I use to do a
>>>>    resource ref to the right location, but I would really rather not do
>>>>    that, since the war is fine the way it is.
>>>>   
>>>>    Regards,
>>>>    Colin
>>>>   
>>>>
>>>>        
>>>>

[Springframework-developer] AbstractXsltView

[Darren D. <da...@da...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

is there any reason this class can't extend AbstractUrlBasedView and replac=
e=20
the stylesheetLocation with a url property for consistency?  Only really=20
struck me as I'm just documenting/using it..  should have noticed before=20
RC1 really.

Traffic to the lists would suggest not masses of people using it so=20
potentially it could be changed for 1.0 final but it would break existing=20
view definition files.  I can commit this if no objections since I'm=20
working with it just now.
=2D --=20

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAMXeIKLMLAN01aw0RAjssAJ9HMQw33Rv3+jTrHND4CeWY3lD7OgCglIDy
Hbx8lai0N6Hje13TMNaP0ak=3D
=3DPFF7
=2D----END PGP SIGNATURE-----

Re: [Springframework-developer] ICQ

[Dmitriy K. <dko...@ru...>]

How about yahoo messenger?

----- Original Message -----
From: Darren Davison <da...@da...>
Date: Monday, February 16, 2004 7:57 pm
Subject: [Springframework-developer] ICQ

> just wondering.. do any of you guys use ICQ?
> 
> -- 
> 
> Darren Davison
> Public Key: http://www.davison.uk.net/key.jsp
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] ICQ

[Darren D. <da...@da...>]

just wondering.. do any of you guys use ICQ?

-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] Form View and Results View on same page issue.

[<wi...@ly...>]

I posted this late last week but didn't get any bites -- maybe I'll try 
a different angle :).  
In short, I believe that the SimpleFormController should be enhanced to 
support posting results back to the originating form page.  The current 
implementation requires implementing classes to know they are returning 
back to the originating form page.  This limits the generic ability of 
wiring up views via IOC and getSuccessView() on SimpleFormHandler.  
Since this is such a common scenario, I was hoping this could be 
addressed prior to the 1.0 release.  Thoughts?

Bill Lyvers


wi...@ly... wrote:

> I recently started using the web framework portion of Spring.  One 
> concept in particular has bitten me a couple of times and I have been 
> unable to determine a best practice.  The concept is how 
> SimpleFormHandler has a different workflow based on whether it is a 
> get request versus a post request.  This concept seemed very intuitive 
> and works fine if the post goes off to a result page.  However, below 
> is a scenario that I believe is quite common and SimpleFormHandler 
> doesn't seem to deal with it very elegantly.  The problem arises when 
> a page displays both a form and the results of a form post on the same 
> page.
>
> Scenario:
> There is item search page with a item search form on the top and a 
> tabular view of the item search results below the search page.
>
> Example Controller:
> public class ItemSearchController extends SimpleFormController {
>    private ItemManager manager;
>    public void setSearchManager(ItemManager manager) {
>        this.manager = manager;
>    }
>    protected Map referenceData(HttpServletRequest request) throws 
> Exception {
>        Map map = new HashMap();
>        map.put( "itemTypes", manager.getItemTypes() );
>        return map;
>    }
>    protected ModelAndView onSubmit(Object object) throws Exception {
>        Item command = (Item)object;
>        return new ModelAndView( getSuccessView(), "items", 
> manager.findItemsByExample( command ));
>    }
> }
>
> So, I request the page via /searchItem.htm which maps 
> ItemSearchController.  The "get" workflow works as usual -- 
> referenceData gets called and the page displays fine.  The user 
> submits a search criteria which then goes through "post" workflow and 
> onSubmit gets called which returns a list of items via ModelAndView.  
> The successView now needs to return to the same page and this time the 
> results will be displayed below the form. However,
>    1. If I forward back to /searchItem.htm, then I end up in an 
> infinite loop because the controller keeps processing it as a post.
>    2. If I forward on to the jsp that displayed the form originally, I 
> will not go through the same workflow as when the page was first 
> loaded and referenceData won't get called. Not too mention that I'll 
> get an binding errors missing exception -- I saw that RC1 tried to 
> address this, but only if you don't override onsubmit.
>
> So, I decided to solve the problem with option 1 and cause the form to 
> realize that the post had already been handled and it must be a "get" 
> request being caused by a forward.  The main reason for this is that 
> the get workflow gets used when entering the page each.  To fix it, I 
> overrode isFormSubmission and set an attribute when a formSubmission 
> was recognized.  If this attribute already exists, it assumes that it 
> is a get request instead. Example:
> protected boolean isFormSubmission(HttpServletRequest 
> httpServletRequest) {
>        Object alreadySubmitted = httpServletRequest.getAttribute( 
> "formSubmission");
>        if (alreadySubmitted != null) {
>            return false;
>        }
>        boolean formSubmission = 
> super.isFormSubmission(httpServletRequest);
>        if( formSubmission ) {
>            httpServletRequest.setAttribute( "formSubmission", 
> Boolean.TRUE );
>        }
>        return formSubmission;
> }
>
>
> I am a surprised that SimpleFormController doesn't deal with this 
> scenario since it is so common or maybe I am missing something and it 
> does.   With the above code you can switch out the success view to go 
> to a seperate result page later by just changing the IOC 
> configuration.   Basically, your controller doesn't really need to 
> know that the results page is the same view as the form view.
>
> I am very curious on how others are dealing with this scenario and if 
> Spring deals with it and I have just overlooked it.
>
> Keep up the good work,
> Bill Lyvers
>
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>