On 1/21/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > >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.
Its actually easier than that. If you provide a custom ResponseWriter, the renderer builds the DOM for you. After all, its calling methods like startElement(), writeAttribute(), and endElement() already. We don't need to deal with a string representation at all, until *after* the transformations have been completed. > 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. It would seem you need to configure the following information somehow: * What renderer do I want to wrap? (Identified by component-family and renderer-type) * What transformations do I want to perform (including figuring out whethe to represent those transformations as stylesheets or Java code or both None of this fits into the standard faces-config.xml architecture, so it'd have to be done in an external one. One implementation detail I hadn't thought of last night will become important ... it's not just the one renderer's encodeXxx calls that you want to capture. You'll want to use the same renderer to apply all the rest of the way down the component tree. Otherwise, you'll have interweaving problems between elements created by this component and by its children. That's going to require a slightly different approach than the hard coded version in the Alternative 2 patch right now. 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. This would be trivially simple to add to shale-tiger. Good idea. Might as well do validators and converters too, while we're at it :-). I wonder if we could share some of the factories and config beans with > tiger. Those config beans are for the standard faces-config.xml archiecture. I'm not sure we can squeeze the info we want into that scheme anyway. > * 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. Yep. > > > Craig > > Gary > Craig
