It's very interesting to see Tapestry used in such an extra-ordinary way. There has been talk in the past of doing many strange things with Tapestry that often separate it from its basic purpose: dynamic web applications.
In fact, had I been in your shoes, I might have investigated using Velocity or WebMacro before trying to fit Tapestry's square peg into this round hole. Still, I'm glad you got your hands dirty ... the community needs more people with an understanding of Tapestry's guts. My hands are a bit full right now just keeping up with the demands of folks using Tapestry for its core purpose. These changes you suggest are not substantial but are low on my list of priorities. In other words, if these are important to you, be prepared to roll up your sleeves! You may want to wait a bit until the repository stabilizies ... I'm in the middle of several things, including renaming everything from com.primix.tapestry.* to net.sf.tapestry.*. For a change of this size, I would ask that you prepare a patch file of your changes and get it to me. This is very easy to do if you are using Eclipse. -- [EMAIL PROTECTED] http://tapestry.sf.net > 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 _______________________________________________________________ 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
