Menu
▾
▴
RE : [Springframework-developer] paged lists
|
From: JP P. <jp....@ti...> - 2003-06-03 03:00:47
|
Hi Juergen, everybody, I have tested and completed the pagedlist. - Some "oldies" were in the JSP. - The locale is now active (en, fr, de). - The detail page can be reached from the list. - The filter must redefine equals() and hashcode() as in the test. We = could provide an abstract class for filters using reflection for = redefining equals and hashcode? - The refreshableListHolder sets now the page to 0 if the refresh is due = to the filter to avoid being over the last page. The online demo and war download can be found at = http://tech.jppawlak.info/spring/samples.htm (the site is now reachable, I didn't add the CNAME entry to the DSN last = week).=20 I didn't change the CookieLocaleResolver, but it seems to me than adding = setPath and getPath methods will be useful as well as setting by default = the path to "/". Generally we want to change the locale for the whole = application and without this, it's only the part in the current url and = subs which is involved. Regards, Jean-Pierre > -----Message d'origine----- > De : spr...@li...=20 > [mailto:spr...@li...] > De la part de j=C3=BCrgen h=C3=B6ller [werk3AT] > Envoy=C3=A9 : lundi 2 juin 2003 11:49 > =C3=80 : spr...@li... > Objet : FW: [Springframework-developer] paged lists >=20 >=20 > Resending with an even smaller JAR file without class files -=20 > the former didn't get throught to the list because of the=20 > attachment size... >=20 >=20 > -----Original Message----- > From: j=C3=BCrgen h=C3=B6ller [werk3AT]=20 > Sent: Tuesday, May 27, 2003 8:05 PM > To: springframework-developer > Subject: RE: [Springframework-developer] paged lists >=20 >=20 > I've attached the reworked version of the paged list example.=20 > I've omitted all the JAR files to keep the JAR small. You'll=20 > still need a current spring-full, log4j, and jstl.jar +=20 > standard.jar for Apache's JSTL implementation. >=20 > Juergen >=20 >=20 > -----Original Message----- > From: j=C3=BCrgen h=C3=B6ller [werk3AT]=20 > Sent: Monday, May 26, 2003 10:07 PM > To: jp....@ti... > Cc: springframework-developer > Subject: Re: [Springframework-developer] paged lists >=20 >=20 > Jean-Pierre, > =20 > I've just committed my reworked version. > =20 > There's now a SortDefinition interface in=20 > com.interface21.beans, with a MutableSortDefinition=20 > implementation. The sort methods have moved from BeanUtils to=20 > PropertyComparator. > =20 > PagedListHolder is quite similar to before, targetted an=20 > immutable lists, but with binding-friendly sorting support=20 > via SortDefinition. I've turned PageListAutoHolder into=20 > RefreshablePagedListHolder, adding refreshing from a source=20 > provider on changed Locale or filter. Filter is a generic=20 > Object property now, allowing for any filter settings being=20 > passed through to the respective source provider. > =20 > I'll send the adapted version of your example app to the list=20 > tomorrow. There haven't been many changes to the controller=20 > and view, but why figure out yourself? :-) > =20 > Regards, > Juergen > =20 > =20 >=20 > -----Urspr=C3=BCngliche Nachricht-----=20 > Von: jp....@ti... [mailto:jp....@ti...]=20 > Gesendet: So 25.05.2003 15:08=20 > An: j=C3=BCrgen h=C3=B6ller [werk3AT]=20 > Cc: springframework-developer=20 > Betreff: Re: [Springframework-developer] paged lists > =09 > =09 >=20 > Hi J=C3=BCrgen, > =09 > Your suggests are very welcome. As you have a better=20 > knowledge ob the whole Spring framework, you seen quickly=20 > better interaction use. I am not at home, It seems you are=20 > already making the change. If you expext anything from me,=20 > talk me just about.=20 > =09 > Regards, > Jean-Pierre > =09 > ---------- Initial Header ----------- > =09 > From :=20 > spr...@li... > To : "JP Pawlak"=20 > <jp....@ti...>,"Spring Developers"=20 > <spr...@li...> > Cc : > Date : Sun, 25 May 2003 14:48:34 +0200 > Subject : Re: [Springframework-developer] paged lists > =09 > Hi Jean-Pierre, > =09 > BTW, the tests have all worked for me on Friday - I'll=20 > recheck tomorrow. > =09 > Regarding PagedListAutoHolder: I appreciate its added=20 > functionality. If I understand correctly, it's targetted at=20 > easy usage in a web controller. My initial PagedListHolder=20 > was just a first take, drawn from an application project. I'm=20 > very much for working all of this into a refined version,=20 > even before 0.8. I'll probably use it in our application project too. > =09 > --- > =09 > I've got some concrete issues: > =09 > - Generally, we should try to use data binding wherever=20 > possible, to keep the model and the actions as OO resp.=20 > bean-style as possible. I'm not a great fan of manual=20 > parameter parsing (have used it far too many times myself),=20 > be it from the ServletRequest or from a String-based=20 > parameter map. Spring's ServletRequestDataBinder allows for=20 > very powerful binding of request parameters to bean=20 > instances, even one to request to multiple beans. Manual=20 > String parameter evaluation doesn't belong in a proper model=20 > object, IMO. > =09 > - getMaxDisplayPages, getFirstDisplayPage,=20 > getLastDisplayPage should probably be called=20 > getMaxLinkedPages, getFirstLinkedPage, getLastLinkedPage - as=20 > they aren't really displayed themselves but rather just=20 > linked from the currently displayed page. > =09 > - I'd like to turn your "Sort" inner class into a=20 > generic com.interface21.beans.SortDefinition interface, and=20 > offer an accompanying=20 > BeanUtils.sortByProperty(List,SortDefinition) method. Your=20 > current Sort implementation could serve as=20 > DefaultSortDefinition implementation. > =09 > - As you've addressed with extendedInfo, reloading can=20 > depend on various specific parameters. But filtering could be=20 > based not only on per-field matching values but on regular=20 > expressions etc. A generic "filter" property of type Object=20 > will allow the controller to store a state object=20 > representing the current filter settings, combining your=20 > filterMap and extendedInfo in one generic Object. Note that=20 > PagedListHolder does not and should not need to know about=20 > the semantics of "filter". > =09 > - Some properties represent List meta data: "sort" of=20 > type SortDefinition, "filter" of type Object, "locale" of=20 > type Locale. These can easily be included in PagedListHolder,=20 > just like the linked pages support too (in the end, let's=20 > merge PagedListHolder and PagedListAutoHolder - we probably=20 > don't need both). PagedListSourceProvider would have a=20 > generic loadList(Object Filter, Locale locale) then. > =09 > - PagedListHolder properties like pageSize, pageNr,=20 > maxLinkedPages should be populated via binding (that's how my=20 > initial version was meant to be used). Let's treat=20 > PagedListHolder as a form bean, with request parameters=20 > getting bound to it on every submit - no String parameter=20 > parsing, no Integer.parseInt. The same applies to "sort" and=20 > "filter": A controller can set specific instances to the=20 > PagedListHolder instance on setup. These instances can be=20 > populated via the same binding step, using nested paths like=20 > "sort.ascending" etc. > =09 > - PagedListHolder's refresh method should do equals=20 > checks on "sort" and "filter" (using stored copies from the=20 > last refresh), and perform resorting resp. reloading if=20 > necessary (setting current versions as stored copies). Thus,=20 > a controller should invoke refresh after each bean=20 > population, i.e. on each request. A real refresh can be=20 > enforced by a respective request parameter, but this should=20 > be checked by the specific web controller, triggering a=20 > refresh(boolean enforce) call with true then. > =09 > - All things considered, the unified PagedListHolder=20 > will not need to know anything about request parameters.=20 > PagedListAutoHolder's xxxParam properties and its quite=20 > lengthy execute method aren't necessary then, most stuff can=20 > work via data binding and refresh. If one wants to use=20 > different request parameters, one can always perform manual=20 > post-binding, but the bean property names should be pretty=20 > straightforward as parameter names anyway. The binding paths=20 > match the JSTL EL expressions nicely, like "sort.ascending". > =09 > --- > =09 > A controller implementation is as simple as before. It=20 > just needs to trigger the binding and call the refresh method=20 > afterwards, instead of the current execute call. The=20 > respective code in your PagedListController example would=20 > look about as follows: > =09 > public ModelAndView showMain(HttpServletRequest=20 > request, HttpServletResponse response) { > PagedListAutoHolder listHolder =3D > =20 > (PagedListAutoHolder)request.getSession(true).getAttribute(COU > NTRIES_ATTR); > if (null =3D=3D listHolder) { > listHolder =3D=20 > (PagedListAutoHolder)this.getApplicationContext().getBean("aut oListHolder"); > listHolder.setSourceProvider(new CountriesProvider()); > listHolder.setFilter(new CountriesFilter()); > listHolder.setSort(new DefaultSortDefinition()); > =20 > request.getSession(true).setAttribute(COUNTRIES_ATTR, listHolder);=20 > } > BindException ex =3D BindUtils.bind(request,=20 > listHolder, "countries"); > boolean forceRefresh =3D=20 > request.getParameter("forceRefresh) !=3D null; > listHolder.refresh(forceRefresh); > return new ModelAndView("mainView", ex.getModel()); > } > =09 > public class CountriesFilter { > private String name; > private String code; > public String getName() { > return name; > } > public vois setName(String name) { > this.name =3D name; > } > public String getCode() { > return code; > } > public vois setCode(String code) { > this.code =3D code; > } > } > =09 > Filtering doesn't work via parameter names that serve=20 > as filter names anymore, but with a nested "filter" object of=20 > type CountriesFilter. So your main.jsp would need to use=20 > "countries.filter.code" EL for matching, sending=20 > "filter.code" as request parameter name for changing. The=20 > same applies to sorting, using the nested "sort" object: e.g.=20 > "countries.sort.ascending" EL for evaluation (just like in=20 > your current version), "sort.ascending" as request parameter name. > =09 > --- > =09 > What do you think? I'm keen on applying these changes=20 > promptly, if you don't mind, if possible already tomorrow.=20 > BTW, I'm writing this on a non-development PC at home, so I=20 > haven't actually prototyped the design, but I expect it to=20 > work nicely. We should end up with significantly less and=20 > more maintainable code, I hope. > =09 > Regards, > Juergen > =09 > =09 > =09 > -----Urspr=C3=BCngliche Nachricht----- > Von: JP Pawlak [mailto:jp....@ti...] > Gesendet: Fr 23.05.2003 22:20 > An: Spring Developers > Cc: > Betreff: [Springframework-developer] paged lists > =20 > =20 > =09 > =09 > Hi, > =20 > Excuse me from disturbing from fundamental=20 > issues like the KeyBinder > posted by Isabelle and the broken tests I've=20 > just posted. > =20 > As I talked about, I have added three files: > In src: > -=20 > com.interface21.util.PagedListAutoHolder.java (Class derived from > PagedListHolder) > -=20 > com.interface21.util.PagedListSourceProvider.java (Interface) > in test: > -=20 > com.interface21.util.PagedListAutoHolderTests.java (Class) > =20 > This all for easy use of a more powerfull paged List. > The javadoc and eventually test source will=20 > normally suffice to > understand the use. > Nevertheless, if I will not be impacted by the=20 > current test issues, I > will try to provide a tiny sample application=20 > for demonstrating. > =20 > After 0.8 will be released, I could have some=20 > help for rewieving the > javadoc comments as my English is very far from perfect. > =20 > Regards, > ______________________________ > Jean-Pierre Pawlak > jp....@ti... > =20 > =20 > =20 > =20 > =20 > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your=20 > application fit in a > relational database is painful, don't do it!=20 > Check out ObjectStore. > Now part of Progress Software.=20 > http://www.objectstore.net/sourceforge > =20 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > =20 > > = https://lists.sourceforge.net/lists/listinfo/springframework-developer > =20 > =09 > =09 > =09 > ********** SPECIAL ADSL ********** > L'ADSL =C3=A0 partir de 15,95 EUR/mois et le modem ADSL=20 > offert ? C'est en exclusivit=C3=A9 chez Tiscali ! > Pour profiter de cette offre, cliquez ici:=20 > http://register.tiscali.fr/adsl/ > Offre soumise =C3=A0 conditions. > =09 > =09 > =09 >=20 > N=18HY=DE=B5=E9=9A=8AX'un7+h=1F~V > ./Z(uh=1E=CA=8Bje=C6=AD=DF=8A=D8=A7jj=D8=A8]j=D6=9Bj=C7=A2vv > =179r=D4=AD > Z=1F> ,J=DE=86i0=E2=80=A0yl=DE=9D=7Fq =DA=99(G^hj)b b=D4=A9)~{ > +=D7=AFzZ)zb,y+=DE=B6=1Bm+-.=C7=9F=1E=7F+-b=D8=A7~=EC=A6=B8=DA=99(G^h >=20 |
