On 10/12/01 6:20 PM, "Terry Steichen" <[EMAIL PROTECTED]> wrote:
> 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.) > Yep - that will work fine. Will this be a public system or product? We would be happy to mention it on our 'powered by' page. > 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 :-). Indeed. It's not 'if' but 'when'. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
