Joshua, > Pithy answer: any customization feature powerful enough to be > useful, will be powerful enough to create the problem you see. > > Therefore, if you want customization features that powerful, > you need to build in debugging and error catching features > to minimize the problems. That is true with Velocity or > with anything else. The important thing is to understand the > problem from the beginning, and design in those support features > from the beginning. > > BTW: I'm assuing that you want people to customize their templates, > so the 'templates in Jar' stuff will not help you. You are afraid > that they will make a mistake while customizing, and that your system > will pay the price for that mistake. > > Joshua Levy
>From the other responses I received, and after re-reading the docs on resource loaders, it seems that I can put the core templates (the ones for administering the system, ones that I do *not* want users to modify) into their own jar, which still allows users to freely create their own additional templates and put them somewhere else. (I should explain that my software provides a publishing framework, so it is expected that users will create scads of content-related pages, which are quite separate in function from the pages I provide to administer and otherwise run the system.) And, BTW, I am not afraid that users *might* screw up my system if they have the option - my long experience (and Murphy's well known Law) says that they certainly *will*, regardless of debugging and error handling :-).
