>Funny; I was thinking the same thing about the static context stuff in JSF >that makes it really difficult to test in isolation.
What makes you think that's difficult? I'm sure you're aware of mock objects. There are a number of mock JSF test frameworks---JMock and Shale come to mind. Writing actions and beans that extend or inherit MVC classes/interfaces are worse than "static context stuff" because: 1. Java doesn't have multiple inheritance so if you want to make your own base classes, you're forced to create an inheritance chain tied to the MVC framework 2. Swapping out frameworks is next to impossible. 3. Classes can't stand on their own. 4. It's easier for Java beginners to mix business logic with MVC framework code. We've been down this road before with struts1. Spring-MVC brought us the next generation of thinking by making all framework dependencies interfaces (implementations are provided but not required, like struts2). JSF takes this idea to its logical conclusion. If your action and bean methods only refer to a framework context (which, by the way, *is* injectable with Seam or with your own VariableResolver, contrary to your statement in a previous post. For example, http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977385), you can write them to support multiple frameworks simultaneously. In practice, no one does this, but it demonstrates the flexibility of the JSF approach. I can, for example, write an action class that works with both Struts2 and JSF: public class CreateCustomerAction extends ActionSupport /* ActionSupport req'd by struts2 */ { ... ... /** Stuts2 action */ public String execute() throws Exception { if (!customerDAO.create(...)) addActionError("Unable to create customer"); return INPUT; } /** JSF action */ public String createCustomer() { if (!customerDAO.create(...)) FacesContext.getCurrentInstance().addMessage("someId", "Unable to create customer"); return "input"; } } If JSF required the extension of a framework class or implementation of a framework interface like struts2 does, the code above couldn't be written without a mixin/delegation (esp. if the interfaces shared the same method names like execute()). I hope you can see how JSF has a lighter footprint than struts2. *************************** IMPORTANT NOTE***************************** The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman & Co., its subsidiaries and affiliates ("BBH"). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus. ************************************************************************ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
