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
