>From: Craig McClanahan <[EMAIL PROTECTED]> > > On 1/20/06, Gary VanMatre 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 :-).
No doubt! That would get to gooey :--) >We'd just want to provide a way to hook in > transformations on the underlying DOM in some general purpose manner. > What about using the Clay parser here? It seems to be handling anything with <sharp pointy things>. I guess that we could use the clay tokenizer to build a DOM, a hybrid parser. We would be ready to generate well-formed html in a API that people are more comfortable using. We would have to move some small parts of clay to the core. > 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 What do you think it terms of configuration? Should we create a separate config file that uses a similar faces config XML structure. Seems similar to what you have done with tiger but we still might need a configuration file. On a quick tangent, components and renders registered using annotations would be handy. This would make room for easy simple disposable components that had specific purposes within a single application. I wonder if we could share some of the factories and config beans with tiger. > * 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. > It would give Shale a edge in the component business without providing components. It could be something used by any component library without having to tie into the implementation. > > Craig > Gary
