On 3/20/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Craig McClanahan wrote: > > Common in the future? That's the plan ... it's especially designed for > > folks who want to create the server side of AJAX interactions, plus > people > > who want to write AJAX-enabled components. The power of expression > > evaluation, plus the "basic dependency injection" capabilities of > managed > > beans, are just too much goodness to pass up. > > Obviously going OT for this thread, so I'd be happy to start a new one > if you want, but this is very interesting to me as a pretty big AJAX > booster.. > > Have you ever looked at DWR? I wonder what your impression is of that? > Especially since it has Spring integration, which I'm sure you would > agree if better dependency injection than the basic capabilities JSF > provides, and since it works with *any* framework, and allows you to > access POJOs, I would personally favor that than start using a whole new > framework. What benefits would you say there are to using Shale/JSF > than that with any other framework over a DWR-based solution? Certainly > you can fire off a chain in any case if that's your need, so I don't see > that as being one. Again, just curious here as an "AJAX guy".
I've looked at DWR some, but the guys here that did the initial research on AJAX frameworks liked DOJO better. Doesn't mean DWR is in any way "bad", mind you ... just that we chose differently. I guess what I'm *really* getting at is to ask doesn't AJAX make much of > this JSF/Shale vs. Struts vs. WW vs. Tapestry vs. whatever else somewhat > irrelevant? Might it even be better to just develop the Shale remoting > as a separate AJAX library? > > Not trying to pick fight :-) Not swinging back either :-). At a 30,000 foot level, there are three basic architectures for usng AJAX (and yes, they overlap a bunch too): * "Eye Candy" -- add a little bit of asynch interactivity to an existing application, often done by utilizing existing JavaScript event handlers on the relevant HTML tags directly (perhaps with the help of a client side JS library, perhaps with just hand coded cut-n-paste JS that you saw on some website). * "Server Side UI" -- the UI of an app fundamentally based on widgets with asynchronous callbacks, but it's still rendered on the server side as is typical of webapps today ... except that the JavaScript/DHTML madness is encapsulated in some sort of API (custom tags, JSF components, PHP objects, whatever) that hides the complexity from the developer. * "Client Side Controller" -- the app itself moves to the client side, and asynch callbacks are strictly for exchanging model tier data. JSF UI components (as well as the framework) work great for the first two cases. The UI components are of less use in the third case (although in an ideal scenario the client side widgets you encapsulated with JSF components for the first two cases is the same code you use directly for the third case), but the framework part is still fully capable of doing what you need to map incoming requests to particular business logic, and helping you format the response. Shale Remoting is still very useful in the third case (as well as being a nice utility library for those building JSF components to handle the first two cases). By the way, I agree with you that Spring's dependency injection is more powerful than that provided by JSF managed beans. Wouldn't it be cool if you could use both Spring and JSF together, but configure your JSF managed beans in Spring just like you do your business logic beans? Oh yah ... that's already possible :-). Spring includes integration with JSF's expression evaluation facilities, so you can use Spring-created beans in your JSF value binding and method binding expressions, without the expression user (UI component, Shale Remoting mapping of an AJAX request, whatever) having to know that. And that one doesn't even take Shale ... basic support for this comes out of the box with Spring, and there's an extension library at SourceForge if you want to get a little fancier (i.e. put Spring-managed beans into request/session/application scope automatically, not just create singletons and per-request instances). > Craig > > Frank Craig
