By the sounds of it jMaki is the way to go then. I understand you might be a bit bias here, but if it does whatever DOJO does and more, capturing all frameworks, what would be the reason for choosing any other framework?
Cheers, Joost -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, January 15, 2007 3:29 PM To: user@shale.apache.org Subject: Re: How to pass object between backing beans On 1/14/07, JS Portal Support <[EMAIL PROTECTED]> wrote: > > Craig, > > Great, it now works nicely and is portable to any other view I might > create > in the future without altering my GenericTable view. Cool ... that's the way it's supposed to work :-). On a different note: > Is it correct btw that MyFaces will use DOJO AJAX toolkit as its script > engine of choice? As we are currently looking at our options it seems to > me > this will be the wisest choice right? More specifically, the component libraries at MyFaces (Tomahawk and Tobago in the MyFaces project now, Trinidad in the incutabor) have tended to choose Dojo for their Ajax support. That's more up to each individual library than it is up to MyFaces as a whole. And, as a general policy, I can't disagree that it is a reasonable choice. I used Dojo also in our work on the Blueprints Ajax components[1] that ship with Java Studio Creator and NetBeans Visual Web Pack. We made that choice originally because of the nice lower level APIs for asynchronous messaging and eventing on the client side. I've been pretty happy with those layers, but not quite as happy with the UI widget layer -- which has been going through a lot of evolution lately but is looking more settled as we go on. Personally, I'm spending a bunch of time today on the jMaki project[2], where a primary goal is to let you avoid locking yourself into one particular widget framework. jMaki strives to provide a common adapter API around various widget libraries (including Dojo, Spry, Scriptaculous, Yahoo, and a bunch of others) to both reduce complexity and support mix-and-match. Today, there's a low level JSF component that provides direct connection to a large portion of these libraries, but with a fairly low level API. I'm also working on adding a layer of JSF components per widget that will appeal more to someone familiar with traditional JSF composition of your views ... and, will fit very nicely into visual development tools. Needless to say, this all works very nicely with Shale :-). I have to say the more I learn about shale/MyFaces the more excited I get. > We come from a custom build mvc which we respectfully will lay to rest now > :-) :-) Thanks, > Joost Craig