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

Reply via email to