On 1/14/07, JS Portal Support <[EMAIL PROTECTED]> wrote:
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?
"Whatever DOJO does and more" is not quite right ... jMaki doesn't currently cover all of DOJO (or any of the other frameworks), and like any abstraction layer its simplifications sometimes hide some of the capabilities of the underlying widgets. On the other hand, the ability to mix and match widgets from different libraries is pretty handy if you need it. Which is right for you? Don't know ... that's really your call, depending on your requirements :-). The best thing to do would ge articulate the kinds of capabilities you need, and see if there is a widget library that addresses all of those needs directly. If there is, you might want to look at just using that library directly. On the other hand, if you really need multiple libraries, or you like the simplifications that jMaki provides, it can be useful. I agree with Kito's comments about how the existing jMaki JSF integration is not particularly in the style of other JSF components. I'm doing some work in the jMaki project (contributions welcome ... it's open source) to provide a more "traditional" style JSF component library that uses jMaki to do all the rendering grunt work, but provides a component-per-widget environment that JSF based developers will be familiar with. It might be worth taking a look at that, although it's in its early stages (six widgets wrapped so far). Cheers,
Joost
Craig -----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
