Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of gcjmu-myfaces-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@myfaces.apache.org
From: Werner Punz <werpu@gmx.at>
Subject: Re: Ajax (back end)
Date: Tue, 12 Jul 2005 21:56:40 +0200
Lines: 67
Message-ID: <db179q$vda$1@sea.gmane.org>
References: <71235db405071211312aac917d@mail.gmail.com>
Reply-To: werpu@gmx.at
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
In-Reply-To: <71235db405071211312aac917d@mail.gmail.com>
Sender: news <news@sea.gmane.org>

Dont know about Shale, but I checked out Martins Code today, and I must 
say how he handles the whole frontend/backend issue is the best approach 
I have seen so far, from a JSF perspective.

What he does basically is to route the Phaselistener intercepting code 
for the ajax request directly into the component and from there into the 
renderer and for the value binding stuff he reuses the bindings already 
in the JSF system.

what he could do by that was to enapsule the whole remoting mechanism 
and data to xml transformation mechanism into the component itself and 
reuse the value binding mechanisms and the control binding mechanisms 
from JSF.
Implementing a AJAX backend on top of that stuff is pretty much the same 
as implementing a normal form/control backend, you use backend beans and 
bindings, set the values from the backend into the binding and be done 
with it.

Much leaner to implement than the way I did it.
What I did was to use a Servlet (you can replace that with a phase 
listener) and use an Apache Turbine like event mapping into a backend 
bean for the full processing, the whole data->xml tranformation was done 
by a separate builder class.
Feasable approach to a tad too much out of the JSF context. I was able 
to reuse the SelectItems but I had no almost transparent backend 
frontend binding, like Martin managed to pull off.

Werner


Matthias Wessendorf wrote:
> hi all,
> 
> I am prototyping a simple ajax component. For something like suggest ...
> I wrote a custom Renderer and a Tag_clazz (reusing UIInput). Since I
> couldn't use the ExtensionFilter and the nice AddResource clazzes I
> created a simplified version of both, that fit my needs...
> 
> Currently I am removing the Filter in case of a PhaseListener, which
> hooks *after* RestoreView into; to ships the JavaScript (like
> ExtensionFilter does) and also handles the XmlHttpRequest stuff to
> interact with Faces' backing beans (via ValueBinding).
> 
> I like the approach of the PhaseListener more ;) It looks similar to
> the bpcatalog stuff
> (I guess the stuff from Werner is also similar to that, isn't it).
> 
Yes I got most of my ideas from the blueprings, including the phase 
listener approaches and the servlet approaches.

> On other thing that was on my list, was the way how Shale handles
> *remote* requests. In "use cases app" there are some requests the end
> with ".remote". Those requests are handled by Shale's Commons Chain
> facility.
> 
> I haven't tested my prototype agains Shale's CoR *remote* catalog, but
> currently I mostly like the PhaseListener stuff (compared with filter)
> :)
> 
> So has anyone used the remote catalog of Shale (for ajaxian stuff) in
> his project? So if yes, are there benefits instead of using a
> PhaseListener?
> 
> Comments are welcome :)
> 
> -Matthias
>