> >> People who want spring resource loading in tiles might as well > >> just use spring-webmvc-3.2 instead. > >> > >> > >> Any objection Nicolas if i go ahead with these changes to > >> tiles-request-servlet-wildcard ? > >> - deprecate tiles-request-servlet-wildcard, > >> - deprecate WildcardServletApplicationContext > >> - make WildcardServletApplicationContext an empty subclass of > >> SpringWildcardServletTilesApplicationContext > > That looks very similar to my own plan. Actually I'm sure I've already > done something similar in my unmerged changes. > > For Tiles 3.1 I'd like to separate concerns inside the > ApplicationContext facade: storing attributes on one side and locating > resources on the other. See TREQ-17 and > https://github.com/nlebas/tiles-request/blob/master/tiles-request-api/src/main/java/org/apache/tiles/request/AbstractApplicationContext.java.
+1 very nice. > Concerning WildcardServletApplicationContext itself, this is my current > plan: > https://github.com/nlebas/tiles-request/blob/master/tiles-request-servlet-wildcard/src/main/java/org/apache/tiles/request/servlet/wildcard/WildcardServletApplicationContext.java Where is SpringResourceLocator? And why not use it to make 1) WildcardServletApplicationContext super short and simple and 2) the same code we're asking others to migrate to? eg https://github.com/michaelsembwever/tiles-request/blob/0403f48809d7b59e5829a03cecafa103298cbeae/tiles-request-servlet-wildcard/src/main/java/org/apache/tiles/request/servlet/wildcard/WildcardServletApplicationContext.java (same q applies on WildcardPortletApplicationContext). ~mck -- "The shortest and surest way to live with honour in the world is to be in reality what we appear to be." Socrates | http://github.com/finn-no | http://tech.finn.no |
signature.asc
Description: This is a digitally signed message part
