--- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > Right. One way to solve this (and I don't really want to do this but > here goes) is to add to our lovely eventCartrige system, and add a > handler for #parse() and #include(), so it would allow you to > preprocess > the arg. Something like : > > public String validatePath( String path ) > > that would be called with the resolved argument to #parse() or > #include() > > That way, you could simply tell your developers to not worry about > the > paths in their templates, and then prepend the appropriate /joe, > /john, > /sally, /whatever at run time... > > That way you as the programmer could enforce template access from > within > the tempalte based on application context, rather than trying to rig > some scheme up and trusting... > I think that even if this is not the way that things end up happening that something similar needs to be implemented. Those of us who are not using this for a web app really would like the ability to define "filters" that are not as much of a pain as the filter that web applications will run using. It feels like some of the restrictions on template loading should not be hardwired into the engine and should instead be based on "helper" classes that can be overwridden in a properties file to define a different scheme for template search paths among other things. just my 2c Brian ===== Brian S. Lloyd-Newberry Vertical Learning Curve Solutions [EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
