On 5/1/06, Travis Reeder <[EMAIL PROTECTED]> wrote:
Great comments Sharath and I agree with all of them.
On 4/28/06, sharath reddy <[EMAIL PROTECTED]> wrote:
> Here are some of the inputs we came up with:
> 1. There are too many special cases in the Phase
> Listener code:
>
> if (component instanceof SuggestAjax) //do something
> if (component instanceof HtmlCommandButtonAjax) ....
> if (ajaxComponent instanceof UIComponentPerspective)
> ...
>
> In our opinion, all this logic should be moved into
> their respective components. The phase listener should
> not be aware of these distinctions.
Definitely.
I totally agree - the big question is what the contract
is between a phase listener or lifecycle and the individual
components. Adding a specific interface that must
be implemented, especially at the component level, is,
IMO, undesirable - the approach Jacob suggests is more
flexible.
> 2. The responsibility for rendering the response
> should lie entirely with the component. The current
> code does something like this:
>
> out.print("<?xml version=\"1.0\"?>\n");
>
> out.print("<response>\n");
>
> ((AjaxComponent) component).encodeAjax(context);
>
> out.print("</response>");
>
> Due to this approach, the component-writer has 2
> disadvantages:
> a. He is forced to render an xml response. Other
> options are ruled out.
> b. If he wants to use an XML API (say, JDOM) to render
> the response, he is contrained, as the root element
> 'response' has already been rendered in the output
> stream.
Good point, this could easily be moved into AjaxRendererUtils.encodeAjax
since most of the form components just call back to that anyways to handle
common cases. I was heading in a different direction with the generic
listener update, where it would send the response wrapper and put the pay
dirt in a cdata section, but it may be easier to just return different types
of responses depending on the component.
I'm not enthused about that - for one thing, it makes
it essentially impossible to send responses from two different
components in response to one request. And that's so
incredibly useful that you really shouldn't shut the door on it.
IMO, MyFaces should just pick a blessed format for sending
responses that is flexible enough to support multiple responses
per request (and sending back at least both XML and HTML
content, and preferably also embedded JSON), and just tell
people to stick with that.
Regards,
Adam
> 3. The existing component(s) ? that still use
> Prototype library should be converted to use Dojo.
Yes, this is just a matter of getting'er done.
> Obviously the existing components will have to be
> altered concurrently with the changes in the Phase
> Listener, so that they continue working. Anyone have a
> suggestion for the best way to go forward?
>
>
I don't think this would be too difficult. For 1, you would have to see if
it's possible to just move what's inside the instanceof blocks into the
encodeAjax method of the component. For 2, answered above. For 3, I *think*
the only real dependency on prototype in the form components is the
Ajax.Request() statement in inputAjax.js. Change that to use dojo and swap
the addResource in AjaxRendererUtils too. The autoupdatedatatable might be
a bit trickier though, because it uses the prototype Updater and I'm not
sure if dojo has that.
Travis