Everything you are saying is possible. The only part I don't know off the
top of my head is whether putting XML into the templates and resetting the
content type will do it. You can dig through BaseComponent's render method
to see how it's writing to the IResponseWriter. I would think everything
will fly, though there is a very slim chance it's an HTMLResponseWriter
down there somewhere.
You should be concerned about the performance of this architecture since
XSLT is slow. Maybe not the best plan, though I don't have direct
experience or empirical data.
-C
|--------+---------------------------------------------->
| | "Craig Gregory" |
| | <[EMAIL PROTECTED]> |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | eforge.net |
| | |
| | |
| | 06/13/2002 07:25 PM |
| | |
|--------+---------------------------------------------->
>--------------------------------------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: [Tapestry-developer] XML Processing & Other Stuff
|
|
|
>--------------------------------------------------------------------------------------------------|
I posted the following a couple of days ago, is it not getting through or
does no one have any thoughts ?
I am trying to add another layer of abstraction to Tapestry when rendering
the final HTML output. Using Tapestry to pull data from the application and
notify the application when HTML gestures occur is the way to go, but I am
looking to add enterprise and/or user look-and-feel to the application. I
am thinking XML/XSLT processing of the native Tapestry output. I would
place XML makers in the Tapestry template files of Tapestry components, and
then have the container (Orion in my case) post-process the output from
Tapestry.
Some of what I want to do would be to reorder the output stream base on
look-and-feel parameters. Is this a sound strategy or am I missing
something that Tapestry already can do ?
To implement the strategy, would the following work ? I would sub-class
ApplicationServlet and overload the doService() method to set the Context
Type of the response.
abstract public class MyApplicationServlet extends
net.sf.tapestry.ApplicationServlet {
protected void doService(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
response .setContectType ("text/xsl") ;
super .doService (request, response) ;
}
}
The container would then process the response after Tapestry is done. The
XML makers I would place in the corresponding template files would pass
information onto the XSLT process. Assuming that Tapestry will pass any
embedded information in component template file as is. Actually I plan to
make the Context Type dependent on a properties file associated with each
Tapestry page. What are your suggestions or where to place the processing
of this information ?
I also see where it might be prudent to generate Tapestry output from
inside a component (not from the template file). I would implement this
kind of processing by sub-classing BaseComponent and overwriting the render
() method. Are there any simple examples of this ?
Craig J. Gregory
Dir. of Information Srevices
Blue Mountain Community College
PO Box 100
2411 NW Carden Av.
Pendleton, OR 97801
(541) 278-5825
Craig J. Gregory
Dir. of Information Srevices
Blue Mountain Community College
PO Box 100
2411 NW Carden Av.
Pendleton, OR 97801
(541) 278-5825
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
