I like the idea of convetion a lot more with components here-- because
you aren't directly invoking your business model, you can do more with
convention without security issues such that all you would have to do is:
// JAVA - on the Renderer
public Object onSuggest(FacesContext faces, UIComponent c) ...
// JAVA - on the Component
public Object onSuggest(FacesContext faces) ...
Then on the client:
new Faces.Event(clientId, "suggest", callback);
That should be it for wiring code and would allow any component any
number of events it can use with it's client-side or Dojo representation.
Adam Winer wrote:
The Renderer does certainly need to know that it is handling an
AJAX request, but any Renderer that is capable of initiating
an AJAX request would, just like they're already capable of
detecting events to their components during decode().
-- Adam
On 4/29/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
The components are delegating the method calls to their corresponding
renderers - it's just like with the default lifecycle related methods.
One question - how would you propose to handle special cases - e.g. an
inputSuggest components doesn't render itself normally on an ajax
request, but renders a list of suggested items?
regards,
Martin
On 4/29/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> Gerald,
>
> Once you start allowing multiple components to be updated,
> *a lot* of possibilities open up.
>
> My big concern with the approach being recommended here is
> that it treats Ajax requests as radically different from all
> other requests, which ends up defeating a lot of the benefits
> of the JSF lifecycle, and forces components to expose
> "too much".
>
> Why, for instance, do you need special "encodeAjax" or
> "decodeAjax" methods on the component? What if a Renderer -
> independently of the component - wishes to add AJAX-style
> feedback?
>
> -- Adam
>
>
>
> On 4/29/06, Gerald Müllan <[EMAIL PROTECTED]> wrote:
> > As far as i know we wanted to update only one component per request
> > with our actual approach.
> >
> > I think we should separate the need of updating the model (like
> > anywhere) and having an ajax response to show something special
> > (visualisation etc.) on the client.
> >
> > cheers,
> >
> > Gerald
> >
> > On 4/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> > > Hi!
> > > > If we rely on our "affectedAjaxComponent" approach (seeking
comp and
> > > > calling methods on it) we are little bit restricted in coding.
> > > If this mean that we can update only one component per request,
then I
> > > would like to see to at least extends this approach.
> > >
> > > Beside the fact that a component would like to update its own
> > > data/layout/etc I would like to be able to update other
components too.
> > >
> > > Say if you have a button "calculate" this should update the
model and
> > > then update the output of n other components.
> > > Something like zones in ajaxanywhere (partial page rendering).
> > >
> > > Or is this wish out of scope of the current discussion?
> > >
> > > Ciao,
> > > Mario
> > >
> > >
> >
> >
> > --
> > Gerald Müllan
> > Schelleingasse 2/11
> > 1040 Vienna, Austria
> > 0043 699 11772506
> > [EMAIL PROTECTED]
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
--------------------------
Sent from my FrankenBerry Wireless Handheld
