Hi, This is a very good detail explanation given by Hans Bergsten
Looking through all the other threads dealing with this question, I see that most of the points have already been mentioned but let's see if I can give you a more conclusive answer. I describe this in more detail in the book, but my take on this is that Struts and JSF are focused on different parts of the application. They also overlap in some areas, however, which is probably the cause for this endless discussion. I refer to Struts as an "application framework". It's main goal in life is to hand off the processing of a request to code registered for the task indicated by the URI, and then hand off the response generation to another piece of code registered under a name returned by the request processing piece of code. Struts doesn't care much about how the request is processed or how the response is generated. Typically JSP is used to generate the response, and if so, there are tag libraries that can help, but you can use any template technology you like, e.g., Velocity. I refer to JSF as a "UI framework." It's focus is on user interface components, which are bound directly to business logic properties holding their values. A request is processed through these components with the help of other well-defined objects attached to the component. For instance, an input component reads its value from the request, converts it to the business logic data type by calling an attached converter, validates it by calling an attached validator, and if everything is okay, sets the business logic property bound to the component to the new value. A command component looks for a marker in the request that tells it if it triggered this request, and if so, queues an event. An event listener bound to the command component handles the event when all components have processed their input, typically by calling business logic code, and may return an "outcome" mapped to a "view ID" to tell JSF to use a different set of components to render the response. The response is generated by the components, or more commonly, by an attached renderer. So JSF hides a lot of the HTTP details and let you develop application code that's focused on the business objective rather that fiddling around with details that add no value to the application. More importantly, a JSF component handles both output and input. For instance, an date input component can let the user input the date by selecting a year, a month and a day from three separate selection lists. Because it knows this, it can correctly read the three input values, merge them and convert the value to a java.util.Date object and update the business logic with this Date object. Struts, on the other hand, may provide a JSP tag that generates the three selection elements, but your application code must know about it and get all three values from the request. The overlap is in validation and navigation. JSF provides just the basics for component level validation out-of-the box, while Struts offers a more sophisticated validation mechanism. I don't think the functional differences in navigation are so big, rather different because of differences between the framework. The important point, though, is that you can plug in custom validation and navigation support in JSF if the defaults aren't good enough for your application. So, that leaves us with the big question: which should I use? My standard answer is that for an existing Struts application, if you want to migrate to JSF for the user interface, it may be a good idea to do it piece by piece with the help of the Struts-JSF integration library if the application is big and complex. If it's small, it's pretty straight forward to migrate all of it to JSF in one shot. But first you need to ask yourself if migrating is the right thing to do. For a complex user interface, the answer is probably "yes" (at least if you're still making user interface changes now and then). For an application with a simple user interface (e.g., mostly simple dynamic output rather than a lot of complex input), or an application that's rarely changed, the answer is probably "no". For a new application, JSF would be my first choice if the user interface is complex, or plain JSP or some other template technology if the user interface is simple. If there are Struts features you can't live without, or don't want to implement as JSF plug-ins, I would take a look at the Struts-JSF integration library and consider using both. Regards Kamakshya Prasad Mishra Sourav, you might know me -----Original Message----- From: souravm [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 11:56 AM To: Struts Users Mailing List Subject: RE: Theoretical debate Hi All, My understanding is JSF is nothing but an improved implementation of Struts' philosophy where all Struts'' internals are made transparent to the end user. So what end user gets is - the same functionality of Struts but with lesser coding. In that way I find JSF to be logical extension of Struts. Please rectify me if my high level understanding is wrong. Regards, Sourav -----Original Message----- From: Hookom, Jacob [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 1:28 AM To: 'Struts Users Mailing List' Subject: RE: Theoretical debate I completely agree with what Crysalis is trying to push, also a framework called VRaptor (vraptor.org) also pushes the same idea of moving away from the procedural weight that Struts promotes. Look at JSF, do you have actions? No, JSF just updates your POJO beans and calls methods on them. Why have an ActionForm or have to create all of these Actions that are simply getter/setter adapters? Please don't be too quick to retort to my supposed anti-struts mindset, but there are other frameworks out there that allow direct interaction with my business objects and don't require a heck of a lot of framework specific coding. --- Example: To have a multi-page form with JSF, I just create a bean that sits in Session scope that has a series of getters and setters. JSF will also allow me to pre-set relationships to other objects at creation time. Then, when I'm ready to submit the multi-page form, I just put in the jsp #{myFormBean.submit}. No action mappings, only a managed bean entry. With Struts, I have to create an ActionForm objects (can't just use a business object I already have), and then create separate Action objects to manipulate that ActionForm. --- -Jacob Hookom -----Original Message----- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, June 17, 2004 2:29 PM To: [EMAIL PROTECTED] Subject: Theoretical debate Last night I was Googling for something and I stumbled across the Crysalis framework. I was actualyl intrigued by the underlying premise of it and I wanted to see what others thought about it. In a nutshell and in my own words, Crysalis (http://chrysalis.sourceforge.net/) has the underlying idea that when you develop in most MVC frameworks, Struts chief among them, you are actually doing something unnatural and in a way at odds with basic OOP design. Think about a shopping cart example... If you were going to write that in straight Java, not for the web or anything, how would you model it? Most likely you would have a ShoppingCart class with a number of methods in it, things like addItem(), removeItem(), totalPrice(), etc. In Struts, although you aren't FORCED to, what you GENERALLY do is create three different Action classes like addItemAction, removeItemAction and totalPriceAction, and each is called in response to a form submission. But isn't it kind of odd that your object model isn't following what you probably think in your head is the right way, i.e., one class with multiple related methods? Proper encapsulation and all that jazz, right? Well, Crysalis does just that. It's controller elements are regular Java classes with multiple methods. What you wind up with is something that resembles Remote Procedure Calls instead of numerous servlets as controllers. In other words, you would create the ShoppingCart object just as I described above, with all three methods. Then, when you submit a form, the action is something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart is the class to execute, addItem the method and cmd is a suffix to direct the request, just like extensions in your Struts apps map requests to ActionServlet. The elements of the submitted form are treated as the parameters of the method being called, making it rather elegant. I haven't gotten into any real detail on Crysalis, but I was interested in getting other peoples' thoughts on the underlying principal (which I *THINK* I've stated properly!). It was rather interesting to me because I'd never reall considered looking at it that way, and certainly it's not the way you typically approach a Struts-based application. It was also interesting to me because I've for about four years now been preaching here at work that we should write our applications as a collection of services that are executed to form a coherent larger application, which is very much along the lines of this (so I guess I actually HAVE looked at it this way in a sense, but not exactly). Any thoughts? Frank _________________________________________________________________ Watch the online reality show Mixed Messages with a friend and enter to win a trip to NY http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/ 01/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
