On 7/12/05, Werner Punz <[EMAIL PROTECTED]> wrote: > 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. >
FWIW, the current implementation in Shale sets up a FacesContext for a remote request, but doesn't actually fire the JSF lifecycle. The primary reason for this was to make it possible to do programmatic value binding and method binding evaluations while preparing the response. The Shale filter also uses the incomding request URI to map to a Commons Chain command (or chain) definition, so you can easily compose the response using fine grained reusable commands. Martin's approach does sound very feasible, but I have one question (not having had time to look at the code yet) ... does the "component" to which the request is routed belong to the component tree of the view from which the asynchronous request was submitted, or is it totally separate? Ed Burns has posted an example of the former approach in the BluePrints Catalog (https://bpcatalog.dev.java.net), which is designed for cases where the client might be manipulating the DOM on the client side, and wants to keep the server side state information in sync. That's probably overkill for simple autocompletion and "look up some values" sorts of interactions, so I suspect both models will have interesting use cases. > Werner Craig
