|
From: March, A. <am...@so...> - 2004-10-21 22:56:09
|
Sounds good to me but what deadline will you give me to provide the = oscache support I promised? > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of j=FCrgen h=F6ller [werk3AT] > Sent: Thursday, October 21, 2004 2:18 PM > To: spr...@li... > Subject: [Springframework-developer] Preparing for 1.1.2 >=20 > Everybody, >=20 > In contrast to the original plan of releasing 1.1.2 in mid November, = I'd > like to suggest to release it signficantly earlier - possibly on Oct = 31st. > We've already collected a quite large number of entries in the = changelog > (most of them minor issues), so I guess it's appropriate to do a = release > ASAP. >=20 > This would give us about 9 days for testing and polishing. Anything = that's > not manageable within that timeframe, no matter if bugfix or = enhancement, > should be deferred. Please test the current CVS contents as thorougly = as > possible, and if you have the chance, address some of the further = issues > currently marked for 1.1.2 in JIRA (in particular the doc ones). >=20 > It seems that there are already enough minor issues and enhancement > suggestions to warrant a 1.1.3 release, possibly at the end of = November. > Alternatively, we could go straight for 1.2 RC1, but I'm not too keen = on > combining the planned number of major new features with that minor = stuff > in one target milestone... I'd rather prefer 1.2 RC1 in early January. >=20 > Thoughts? Alternative suggestions? >=20 > Juergen >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on = ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give = us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-11-09 17:36:27
|
I've just added a further minor new feature, following a JIRA = suggestion: UrlBasedViewResolver supports a special "redirect:" prefix now, = generating RedirectViews for the given rest of the view name. All = regular view names will be resolved as usual, i.e. as = InternalResourceViews or VelocityViews (typically prepending the = specified prefix and appending the specified suffix). The benefit is that redirects can be specified through a special view = name now, rather than through programmatically creating a ModelAndView = with a RedirectView instance. In particular, this means that you can = specify "redirect:myList.do" as "successView" for a = SimpleFormController, just overriding "doSubmitAction" and not worrying = about the success ModelAndView. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Tuesday, November 09, 2004 8:52 AM To: spr...@li... Subject: [Springframework-developer] Preparing for 1.1.2 Hi everybody, =20 Once again, I'm about to prepare for release 1.1.2 :-) I've added two minor new features yesterday, following suggestions in = JIRA: =20 * added support for multi-dimensional collections to BeanWrapperImpl = (e.g. "map[myKey][0]" or "map[myKey][0].name") * added "setText(plainText, htmlText)" method to MimeMessageHelper, for = alternative texts in the same mail =20 If anyone has the chance, please give those a try, in particular the = BeanWrapperImpl change. I plan to do the actual release tomorrow now, if we don't encounter any = remaining issues. =20 Juergen ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-11-09 18:36:01
|
Great! I think this is the entry I put in there a while ago and never got around to implementing. Anybody using this should really treat all view names opaquely in the controller, if possible, so the controller has no idea that there's a redirect even happening.. So the controller should define properties (similar to successView) for all view names... jürgen höller [werk3AT] wrote: >I've just added a further minor new feature, following a JIRA suggestion: > >UrlBasedViewResolver supports a special "redirect:" prefix now, generating RedirectViews for the given rest of the view name. All regular view names will be resolved as usual, i.e. as InternalResourceViews or VelocityViews (typically prepending the specified prefix and appending the specified suffix). > >The benefit is that redirects can be specified through a special view name now, rather than through programmatically creating a ModelAndView with a RedirectView instance. In particular, this means that you can specify "redirect:myList.do" as "successView" for a SimpleFormController, just overriding "doSubmitAction" and not worrying about the success ModelAndView. > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of jürgen höller [werk3AT] >Sent: Tuesday, November 09, 2004 8:52 AM >To: spr...@li... >Subject: [Springframework-developer] Preparing for 1.1.2 > > >Hi everybody, > >Once again, I'm about to prepare for release 1.1.2 :-) >I've added two minor new features yesterday, following suggestions in JIRA: > >* added support for multi-dimensional collections to BeanWrapperImpl (e.g. "map[myKey][0]" or "map[myKey][0].name") >* added "setText(plainText, htmlText)" method to MimeMessageHelper, for alternative texts in the same mail > >If anyone has the chance, please give those a try, in particular the BeanWrapperImpl change. >I plan to do the actual release tomorrow now, if we don't encounter any remaining issues. > >Juergen > > |
|
From: Colin S. <col...@ex...> - 2004-11-09 23:44:40
|
Juergen, I think the defualt state in the class for the redirectContextView should be true. While the default State in RedirectView for the similar flag is false, even the JavaDoc for RedirectView says you will almost always want to set it true, since nobody wants to have to know the app context name just to do a redirect. I presume the reason it's false by default there is for historical reasons. So I think it makes sense to set it true by default in the view resolver, so people don't have to remember to set it true as a property when they define their view resolver. Colin Sampaleanu wrote: > Great! I think this is the entry I put in there a while ago and never > got around to implementing. Anybody using this should really treat all > view names opaquely in the controller, if possible, so the controller > has no idea that there's a redirect even happening.. So the controller > should define properties (similar to successView) for all view names... > > > jürgen höller [werk3AT] wrote: > >> I've just added a further minor new feature, following a JIRA >> suggestion: >> >> UrlBasedViewResolver supports a special "redirect:" prefix now, >> generating RedirectViews for the given rest of the view name. All >> regular view names will be resolved as usual, i.e. as >> InternalResourceViews or VelocityViews (typically prepending the >> specified prefix and appending the specified suffix). >> >> The benefit is that redirects can be specified through a special view >> name now, rather than through programmatically creating a >> ModelAndView with a RedirectView instance. In particular, this means >> that you can specify "redirect:myList.do" as "successView" for a >> SimpleFormController, just overriding "doSubmitAction" and not >> worrying about the success ModelAndView. >> >> Juergen >> >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...]On Behalf >> Of jürgen höller [werk3AT] >> Sent: Tuesday, November 09, 2004 8:52 AM >> To: spr...@li... >> Subject: [Springframework-developer] Preparing for 1.1.2 >> >> >> Hi everybody, >> >> Once again, I'm about to prepare for release 1.1.2 :-) >> I've added two minor new features yesterday, following suggestions in >> JIRA: >> >> * added support for multi-dimensional collections to BeanWrapperImpl >> (e.g. "map[myKey][0]" or "map[myKey][0].name") >> * added "setText(plainText, htmlText)" method to MimeMessageHelper, >> for alternative texts in the same mail >> >> If anyone has the chance, please give those a try, in particular the >> BeanWrapperImpl change. >> I plan to do the actual release tomorrow now, if we don't encounter >> any remaining issues. >> >> Juergen >> > |
|
From: Seth L. <set...@gm...> - 2004-11-09 23:53:54
|
> I think the defualt state in the class for the redirectContextView > should be true. While the default State in RedirectView for the similar > flag is false, even the JavaDoc for RedirectView says you will almost > always want to set it true, since nobody wants to have to know the app > context name just to do a redirect. I presume the reason it's false by > default there is for historical reasons. So I think it makes sense to > set it true by default in the view resolver, so people don't have to > remember to set it true as a property when they define their view resolver. +1 ! Every time we use it, we use 'true'. I think that's the more sensible default. Thanks, Seth |
|
From: <jue...@we...> - 2004-11-10 00:21:12
|
Makes sense - just changed it to "true". However, note that this just = applies to redirect URLs that start with a slash anyway: URLs that are = relative in the first place will always be considered as relative to the = current URL path (which is often appropriate). For an example, have a = look at imagedb's ImageController. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Seth Ladd Gesendet: Mi 10.11.2004 00:53 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.1.2 > I think the defualt state in the class for the redirectContextView > should be true. While the default State in RedirectView for the = similar > flag is false, even the JavaDoc for RedirectView says you will almost > always want to set it true, since nobody wants to have to know the app > context name just to do a redirect. I presume the reason it's false by > default there is for historical reasons. So I think it makes sense to > set it true by default in the view resolver, so people don't have to > remember to set it true as a property when they define their view = resolver. +1 ! Every time we use it, we use 'true'. I think that's the more sensible = default. Thanks, Seth ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-11-13 17:17:57
|
I've just finished preparations (including javadoc cleanup) and tests = for 1.1.2. From my point of view, everything is ready for the release. I = could upload it to SourceForge any time now; I plan to do so tomorrow. = If anybody spots last minute issues, please raise them ASAP :-) =20 If there's an easy way to resolve the HSQLDB 1.7.1/1.7.2 compatibility = issue, I'd like to include it in the release. Thomas, please keep me up = to date on the status there! Of course, I'd need to re-test Petclinic = and JPetStore then, but that's acceptable. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Mi 10.11.2004 01:20 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.1.2 Makes sense - just changed it to "true". However, note that this just = applies to redirect URLs that start with a slash anyway: URLs that are = relative in the first place will always be considered as relative to the = current URL path (which is often appropriate). For an example, have a = look at imagedb's ImageController. Juergen ________________________________ Von: spr...@li... im Auftrag = von Seth Ladd Gesendet: Mi 10.11.2004 00:53 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.1.2 > I think the defualt state in the class for the redirectContextView > should be true. While the default State in RedirectView for the = similar > flag is false, even the JavaDoc for RedirectView says you will almost > always want to set it true, since nobody wants to have to know the app > context name just to do a redirect. I presume the reason it's false by > default there is for historical reasons. So I think it makes sense to > set it true by default in the view resolver, so people don't have to > remember to set it true as a property when they define their view = resolver. +1 ! Every time we use it, we use 'true'. I think that's the more sensible = default. Thanks, Seth ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |