Quoting Mete Kural <[EMAIL PROTECTED]>: > Hi Craig, > > >A completely different way to consider using JSF would be to build a > RenderKit > >that took input like this and generated the corresponding HTML (or > whatever) > >markup, starting from the exact same components as the standard HTML > RenderKit. > > In the JSF release, there is the very beginnings of an example how this can > be > >done, which uses XUL as the input templating language. Fleshing something > like > >this out could leverage the fact that Mozilla has already popularized this > as a > >technology for defining page layout, as well as some amount of > interactivity. > > I have a question here. I've been thinking of ways of how JSF and XSLT could > be leveraged together, with or without leveraging JSP. Let's say we have an > application where the Action classes make lots of calls to SOAP services and > sometimes receive fairly large XML documents. In the case of large XML > responses, converting the XML to POJOs may turn out to be unnecessary > processing, where as you can simply do an XSLT transformation over the XML > response to generate the final markup output. So what would be an efficient > way to leverage both JSF and XSLT here? Could this be a good strategy: > > "Implement a RenderKit and JSF components that take XML documents as the > business object input (instead of JavaBeans, Maps, etc.) and uses XSLT to > generate the device-specific markup output. Then if you are using JSP as the > templating system, implement a JSP taglib to call these components. If you're > using another templating engine, write a tag library specific to that > templating system and call your components." >
One of the interesting things about JSF is that it's a two level API -- components and renderers have a JavaBeans-ish API to be used directly (or from the templating environment's renderers), and you can build a JSP custom tag around them to get access from the JSP layer. For example, doing something like JSTL's <x:transform> tag in JSF would be as simple as: * No new component needed ... leverage the "generic attributes" capability of the standard UIOutput component class. Or, if you really want, you can create a component class if you like exposing everything as JavaBeans properties. * Create a new XsltRenderer that uses the "value" property of the UIOutput component to point at the XML data to be transformed, and (perhaps) an "xslt" attribute to point at the stylesheet. (I'd suggest making the syntax and semantics as close as possible to <x:transform> for maximum familiarity), and used JAXP APIs to perform the transformation, followed by writing the output to the response. * Create a JSF component tag that marries the two together (about 30 lines of code) and utilizes the Java-level APIs underneath. Hmm, that's about 30 minutes of effort, and you get an XSLT transformation component that can be used in JSP or any other templating environment supported by your JSF RenderKit. I should have some time to play with stuff like this next week, when Sun shuts down for the Christmas break. > >Craig > > Mete > Craig PS: Of course, if you're using JSP as your rendering technology, nothing stops you from using tags like <x:transform> in the same page as your components, if you want. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
