Correctly stated, some of the Struts taglibs have been superseded by JSTL. We are starting a major new project and we are trying to guess which technologies have the best viability. We have made a decision to use Struts because it is the best current solution and we think the controller aspects of Struts will be around for several years. We will use JSTL because it is a functional standard that is easy to use and it integrates with the Struts html-el tags. We have a "wait and see" attitude toward JSF.
As someone who started out processing HTML forms with CGI and PERL, I am very thankful for the contributions made by the Struts team. I often wonder why the JCP didn't take in Struts as a standard and build on that standard. Instead, it looks like they kidnapped one of the main developers of Struts and started from scratch with Java Server Faces. :) The key point in determining the dominance of a technology is the quality of the tools developed to implement that technology (the "Beast of Redmond" clearly understands this concept). People who have resources to invest in the development of tools are going to make that investment based on establish standards. That is why I think JSF will eventually supersede Struts. Regarding a persistence model, Mark Galbreath is right, JDO is a simple answer and JDO is a standard. JDO may turn out to be the answer, if the EJB specification team does not build upon the improvements made in EJB 2.0. Right now, the EJB standard is certainly not perfect, but it is OK. My guess/hope is that the EJB standard will continue to improve. As stated earlier, XDoclet makes EJB incredibly cool to use. There is a very good book that goes into great detail on these issues: Bitter EJB, by Tate, Clark, Lee, Linsky. http://www.amazon.com/exec/obidos/ASIN/1930110952/qid%3D1065295596/sr%3D11-1/ref%3Dsr%5F11%5F1/102-7314677-9317754 According to the authors, JBoss 4.0 will offer service decoupling, "...hopefully, other application service vendors [and the EJB specification team] will follow its lead." One of the interesting things I learned by reading this book is that Entity Beans were an afterthought to the original EJB spec. In early drafts, the EJB spec was focused exclusively on distributed components, not persistence. It is not surprising that the original persistence mechanism was poor. My guess/hope is that within a year there will be a completely decoupled fine grained persistence service within EJB. Perhaps there will be some sort of "byte code enhancement" for entity beans. :( Mike --- Ted Husted <[EMAIL PROTECTED]> wrote: > Mike Duffy wrote: > > In the short term, a non-standard solution may be the only choice available. If > > so, the best > > thing to do is to design your code in a way that isolates the non-standard > > components. If you > > really think Hibernate or iBATIS is the way to go, then go through delegates to > > your data > access > > layer. This will make future changes less painful. > > Very good advice. Both the Hibernate and iBATIS teams consider using a > DAO layer to be a best practice (and I suspect OJB does too). iBATIS > ships a DAO framework as a separate component which works with most > anything you can name, including Hibernate and EJBs. > > > > Because Struts will eventually be superseded by Java Serer Faces, I strongly > > recommend that > you > > keep your Action classes as light as possible. > > Most people have always recommended keeping your Action classes as light > as possible. Still good advice. But, I don't think that most people > believe that it is a foregone conclusion that Struts will be superseded > by JSF. There are people who say such things, but saying it doesn't make > it so. > > JSF does include a navigational element that will be enough for many > applications. But it does not include anything like the Struts > Controller. Or Tiles. Or the Validator, Struts-Menu, Struts-Workflow, > Struts-BSF, and so forth. > > I'd say something like "JSF has a lot of catching up to do", but it's > not an either/or decision. People can, and I'm sure will, use Struts and > JSF together. The technologies are complementary. Struts is strongest > where JSF is weakest, and vice versa. > > JDBC didn't eliminate the need for packages like Hibernate and iBATIS. > JSP didn't eliminate the need for XLS or Velocity templates. JSTL didn't > eliminate the need for custom taglibs. And JSF won't be the final > solution either. These types of specifications are only the beginning. > > > > Note: Many of the Struts functions have already been superseded by the functions > > of the JSTL. > > > There is no longer a need for Struts bean tags or logic tags. There is a need for > > the Struts > > html-el tags. They allow interaction with JSTL and enable the MVC funtionality. > > If you limit > > your use of Struts tags now, you'll be able to make an easier transition to Java > > Server Faces > and > > JSTL. > > Many of the functions of the Struts JSP taglibs are being superseded > (thankfully!), but Struts is primarily a Controller. The bundled taglibs > are one way to access the Controller, but there are many others, such as > the Velocity Tools and Stxx. > > The taglibs generate a lot of traffic on the list (and hopefully JSF > will draw some that fire someday). But they are not what define Struts. > Struts is the C in MVC. The taglibs are just a proof of concept. (And a > great one at that, given they help spawn things like JSTL and JSF.) > > With JSF and Commons Chain helping to define what it means to be a View > and a Model, we will finally have the freedom to focus on our core > business: what it means to be a Controller. > > -Ted. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
