Bug Patterns:

While developing web applications there are few common errors that get reported again & again.We don't usually document these.I thought it will be very useful if we can document these after consolidating from the existing bug reports. So here I am trying capture few.

I am sure it will be helpful for new developers to reduce the bug count in their web related projects. I will be updating this list whenever I come across new common mistakes. So keep checking this blog for latest updates :-)

UI Bug Patterns:

1. Handle the date display format @ common place, there is great possibilityto change here.
2. Screen resolution/Browser Compatibility issues (Make sure these are part of NFR) should be tracked well.
   
3. Make sure about UI issues while taking off the shelf tag libraries (For example tag libraries dsiplay tag, struts-menu comes with good CSS support)
4. "Enter" key should work for search screens (Use java script), Struts submit won't work most of the times
5. Session clearing issues- (Use case dependency, back button), Test all the scenarios by pressing the back button & clicking on the links/buttons.
   
6. Horizontal scroll bar appearence (Look for fields that accepts more than 80 chanracters) Look into IFrame, Frame and <div> tags.
7. Wrapping of characters in the table (header & other cells) will certainly help to avoid the horizontal scrool bar but for a continous String (without any space) wrapping will no effect
   
8. Placement Calender window(Any pop-up for that matter) all platforms (Mac Safari, IE behaviour), Don't include calender option below the screens with vertical scrollbar.
9. Don't use high resolution images(for thumbnails etc...),it takes more time to load the screens
10. Don't add all the import statements as part of the common init.jsp.
11. Before using any variable from session check for null if you are taking care of clearing of that session variable (Ideally you should not keep variables in the session,avoid if possible)
12. Instead of hardcoding, use context Root path in JS or JSP files, make sure to use the relative paths. Use http server to load all the static data (if possible). It will reduce the sover-all ize of EAR file to be deployed.
13. If user provides some junk values as HTML parameters (by directly editing url in the browser, just forward to same page by validating the same.For Example: He may enter the some String for Integer ID, then expect NumberFormatException & forward it to the same page.
14. Cache all the Combo-box related data & make sure to update cache data as well if there is seperate edit(add/update/delete) for these data.
15. Make sure to trim the input data while reading from text area/text feild
16. Use "value".equals(value) rather than value.equals("value") to avoid NullpointerException - This is not general rule but failrly applicable in web applications
17. Externalize all the user visbile data into properties file even if internationalization is not required. Eclipse(or any IDE) provides easy way to refarctor for externalizing
18. Handle duplicate submission
    

I am also planning to come similar kind of list for Java track as well. I am sure this would be helpful for developers/managers as checklist which can be part of defect prevention activity.

Choosing Java Web Framework - Evaluation Parameters

Selecting a web framework is one of the difficult decision that Java architect has to make upfront while architecting enterprise web application
First, we need to select between MVC frameworks(strut, struts-2, Spring MVC) and Component oriented frameworks (JSF,Tapestry... they are also MVC based although!). Hybrid solutions also can be better solution for certain areas.General thumb rule should be, if the application is more stateful with less read only pages we should go for JSF (Possibly the best bet is using frameworks like Seam & ICEFaces).We can also look into Spring webflow(I have not tried) if the application is tightly coupled with Spring back end & has to work with pre-Java EE envioronment. These frameworks offers much mature in handling statefulness of application (we don't have mess around HttpSession) and inbuilt future to handle workflows & continuations.Struts(Classic one) should be fine for small CRUD app with read only pages.

It is very difficult to layout the evaluation parameters for selection. I tried to come up following parameters (which I think are going to be more important in the year 2007) after spending some time in going through these frameworks. Depending on weightage (which is project dependent) we can take decision. I also give set of links that should help the evaluator for zeroing on some framework (or frameworks :-))

1. RIA Factor
I guess giving rich experience to web users is not going to fancy feature but a mandatory one in coming days.If this feature becomes #1 driving factor while building the application (Ex:entertainment & media industry) traditional MVC frameworks cannot be even part of such evaluations.
JSF - Because of better ecosystem provided by the IDEs and off the shelf component libraries that easily blend with AJAX.
Adobe Flex - For all Flash lovers. I am yet to see a practical full fledeged scalable big enterprise application although samples & SDK look impressive
Web start SWING - The most undervalued/under utlized option according to me while developing intranet applications
targetting finite #(with known pattern) of users.
Winner : JSF

2. Data Validation and Binding framework
Struts 2 (Webwork) is the best choice here. Although Tapestry (Good but has steep learning curve),JSF and Spring MVC provides fairly good data binding/validation support, but are not as attractive as Struts 2 (with OGNL)
Classical Struts is very poor (because of fundamental design flaw in dealing with web forms & stateless Action classes) while handling this.
Winner : Struts 2

3. Presentaion layer options
Some times it becomes importnat political decision to go with trditional templating engine option (like Velocity & Free marker) when we need to build a very big site with seperate UI and back end team. But I personally don't value this point much, all the frameworks should be able to use all the best of off the shelf custom tags (Like popular Display tag & Struts menu & site mesh ) & template options.
In these situations Struts 2 and Spring MVC shines well. Although HTML native support by Tapestry is the most likable option if need to provide HTML prototype for each & every screen before implementation & we can directly roll-out the screens to production by making the changes to HTML itself.Spring MVC comes with inbuilt design for handling the various presentation layer option from it's inception.
Winner : Spring MVC

4. Navigation mechanisms and Controller infrastructure
Component Frameworks provide event driven approach (JSF & Tapestry) like our regular SWING listener classes that we can attach to UI components. we can even attach sophistgated renderers. But I personlly not very receptive this idea of taking away request/response paradigm and low level APIs (HttpRequest, URLs, etc...) from the developer.
Struts 2 comes with most sophistigated support for the interception infrastructure and works well with our thinking.
Winner : Struts 2

5. People & deadline Issues/Learning curve
Usagewise Struts 2 doesn't seem to have won many supporters (Unfortunately :)).There is pretty steep leanrning curve involved with all non classic -struts option as 90% developers are familiar with struts & continue to use it. (Why to waste time 1 month time in learning for 3-4 months simple CRUD project even if it takes is a valid argument). I think some time down the line we need to work with better tools and techniques that can simplify the programmer's job.In longer run it is better to scale up programmer's ability to learn new things & adopt in a faster time. Hence it is better to use latest tools rather than relying on classical struts. After all we are not going to work with single project throughout our life. We have to consider market behaviour, effort investment & future project oppportunities.
Winner: JSF

In Summary,
Unless the site to be built is not stateful, small & includes mainly read only pages with less complex navigation requirement compoenent framework is over-kill & traditional MVC framework (Struts -2 my favorite) is a better option.
Most of time we end up evaluating frameowork based on their technical capability rather our business applicability. I felt it is important to focus on business applicabilty rather than techincal capability.

1. Total # of lines of code for accomplishing particular activity(use cases)
2. Non functional requirements. (People,longevity,envioronment,existing investments etc...)
should also guide the decision

I came across these links & found useful.
SWING is not better option compared to JSF as per Oracle
Java Web Framework Sweet Spots - By Matt Raible