> The renderer receives a Request parameter and has to adapt it into > whatever API is required by the underlying technology. The difficult > part is passing the appropriate scopes from the request to the > underlying API. > [snip] > Which is it better?
My preference is to leave this decision up to each implementation. Accessing everything in all scopes for most implementations has no noticeable cost. For implementation that do, or for any other valid reason, they can/should go for the UnderlyingContext approach. > Two schools here: setting an attribute in the underlying API (like > most web-centric technologies: JSP, tomcat, struts, tiles, liferay, ...) > or using a ThreadLocal (like Spring MVC or Spring Security or JSF). I > don't think I've seen a third way, and I really don't know which one is > better. > [snip] > I'd like it if we could choose a single way of doing it here at apache > tiles. What do you think? My preference is for the first approach, and particularly standardising on using Request.class.getName() as the key in foreign contexts. But there often isn't a foreign context that is loose enough to put a request object into. I would rather have taken the first approach in tiles-request-mustache but it doesn't seem possible. Using a ThreadLocal should be a frowned upon last-available option to use. ( i didn't use try…finally as the threadLocal.remove() is but house-cleaning ) ~mck -- "All stable processes we shall predict. All unstable processes we shall control." John von Neumann | http://github.com/finn-no | http://tech.finn.no |
signature.asc
Description: This is a digitally signed message part
