|
From: <jue...@we...> - 2003-04-07 16:17:16
|
A naming issue: UrlHandlerMapping should probably be called =
DefaultUrlHanderMapping or some other more meaningful name. Especially =
with AbstractUrlHandlerMapping in addition to BeanNameUrlHandlerMapping, =
naming a concrete implementation UrlHandlerMapping seems inappropriate.
Of course, this would mean a name change that affects ControllerServlet =
context config files. But I think that we should prefer proper names and =
proper structure to backward compatibility, at least as long as there =
isn't an official release.
Juergen
-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Monday, April 07, 2003 5:09 PM
To: spr...@li...
Subject: [Springframework-developer] Ordering HandlerMappings and other
beans
Hi Rod, everyone,
I've just developed a custom HandlerMapping strategy for one of our =
applications and faced the issue that I wanted to retrieve beans of a =
certain class from the ApplicationContext in a specifyable order. =
Looking for a solution, I've recognized that exactly the same issue =
occurs with HandlerMappings themselves too. Currently, ControllerServlet =
solves this via sorting by bean name ("a.urlMap", "b.urlMap"), but =
frankly, I've never particularly liked that solution.
So I've applied a new approach to both HandlerMapping order and the =
problem in the custom application. Details of the HandlerMapping =
solution follow:
- I've introduced a Ordered interface to com.interface21.core, featuring =
one single method "int getOrder()", and an associated OrderComparator. =
The getOrder() method simply returns an int value, higher value meaning =
greater in terms of sorting resp. lower priority. This is somewhat =
analogous to Servlet load-on-startup values. OrderComparator sorts by =
order value, treating non-Ordered objects as greatest resp. lowest =
priority.
- ControllerServlet now sorts HandlerMappings (and HandlerAdapters, for =
consistency's sake) by sorting them with OrderComparator, rather than by =
bean name. Non-Ordered instances are thus applied in an arbitrary order, =
but instances can choose to implement Ordered to be able to specify a =
higher priority. Of course, the obvious way is adding an "order" bean =
property with getter and setter, to allow specifying the order value in =
the ApplicationContext configuration.
- There's AbstractUrlHandlerMapping now, an abstract base class for =
url-based HandlerMapping implementations. In addition to refactored =
things like unified handler initialization code (propagating =
ApplicationContext and LocaleResolver) for both =
BeanNameUrlHandlerMapping and UrlHandlerMapping, it offers a =
property-based Ordered implementation.
An example snippet from an applicationContext.xml file:
<bean name=3D"myUrlMap" =
class=3D"com.interface21.web.servlet.handler.UrlHandlerMapping">
<property name=3D"order">0</property>
<property name=3D"mappings">
/example.do=3DexampleController
</property>
</bean>
<bean name=3D"yourUrlMap" =
class=3D"com.interface21.web.servlet.handler.UrlHandlerMapping">
<property name=3D"order">1</property>
<property name=3D"mappings">
/example.do=3D/exampleFormController
/exampleForm.do=3DexampleFormController
</property>
</bean>
According to the order values, myUrlMap gets applied first, thus =
"/example.do" will lead to exampleController's execution. If one sets =
myUrlMap's order value to "2" or omits its order line, yourUrlMap will =
get applied first, thus "/example.do" will lead to =
exampleFormController's execution.
I consider this more elegant and more flexible than sorting by bean =
name. After all, servlets don't get started in the order of their name =
for a reason... ;-) Fortunately, an application developer doesn't have =
to care about the Ordered interface if he doesn't want to: A single =
HandlerMapping definition doesn't need to specify an order value, and a =
HandlerMapping implementation doesn't need to implement Ordered.
If noone objects, I will check in the changes promptly, as they go hand =
in hand with other things like the UrlHandlerMapping refactoring and =
some ControllerServlet polishing.
Juergen
DI J=FCrgen H=F6ller
Senior System Architect
__________________________________
werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg
europaplatz 4
A - 4020 linz
t. +43 (0) 732 71 65 29 502
f. +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|