Re: Rendering raw data in pages
I agree with you on the fact that services are not and should not be pooled, it would not make any sense. On the other side, limiting pages to only render text is (in my humble opinion) arbitrary; services can render binary data, but they lack the features (property injection, ease of use, programmatic activation) that pages provide. In my case, i must render different images based on form submit data. This is not easy to do in a service, but would be in a page that could render binary data. By the way, the proposed change would not impact existing code at all. Regards Francesco Christian Haselbach wrote: On Sun, Mar 25, 2007 at 11:02:50AM +0200, fdegrassi wrote: I already did it using a service, what i do not like of it is that services are (obviously) stateless, not pooled, so i can't use them in While they are not pooled, they are not necessarily stateless. Services have access to the session and to ASOs just as everything else. It certainly makes sense for tapestry to pool pages, but it would not make sense to pool services in that sense, because there is nothing tapestry has to do, like parsing the template, wiring the components. Hence, I do not see the advantage of (ab)using a page to render a png. What should tapestry pool here, and how should it know how to do it? Other markups (like SVG) would be another case. There is a lot of reuse potential. Regards, Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rendering raw data in pages
On Sun, Mar 25, 2007 at 11:02:50AM +0200, fdegrassi wrote: > I already did it using a service, what i do not like of it is that > services are (obviously) stateless, not pooled, so i can't use them in While they are not pooled, they are not necessarily stateless. Services have access to the session and to ASOs just as everything else. It certainly makes sense for tapestry to pool pages, but it would not make sense to pool services in that sense, because there is nothing tapestry has to do, like parsing the template, wiring the components. Hence, I do not see the advantage of (ab)using a page to render a png. What should tapestry pool here, and how should it know how to do it? Other markups (like SVG) would be another case. There is a lot of reuse potential. Regards, Christian -- Christian Haselbach - [EMAIL PROTECTED] - +49 176 2082 5804 TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring Geschäftsführer: Henrik Klagges, Gerhard Müller, Eike Reinel Amtsgericht München, HRB 135082 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rendering raw data in pages
Hi all. The thing I'm trying to do is render an object of type image/png to the response without resorting to writing a custom service. I already did it using a service, what i do not like of it is that services are (obviously) stateless, not pooled, so i can't use them in the flexible way that Tapestry got me accustomed to when dealing with pages. What i would like would be, from my page listener, to get an injected "RawRenderingPage", set its "source" parameter to, e.g. an open inputstream, and activate it. It would then copy the source inputstream to the response outputstream. Problem is, the page service, when calling renderComponent on my page RawRenderingPage, passes a ResponseWriter already initialized with the Writer obtained calling getWriter from the HttpServletResponse; this prevents me from calling getOutputStream on the same (injected) HttpServletResponse. My idea would be to patch the ResponseWriter or the code creating it to lazily call HttpServletResponse.getWriter only when actually needed the first time, letting me get an handle on the response output stream in my page, if i want. Before trying, i thought maybe someone had already analyzed the problem and eventually studied a better approach. Regards Francesco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]