That "security" concern is the thing that bugs me the most about this idea. The templates are not, by definition, raw web resources, and they should never be vended directly to the client. I realise that's a rather categorical and final statement, but I am utterly convinced it is true, and would be very interested in any counter-example. Putting the templates in the context root then simply invites inappropriate access to those templates.
Putting them in a directory in WEB-INF however, seems like a nice idea to me. It's out of the way as far as web-content goes, while being convenient enough for Tapestry to find them all in one easy step. The only contra-argument I can come up with for now, however, is that this would mean the .java/.class lives in a different directory from the .page. It would seem to me that the current situation is advantageous in that if you've found the .page, you know exactly where the .java is (right where you are now). If you move one, it's much easier to see that you have to move the other (and modify references, granted). It's a small benefit, and one that may be strongly outweighed by the convenience of not having to declare pages in the .application. Craig On Sat, 2002-11-16 at 05:39, Eric Everman wrote: > Actually, I have some misgivings about placing templates in the context > root. The key one is that it would mean that contexts using Tapestry would > need to be Tapestry *only*. Currently it is possible to use Tapestry, JSP, > and other frameworks within the same context if they are mapped > appropriately. This could be important for integration with existing web > apps and in places where Tapestry is only part of a larger site that needs > to share session information. > > My second concern is that if Tapestry is designed to control the entire > context, people may ignore that fact and try to map files to the context > root anyway. In doing this, they could easily open up a (very minor) > security hole where people might be able to access raw files from the > context root that are intended to be templates or page files. > > Thoughts? > > Eric Everman > > > > At 11/15/2002, [EMAIL PROTECTED] wrote: > >Nope, these ideas are where we are headed. > > > >My thinking is that the templates belong in the context root, so that > >relative > >URLs to static assets work. > > > >I had been thinking that any page that required a page specification would > >require an entry into the application specification. > > > >This idea, that there could be a specific directory where page specifications > >are stored, is very worthwhile. > > > >Where we could end up is that the application specification exists to > >identify > >libraries and components. > > > > > >-- > >[EMAIL PROTECTED] > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Tapestry-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/tapestry-developer ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
