Craig, I was talking to Greg Murray about jMaki at Javapolis, and I mentioned the possibility of generating JSF components based on some metadata much like the RI and MyFaces do for the HTML components and the tag libraries. (I don't think Greg fully appreciates the value of the JSF model.) Are you taking a code-generation approach or more of a hand-crafted approach?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Craig McClanahan > Sent: Sunday, January 14, 2007 9: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 >
