Geir wrote : > Interesting approach. What worries me is how deeply it touches things, > from ICA to Template to nodes.
Hi Geir. Let's review the things the mechanism touches in velocity : - template : what I did here is just to add an *optional* parameter, contentType. To store type information (either in the template or directly in the resource) may be usefull for other tasks, as setting the proper content type in the servlet response. Anyway, no escaping at all can take place without knowing sthing about the content, and the template looked the right place to store this info. - ICA : this one may be avoided. I added an optional parameter, the CharEscaper. It could be stored anywhere the nodes have an access to, provided it is in the scope of the current merging process. It could even be stored as a simple context object under the apropriate key string, but when I saw this empty interface, and also your comment "If anything new comes along, add it here."...I could not resist... ;-) - nodes : here I guess it cannot be avoided, since the nodes are the only one to know that what they render should get a chance to be escaped or not. Note that only ASTText and ASTReference are concerned. > Why couldn't this be implemented as a filter on the writer? It would then be a FilterWriter that would wrap the outer writer, and would have two methods : a writer.write (no escaping) and a writer.filter (escaping). Then, only two classes would be touched : Template (for the content type and to build the FilterWriter) and ASTReference (to call writer.filter instead of writer.write). I can implement it this way if there is a better chance for the module to be commited (and I also guess it's a little better). CloD -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
