Error Handling Strategy
I really do not like the way my current application handles errors as every error requires three or four lines and it is very redundant. I have been reading a lot about Exception(s) and how developers are slowly seeing the benefits of extending their Exception(s) from RuntimeException freeing coders from writing catch blocks when they can't do anything about it or just throwing it up again adding "throws SQLException" to every method up the line. With the exception (no pun intended) of using ActionErrors in ActionForm.validate(), could anyone tell me why it wouldn't be much better to use Exceptions to handle errors. Say I have three layers in my application: model, business, controller/view. If the model error throws an Exception and not a RuntimeException, both the business and the controller/view layers have to catch it or pass it on. With RuntimeExceptions you have the best of both worlds: you don't have to do ANYTHING if you don't know what to do with it, or if you do know what to do with it, you can catch it. In my new application design I am employeeing this strategy and using custom ExceptionHandler classes to catch, log, and redirect the user to the appropriate pages. In my Exception classes, instead of a non-localized string as the exception message, I use a message key which I can then retrieve and translate into a localized string for the end user. This has two main benefits: you are forced to actually THINK about your error messages as you need to look them up in a properties file and they can be organized somewhat categorically AND you don't have to write two different error messages for both the developer and the end user. If the developer wants more information, he can look at the error log for the stack trace. Can anyone tell me why this isn't a good idea? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ActionForms and Interfaces
While reading through the DynaActionForm debate, I wondered if using Interfaces as well as inheritance might be a good alternative for those who want type enforcement but don't want to duplicate common form elements. I inherited a fairly large struts application months ago with 30+ forms. However, I have recently realized that none of the forms use inheritance at all to share common attributes even though there are glaring examples of forms just waiting to be combined: ie: PrintDocumentForm PrintMultiPageDocumentForm PrintWorkflowDocumentForm The three forms share 90% of the same attributes, but no one took the time to create a superclass. In addition to the benefit of checking data typing, I like having superclasses for common forms because it ensures that I am going to call the same property the same name on multiple forms. One of the major headaches of this project is that there are many forms that refer to the same bean property but are named slightly differently (i.e., container_id, _container_id, containerId). While inheritance will take you most of the way in solving naming conflicts and type conflicts, I am trying to use interfaces to take me the rest of the way. In the form example above, I have created three interfaces: Document MultiPageDocument WorkflowDocument and four forms PrintForm PrintDocument extends PrintForm implements Document PrintMultiPageDocument extends PrintForm implements MultiPageDocument PrintWorkflowDocument extends PrintForm implements WorkflowDocument Every bean property on the three subclass forms are either inherited or implemented from an interface. This way I can avoid naming conflicts by only naming a property that is used across multiple forms only once. Has anyone else done something similar? Or is there a better solution to this problem that would use less code? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tiles Question
I think I am misunderstanding something. I have two layout JSPs in my application doc.mainLayout doc.admin ... Basically mainLayout.jsp does 99% of the layout work. adminLayout.jsp just looks like this: --adminLayout.jsp--- <%@ page language="java" contentType="text/html; charset=iso-8859-1" %> <%@ taglib prefix="tiles" uri="struts-tiles" %> Extra text - When I try to have a JSP use doc.admin as a layout, it blows up. What is happening? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Strategies for Large Struts Application (LONG)
I inherited a rather large Struts application a couple of months ago. It was rather badly organized and almost no test code exists for either the business code or Actions. One of the many problems I have working with this code is that all the Action classes (200+) exist in one flat package with no consistent naming structure. The JSPs (200+) also all sat in one flat folder with no consistent naming structure either. Recently, I have begun the frustrating (but worth-it-in-the-long-run-...I hope) process of splitting the application into more manageable parts. I created an extensive use-case list and seperated them into about eight clusters. I created a folder for each cluster and put the JSPs into their respective folder. It took a lot of work to get that together and fix the struts-config. All the links from one JSP to another work if you go through an Action first, but if you go directly to the JSP, a lot of links fail. My structure is sort of like this: webapp\jsps\similarActions1 webapp\jsps\similarActions2 webapp\jsps\similarActions3 webapp\images webapp\css webapp\js What is the best solution? Put a tag on every page, or insert the context path before every link, image source, frame source. OR I have an idea of using JavaScript to just parse through all the links, image sources, and prepend the context path. Anyone who has had trouble with relative links and links breaking when you move stuff around, I'd be happy to heard your thoughts on this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
