Menu
▾
▴
[Springframework-developer] =?iso-8859-1?Q?Re:_[Springframework-developer]_paged_lists?=
|
From: =?iso-8859-1?Q?<jp....@ti...> - 2003-05-25 13:12:44
|
Hi J=FCrgen,=0D=0A=0D=0AYour suggests are very welcome. As you have a be=
tter knowledge ob the whole Spring framework, you seen quickly better int=
eraction use. I am not at home, It seems you are already making the chang=
e. If you expext anything from me, talk me just about. =0D=0A=0D=0ARegar=
ds,=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial Header -----------=0D=0A=
=0D=0AFrom : spr...@li...=0D=
=0ATo : "JP Pawlak" <jp....@ti...>,"Spring Developers" <=
spr...@li...>=0D=0ACc : =0D=0A=
Date : Sun, 25 May 2003 14:48:34 +0200=0D=0ASubject : Re: [Springfra=
mework-developer] paged lists=0D=0A=0D=0AHi Jean-Pierre,=0D=0A =0D=0ABTW,=
the tests have all worked for me on Friday - I'll recheck tomorrow.=0D=0A=
=0D=0ARegarding PagedListAutoHolder: I appreciate its added functionalit=
y. If I understand correctly, it's targetted at easy usage in a web contr=
oller. My initial PagedListHolder was just a first take, drawn from an ap=
plication project. I'm very much for working all of this into a refined v=
ersion, even before 0.8. I'll probably use it in our application project =
too.=0D=0A =0D=0A---=0D=0A =0D=0AI've got some concrete issues:=0D=0A =0D=
=0A- Generally, we should try to use data binding wherever possible, to k=
eep the model and the actions as OO resp. bean-style as possible. I'm not=
a great fan of manual parameter parsing (have used it far too many times=
myself), be it from the ServletRequest or from a String-based parameter =
map. Spring's ServletRequestDataBinder allows for very powerful binding o=
f request parameters to bean instances, even one to request to multiple b=
eans. Manual String parameter evaluation doesn't belong in a proper model=
object, IMO.=0D=0A =0D=0A- getMaxDisplayPages, getFirstDisplayPage, getL=
astDisplayPage should probably be called getMaxLinkedPages, getFirstLinke=
dPage, getLastLinkedPage - as they aren't really displayed themselves but=
rather just linked from the currently displayed page.=0D=0A =0D=0A- I'd =
like to turn your "Sort" inner class into a generic com.interface21.beans=
.SortDefinition interface, and offer an accompanying BeanUtils.sortByProp=
erty(List,SortDefinition) method. Your current Sort implementation could =
serve as DefaultSortDefinition implementation.=0D=0A =0D=0A- As you've ad=
dressed with extendedInfo, reloading can depend on various specific param=
eters. But filtering could be based not only on per-field matching values=
but on regular expressions etc. A generic "filter" property of type Obje=
ct will allow the controller to store a state object representing the cur=
rent filter settings, combining your filterMap and extendedInfo in one ge=
neric Object. Note that PagedListHolder does not and should not need to k=
now about the semantics of "filter".=0D=0A =0D=0A- Some properties repres=
ent List meta data: "sort" of type SortDefinition, "filter" of type Objec=
t, "locale" of type Locale. These can easily be included in PagedListHold=
er, just like the linked pages support too (in the end, let's merge Paged=
ListHolder and PagedListAutoHolder - we probably don't need both). PagedL=
istSourceProvider would have a generic loadList(Object Filter, Locale loc=
ale) then.=0D=0A =0D=0A- PagedListHolder properties like pageSize, pageNr=
, maxLinkedPages should be populated via binding (that's how my initial v=
ersion was meant to be used). Let's treat PagedListHolder as a form bean,=
with request parameters getting bound to it on every submit - no String =
parameter parsing, no Integer.parseInt. The same applies to "sort" and "f=
ilter": A controller can set specific instances to the PagedListHolder in=
stance on setup. These instances can be populated via the same binding st=
ep, using nested paths like "sort.ascending" etc.=0D=0A =0D=0A- PagedList=
Holder's refresh method should do equals checks on "sort" and "filter" (u=
sing stored copies from the last refresh), and perform resorting resp. re=
loading if necessary (setting current versions as stored copies). Thus, a=
controller should invoke refresh after each bean population, i.e. on eac=
h request. A real refresh can be enforced by a respective request paramet=
er, but this should be checked by the specific web controller, triggering=
a refresh(boolean enforce) call with true then.=0D=0A =0D=0A- All things=
considered, the unified PagedListHolder will not need to know anything a=
bout request parameters. PagedListAutoHolder's xxxParam properties and it=
s quite lengthy execute method aren't necessary then, most stuff can work=
via data binding and refresh. If one wants to use different request para=
meters, one can always perform manual post-binding, but the bean property=
names should be pretty straightforward as parameter names anyway. The bi=
nding paths match the JSTL EL expressions nicely, like "sort.ascending".=0D=
=0A =0D=0A---=0D=0A =0D=0AA controller implementation is as simple as bef=
ore. It just needs to trigger the binding and call the refresh method aft=
erwards, instead of the current execute call. The respective code in your=
PagedListController example would look about as follows:=0D=0A =0D=0Apub=
lic ModelAndView showMain(HttpServletRequest request, HttpServletResponse=
response) {=0D=0A PagedListAutoHolder listHolder =3D=0D=0A (PagedLis=
tAutoHolder)request.getSession(true).getAttribute(COUNTRIES_ATTR);=0D=0A =
if (null =3D=3D listHolder) {=0D=0A listHolder =3D (PagedListAutoHold=
er)this.getApplicationContext().getBean("autoListHolder");=0D=0A listH=
older.setSourceProvider(new CountriesProvider());=0D=0A listHolder.set=
Filter(new CountriesFilter());=0D=0A listHolder.setSort(new DefaultSor=
tDefinition());=0D=0A request.getSession(true).setAttribute(COUNTRIES_=
ATTR, listHolder); =0D=0A }=0D=0A BindException ex =3D BindUtils.bind(=
request, listHolder, "countries");=0D=0A boolean forceRefresh =3D reques=
t.getParameter("forceRefresh) !=3D null;=0D=0A listHolder.refresh(forceR=
efresh);=0D=0A return new ModelAndView("mainView", ex.getModel());=0D=0A=
}=0D=0A =0D=0Apublic class CountriesFilter {=0D=0A private String name;=0D=
=0A private String code;=0D=0A public String getName() {=0D=0A retur=
n name;=0D=0A }=0D=0A public vois setName(String name) {=0D=0A this.=
name =3D name;=0D=0A }=0D=0A public String getCode() {=0D=0A return =
code;=0D=0A }=0D=0A public vois setCode(String code) {=0D=0A this.co=
de =3D code;=0D=0A }=0D=0A}=0D=0A =0D=0AFiltering doesn't work via param=
eter names that serve as filter names anymore, but with a nested "filter"=
object of type CountriesFilter. So your main.jsp would need to use "coun=
tries.filter.code" EL for matching, sending "filter.code" as request para=
meter name for changing. The same applies to sorting, using the nested "s=
ort" object: e.g. "countries.sort.ascending" EL for evaluation (just like=
in your current version), "sort.ascending" as request parameter name.=0D=
=0A =0D=0A---=0D=0A =0D=0AWhat do you think? I'm keen on applying these c=
hanges promptly, if you don't mind, if possible already tomorrow. BTW, I'=
m writing this on a non-development PC at home, so I haven't actually pro=
totyped the design, but I expect it to work nicely. We should end up with=
significantly less and more maintainable code, I hope.=0D=0A =0D=0ARegar=
ds,=0D=0AJuergen=0D=0A =0D=0A =0D=0A=0D=0A -----Urspr=FCngliche Nachricht=
----- =0D=0A Von: JP Pawlak [mailto:jp....@ti...] =0D=0A Gesendet=
: Fr 23.05.2003 22:20 =0D=0A An: Spring Developers =0D=0A Cc: =0D=0A Betr=
eff: [Springframework-developer] paged lists=0D=0A =0D=0A =0D=0A=0D=0A=0D=
=0A Hi,=0D=0A =0D=0A Excuse me from disturbing from fundamental issues li=
ke the KeyBinder=0D=0A posted by Isabelle and the broken tests I've just =
posted.=0D=0A =0D=0A As I talked about, I have added three files:=0D=0A I=
n src:=0D=0A - com.interface21.util.PagedListAutoHolder.java (Class de=
rived from=0D=0A PagedListHolder)=0D=0A - com.interface21.util.PagedLi=
stSourceProvider.java (Interface)=0D=0A in test:=0D=0A - com.interface=
21.util.PagedListAutoHolderTests.java (Class)=0D=0A =0D=0A This all for e=
asy use of a more powerfull paged List.=0D=0A The javadoc and eventually =
test source will normally suffice to=0D=0A understand the use.=0D=0A Neve=
rtheless, if I will not be impacted by the current test issues, I=0D=0A w=
ill try to provide a tiny sample application for demonstrating.=0D=0A =0D=
=0A After 0.8 will be released, I could have some help for rewieving the=0D=
=0A javadoc comments as my English is very far from perfect.=0D=0A =0D=0A=
Regards,=0D=0A ______________________________=0D=0A Jean-Pierre Pawlak=0D=
=0A jp....@ti...=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A ------=
-------------------------------------------------=0D=0A This SF.net email=
is sponsored by: ObjectStore.=0D=0A If flattening out C++ or Java code t=
o make your application fit in a=0D=0A relational database is painful, do=
n't do it! Check out ObjectStore.=0D=0A Now part of Progress Software. ht=
tp://www.objectstore.net/sourceforge=0D=0A ______________________________=
_________________=0D=0A Springframework-developer mailing list=0D=0A Spri=
ngf...@li...=0D=0A https://lists.sourcefor=
ge.net/lists/listinfo/springframework-developer=0D=0A =0D=0A=0D=0A=0A=0A*=
********* SPECIAL ADSL **********=0AL'ADSL =E0 partir de 15,95 EUR/mois e=
t le modem ADSL offert ? C'est en exclusivit=E9 chez Tiscali !=0APour pr=
ofiter de cette offre, cliquez ici: http://register.tiscali.fr/adsl/=0AOf=
fre soumise =E0 conditions.=0A
|
