On 1/20/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > I'll looking for feedback and would like to start some discussion on an > idea that might be a nice Shale add-on. What do you think about the second > approach in this ticket? > > http://issues.apache.org/bugzilla/show_bug.cgi?id=37932 > > What do think about making this more of a generic feature so that any > render could be decorated by family or component type. Make this > configurable through a XML config file. > > > Besides being able to fix the immediate validation bug, we could use the > generic capabilities to add Ajax enabled features without having to lock > into a specific implementation or get into the business of component > building. > > > General ajax enabled field level validation might be a interesting feature > that could be added. The decorator renderer could add the view id and the > client id of a component in a remote javascript validation request that > could fire a method on a managed bean (new remoting). The view could be > restored using the view id with the state manager and the component found in > the tree using the client id both passed in the ajax call. Invoke the > validation and intercept the messages into a response. Seems like it might > work? > > > It might be an easy way to convert a component rendering to XHTML by using > the Clay parser to tokenize and re rendered in XML without having to > understand the specifics of the component and renderer. > > > You might want to wrapper panels in an html div to inject some slick CSS > sex without having to know anything about the component. > Any thoughts? > Gary >
This is certainly an interesting idea. For those who don't want to dig in to the code, basically the decoraing renderer hijacks the response writer that the "real" renderer uses to emt its output, then post processes the results. For a general purpose solution, one suggested improvement would be to have the imposter ResponseWriter give you back a DOM of the emitted output, rather than a String. It would be much easier to perform surgery on such a DOM, then pretty print it to the real output stream, than to do all the concatenation it takes to deal with the string representation. Interestingly, this is exactly what tools like Creator do at design time ... the page designer provides a ResponseWriter implementation that creates a DOM just like a browser would, and then interprets the HTML to render what a browser would render. In our case, we wouldn't have to worry about the visual rendering part (phew :-). We'd just want to provide a way to hook in transformations on the underlying DOM in some general purpose manner. Then, the workflow of the wrapping renderer would be: * Temporarily replace the response writer provided by the JSF implementation with one that creates a DOM * Call the rendering methods on the real renderer * Restore the previous response writer (so that the rest of the components on the page are rendered normally) * Provide API to access the resulting DOM * Provide a mechanism to specify zero or more transformations to be performed on the DOM * Provide a mechanism to "pretty print" the transformed DOM to the underlying writer. Craig
