tiles-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Le Bas <m...@nlebas.net>
Subject Re: Using Tiles 3 in Struts 2
Date Sat, 16 Jan 2016 19:16:22 GMT
On 01/14/2016 02:07 AM, Lukasz Lenart wrote:
 >> - #getResource(path) and #getResources(path) are used for non localized
 >> >resources. Tiles uses them to inventory the tiles.xml files at 
startup, like
 >> >here:
 >> 
 >https://github.com/apache/tiles/blob/TILES_3_0_X/tiles-core/src/main/java/org/apache/tiles/factory/BasicTilesContainerFactory.java#L220
 >> >or here:
 >> 
 >https://github.com/apache/tiles/blob/TILES_3_0_X/tiles-extras/src/main/java/org/apache/tiles/extras/complete/CompleteAutoloadTilesContainerFactory.java#L203
 > Those methods return ApplicationResource, how should I construct it?
 > Right now I'm doing it like this for all tiles*.xml definition files,
 > should I distinct them based on a suffix ("en", "pl")?
 >
 > 
https://github.com/apache/struts/pull/73/files#diff-a4ef02a35b4a5838b0cc73fa5e6236f9R113
 >

I think it will be OK. There is some logic in Tiles 
(BaseLocaleURLDefinitionDAO.setSources) that will strip the locale 
suffix and realize that tiles_en.xml and tiles.xml are related. You may 
run into trouble if you're using more underscores in your filename, 
though (like tiles_myapp_en.xml and tiles_myapp.xml).

On 01/14/2016 02:07 AM, Lukasz Lenart wrote:
> Because I want to have wildcard support without using Tiles wildcard
> servlet which is based on Spring
>
> https://github.com/apache/struts/pull/73/files#diff-a4ef02a35b4a5838b0cc73fa5e6236f9R45

OK. I don't know what's wrong with spring.

I can see a couple of things wrong with the implementation you're 
proposing, though:
- The existence of an ApplicationResource instance implies that the file 
exists. I think that your StrutsWildcardServletApplicationContext 
fullfills that requirement. Therefore you shouldn't have to test for the 
existence of the file in getInputStream(). Tiles certainly expects this 
method never to return null.

- Reliance on the existence of a physical File: many servlet containers 
have issues with that, depending their configuration. I can think of 
tomcat, jetty, jboss, weblogic, websphere (you can configure tomcat and 
jetty for not unpacking the wars, and I think the last 3 use a Virtual 
File Structure). That's what I like the most with the spring-based 
solution: those guys have ironed out this kind of problems :)

Overall I think URLApplicationResource is a better fit for you than your 
custom implementation, since the XWorks ResourceFinder returns URLs.


Hope this helps.

Nick.

Mime
View raw message