On 12/6/06, Hermod Opstvedt <[EMAIL PROTECTED]> wrote:
Hi I think we need to give this a good hard thought. What you (if I read you right) are saying in essence is that Shale/Clay and Ajax will not work.
You are not understanding Gary correctly. What you are trying to do, it seems, is based on incorrect expectations. With regards to JSF and AJAX, there are two fundamental paradigms that can be addressed: * Keep the JSF component tree up to date with respect to dynamic changes that happen because of asynchronous interactions. * Ignore the JSF component tree, and just serve the asynchronous requests. You seem to be expecting the former, and blaming Clay because this doesn't happen. The reality is that Shale Remoting is focused on the latter case, not the former. The fact that synchronizing changes to the component tree is based on that fact -- using Clay, or JSP, or Facelets, or anything else as the view tier has nothing to do with it. There are many solutions to the former use case. Unfortunately, most of them seem to be intimately tied to a particular component library. One that is not, which pleases me from an architectural viewpoint, is Dynamic Faces ( https://jsf-extensions.dev.java.net), which will work just fine with Shale functionality. Please don't assume that Clay is the problem here -- it should NOT have the responsibility for synchronizing the component trees. If you need that, use a framework in concert with Clay that supports this. If you don't (and therefore can achieve better overhead because you're not sending dynamically updated component trees for the entire page back and forth), use Shale Remoting. The key -- your goal should be that these decisions (sync versus not, and which view technology you like) should be independently mixable, not forced upon you by the choice of one or the other. Craig
