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
