Craig, *Exactly* what I was looking for, thanks. Yes, we're keeping an eye on MyFaces, Facelets, Tomahawk components, IBM Components (We have Rational Application Developer and IBM ships some components), and the recent news of Oracle donating many components to add to Tomahawk.
If I get a chance, I'll play with the remoting stuff and see if I can't find a good use for it in one of our apps. Thanks again, -Troy Troy J. Kelley E-gineering, LLC 10401 North Meridian Street | Suite 150 Indianapolis, IN | 46290 | 317.616.3974 www.e-gineering.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, January 30, 2006 3:46 PM To: Struts Users Mailing List Subject: Re: Strategy for incorporating Shale w/JSF Inline. On 1/30/06, Troy J. Kelley <[EMAIL PROTECTED]> wrote: > > I did my best to see if this was already addressed by searching mail > archives. All I found so far is a comment from Craig here: > > http://marc.theaimsgroup.com/?l=struts-user&m=112604395721097&w=2 > > Craig writes: > "If, on the other hand, you decide to commit to JSF's controller early > rather than late, you might as well just use Shale along with it from the > beginning. Unlike the way that other frameworks deal with JSF, Shale > *assumes* you will be using the JSF controller architecture, and it just > adds ease of use around problems you'll face anyway. It doesn't try to treat > JSF as purely a component architecture." > > I'm in a situation where I'm consulting in a corporate environment. I > really love what shale has to offer, but I'm concerned about adopting things > a bit too early. I checked out the "API Stability" section of the project > docs (http://struts.apache.org/struts-shale/api-stability.html - which is > great, btw) Thanks ... I hope it nudges my fellow framework developers (both here and other webapp projects) to provide the same sort of information. and I'm trying to answer the question: > > What components of shale can I integrate into a JSF app and get the > biggest benefit from, without sacrificing stability at the functional and > API level? > > For instance, shale-core is a mixture of Developing and Evolving packages > at both the Application and Framework level. If I'm writing and enterprise > app that's going to production in 6 months, how do I choose wisely? :-) The most conservative approach would be to use the following rules: * Stay away from any package targeted as "Framework" ... that's for modifying Shale itself, rather than using it. (If you find yourself tempted to change things here, please file RFEs so we can make the stuff you need a standard part of Shale). * Stick with packages marked as "Stable" or "Evolving". In practical terms, that means (as of today): * The JSF components provided by Shale are only those needed to integrate framework capabilities ... I don't forsee Shale itself becoming a general repository for JSF components. Instead, it should interoperate nicely with libraries like those from MyFaces. * The ViewController APIs (org.apache.shale.view) that an application requires are solid, although new features might get added later. One reason for my confidence here is that Sun Java Studio Creator 2 (for which I'm the architect) provides very similar (paranoids would say "suspiciously" similar :-) capabilities in the page beans that it produces for you, and the paradigm seems to fit the proposed application design pattern quite nicey. * The dialog stuff (one of my favorite features) is marked as "Evolving" not because I expect to break backwards compatibility, but because some known deficiences need to be addressed (particularly in dealing with more than one simulataneously active dialog) that *might* require such changes. Even in that circumstance, I would strive to not break old apps (one of the reasons Struts 1.x was and is popular is we were really conservative about changes like this) ... but it's not yet clear what we might need/want to do to finish this functionality. * I'm pretty happy with the new remoting stuff (org.apache.shale.remoting) but it's going to stay "Evolving" until someone actually *does* use it and provides some feedback. Hows that Catch-22 for you? :-). (It also needs better documentation ... in progress.) * Do not assume that APIs marked "Developing" necessarily *will* break -- so depending on them shouldn't be dismissed out of hand. It's just that the likelihood of needing adaptations here is slightly higher than "Evolving" packages. I've included the start of a package dependency diagram that might help - > it's incomplete. I figured somebody might know this by heart, and could > finish it quickly :-) Feel free to distribute. I don't see the attachment, but as long as you stick with the packages targeted at *Application* deveopers rather than *Framework* developers, you should not have to care about internal-to-Shale dependencies on the framework stuff. That's our job to deal with any changes there. You should focus on using the public application APIs only. I've spent the past several days doing research on web app frameworks and > JSF is a contender for *this environment* - but only becomes more promising > with offerings like facelets and shale (IMHO). Certainly looks like a contender to me :-). And don't forget to look at the components over at http://myfaces.apache.org-- they are doing some interesting things. Much more comprehensive than the sum total of all the UI-oriented JSP tag libraries I have looked at to date. That's one of the benefits of a common base API. Thanks, > -Troy Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
