Jack Dragano wrote:This is good if the form contains no errors, but if not, I cannot display them because I've already moved from viewProduct, losing its state.
Jack Dragano wrote:I read that usually Struts 2 programmers use the same action for both showing the "first-request" page (the one I print now with viewProduct) and then working with inputs, but for both code cleanness and logic subdivision I prefer to keep two separated actions (merging them would result in a little chaos).
It is wise to avoid creating lengthy and complex Action classes. If you start to embed too much logic in the Action class itself, you will begin to find the Action class hard to understand, maintain, and impossible to reuse. Rather than creating overly complex Action classes, it is generally a good practice to move most of the persistence, and "business logic" to a separate application layer. When an Action class becomes lengthy and procedural, it may be a good time to refactor your application architecture and move some of this logic to another conceptual layer; otherwise, you may be left with an inflexible application which can only be accessed in a web-application environment. The framework should be viewed as simply the foundation for implementing MVC in your applications. Struts provides a useful control layer, but it is not a fully featured platform for building MVC applications, soup to nuts.
Jack Dragano wrote:
Plus, using the same action does not allow the framework (or I don't know how to make it) to distinguish between a first request, where input fields are obviously empty, and subsequent requests, where empty fields mean errors. This is not good, of course, because in this way a customer gets an error by simply viewing a product.
Joe Ess wrote:What does your action configuration look like? One usually specifies an "input" result for the validator to return to.
Joe Ess wrote:This sounds like your are putting all your logic in the action class. Bad Idea:
Joe Ess wrote:One can map any number of action names to an action class, and those action names can invoke different methods with different behavior.
in the case that parameters are wrong, I don't know how I can go back to viewProduct with making Struts informing the user about which fields are wrong.
They are short, but I don't want to merge them because in my mind they are two different operations.
Joe Ess wrote:What happens if you make viewProduct.jsp the input result for the addToCart action?
Joe Ess wrote:There's a "method" attribute that changes the method invoked in your action from execute() to whatever you want:
Consider Paul's rocket mass heater. |