Hi list, first of all I have to say that I totally agree with Mr. Mind Bridge ;-) on his thoughts on Tapestry. Pretty good read.
Because some future changes have been proposed on this list, I'd also like to give suggestions for a future release - however my points are a bit different to those mentioned before. I'd like to see a stronger decoupling between the markup generation aspects and the servlet context. In particular, in my opinion it'd be desirable if one could use a generic tapestry engine without need to have a servlet and a request/response. The engine should provide a method which can render a page into an output stream, i.e. renderPageNamed(String name, OutputStream output). The reason one might want to have this sort of engine is simply to reuse Tapestry's markup construction engine concepts i.e. in another framework or a tool (command line) project. I use it for creating LaTeX markup that's postprocessed via mikTeX to generate PDF reports. There's no relation to servlets, just reuse of the markup construction (because the templates are highly dynamic). I've written such an engine, but it took me some time, as I had to go through a lot more stuff than I had expected first. I had to subclass the RequestCycle class, simply because the original class needs the requestContext's response to encode URLs (I don't have a requestContext, so my URLs are generated differently). So, I just had to override encodeURL(). I also had to provide my own ResourceResolver (because that class is protected and I'm in my own package space and thus cannot use it). Is this a bug? Designwise it's understandable that one thinks this class is only useful within the Tapestry framework, but doesn't my case prove that this isn't always true? The last things I came across are in AbstractResponseWriter. Some instance variables are declared private, which makes it impossible for subclassers to clean the activeElementStack for example. In the LaTeX case I could reuse the AbstractResponseWriter (because the markup languages are not really that different), but I'd also need to keep track of the stack elements, in order to set closing curly braces for contexts correctly. If you're wondering why I did that - I could easily reuse the components for generating pagelinks without needing to duplicate them (I use the hyperref package with pdftex). Obviously not all HTML markup elements have a counterpart in LaTeX, though, hence reuse is somewhat limited. However it'd be preferrable if all instance variables that are declared private could be changed to protected in AbstractResponseWriter. That's my 0.02 EUR! ;-) Comments welcome, Marcus -- Marcus Mueller . . . crack-admin/coder ;-) Mulle kybernetiK . http://www.mulle-kybernetik.com Current projects: finger [EMAIL PROTECTED] _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
