Thanks Craig, your comments will help in my deliberations at the moment, I appreciate you taking the time to reply :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, November 22, 2005 2:35 pm, Craig McClanahan said: > On 11/22/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >> On Tue, November 22, 2005 1:24 pm, Craig McClanahan said: >> > For the long term, I absolutely agree with you ... and Shale will >> > certainly >> > serve as good "research and development" for what should be >> standardized >> > in >> > JSF 2.0. >> >> Craig, that's an interesting comment, and I'd like to ask you to expand >> on >> it... specifically, are there plans to ensure forward-compatibility >> between Shale and JSF 2.0? > > > *Nobody* can make that kind of a promise ... the results of the JSF > 2.0expert group deliberations will determine what actually happens in > JSF > 2.0. At the very least, the package names would change to " > javax.faces.something" ... but it's likely to be a lot more than that -- > standardization is a synthesis of approaches to individual technology > areas, > not an *annointing* of the particular approach taken by one individual > package. > > A current analogy is what's going on with the Java Persistence API spec > being developed as part of EJB3. The technology is fundamentally pretty > similar to Hibernate, but it is *not* identical. Instead, Hibernate has > plans to become an *implementation* of the new spec (along with potential > other implementors such as TopLink). > > The question I'm really getting at is if I start a Shale app today, >> ignoring whatever changes may come down in Shale itself since it's still >> a >> work-in-progress, will I be able to migrate my app to JSF 2.0, which it >> *sounds* like should wind up being comperable to Shale in terms of what >> it >> offers, or do I really need to make a choice between two divergent paths >> (even if the paths largely wind up intersecting)? >> >> In other words, is Shale future-proof with regard to JSF 2.0? :) > > > There's absolutely no way for me or anyone else to predict exactly what > JSF > 2.0 will look like. > > That being said, I'm personally committed to ensure that Shale evolves in > a > way that is compatible with the future of JSF. If JSF 2.0 offers a > different > approach to the same functional issue, Shale will continue to support its > own, while also being compatible with the new "standard" way to do the > same > thing. > > In other words, if you start with Shale today you get to use cool stuff > like > ViewController and Dialogs now, instead of waiting months or years for JSF > 2.0 to standardize them, and then some undefined longer amount of time for > the JSF implementations to catch up. > > As a Struts project, once Shale gets to a General Availablility release > (which *definitely* won't be true for at least the first few milestones), > it > will share the Struts community passion for backwards compatibility. > However, even today, the documentation will include an indication of API > stability for each individual package, so you can focus on the parts of > Shale you plan to take advantage of. (This section seems to have gotten > dropped from the javadocs, so I'm going to pull it out as a separate page > in > the website.) > >> Craig >> >> Frank > > > Craig > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
