On Sat, 2012-08-04 at 01:32 +0530, Nagarajan Chinnasamy wrote: > Dear Massimo, > > > 1. A solution that is specific to XML may not be a good idea. That is > not a generic solution.
My personal programming style with Rivet is to create a very generic template (generally a very simple index.rvt with a few basic tags) and then I embed in it the code for composing every page in the website. This approach implies I have just one <!DOCTYPE ...> declaration in that file. I never had to switch DOCTYPE within the same web application, but I understand this assumption isn't necessarily true every time. So if I had to put the <?xml ...?> header in my pages it would just occur once in index.rvt, it wouldn't be found anywhere else, and the clever trick Jeff proposed (neatly in the spirit of Tcl) would work very nicely. Even a web application which should switch back and forth from different HTML/XHTML doctypes could be handled using our current template mechanics scripting the header. > 2. Re-compiling code is not an out-of-the-box solution. Doing this > where run-time work-around doesn't exist is fine. > This, if we don't want to touch the documentation and test-suites, > leaves us with the only option of writing a proc that Jeff suggested. > > > If we are OK with touching the documentation and test suites, another > middle-ground solution, in the same lines of what Jeff suggested, is > to introduce a run-time switch that tells Rivet the tags to exclude: > > > RivetServerConf ExcludeStartTags "return [list <?xml <?tag2]" > I gave a look at the parser and I think it would require deep changes in the way the input buffer is processed. The current parser processes the buffer in a very straightforward way, having just one END_TAG and one START_TAG to check for. It's fast and simple. Changing it in the way you propose is possible, but it won't be so simple (and possibly so fast) anymore. > This solution may save writing new procs and will be open for future > contentions with other <? tags. > > All said, I understand that we have a work-around for now and this may > not be a high-priority change. > thanks for the understanding. Cheers -- Massimo --------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
