Thursday, June 7, 2012

JSF Best Practices


Open Source Components
  1. Use myfaces or Sun RI. It doesn’t matter which one you use because both comes from Sun. Sun offers myfaces through open-source community.
  2. Use richfaces to get rich look quicker. Click here to go to demo site.
  3. Use facelets to avoid compilation time and better code readability.

IDE

  1. Use eclipse latest version
  2. Use richfaces eclipse plugin. It offers Visual Page Editor for Richfaces, JSF, and HTML / CSS.
  3. Use Tomcat instead of JBoss to avoid server restart for each changes.

Naming Convention

  1. Keep resource bundle name and xhtml name as same. Example SearchUsers.xhtml and SearchUsers.properties
  2. Suffix all the managed bean with “Bean” word, like SearchUsersBean.java
  3. Keep all the folder names in lower case.

Techniques

  1. For bigger project it is better to extend all the default components, that gives flexibility and extensibility to add new features in future.
  2. Use components effectively like oops concept to minimize the coding and maximize the usage.
  3. To keep your application scalable, minimize creating managed beans in session scope. Many of them recommending session scope for managed beans to solve the JSF component state problem but it is a serious issue if you want to host your application in clustered environment.
  4. Use Map object to capture values for components created inside <c:foreach> loop.
  5. Write a custom datetime converter and register with java.util.Date type to keep control of TimeZone and default date format. See here for more information.
  6. Customize default JSF error messages. See here.
  7. Use facelets layout feature to simulate Struts Tiles kind of behavior.
  8. Always use Wrapper classes instead of primitive types. If you use primitive data type passing empty values from the field will through exception.
  9. Use <h:outputLink> for simple page navigation, use <h:commandLink> to submit form and does validation too.
  10. Don’t hesitate to use simple HTML input controls where JSF doesn’t provide good solution. For example displaying radio button in datatable has issues when you fetch data from database. For these scenarios I prefer to use simple HTML controls.
  11. Use <c:if> instead of rendered attribute for <h:commandLink> and <h:commandButton>. If you use rendered attribute sometime action may not be fired if the bean by default returns false.
  12. If you are using JSF1.2, use <f:view beforePhase=”#{method-binding}”> to execute all your page initialization stuffs like fetching data from database, creating error messages to be displayed.
  13. If you are using JSF1.2, use field specific custom error message wherever is required. Example:
    <h:inputText value=”#{bean.value}” requiredMessage=”#{bundle.requiredMessage}” converterMessage=”#{bundle.converterMessage}” validatorMessage=”#{bundle.requiredMessage}”>
    More information can be found here.
  14. Don’t use <c:if> inside iterative tags like <h:datatable> and <ui:repeat>. see here to know the reason.

Work around for some common issues

  1. Add immediate=”true” for Cancel and Reset types of buttons to bypass validations. See here.
  2. One of the major missing feature in JSF is calling an action before page invocation. Here is the workaround.
  3. Here an work around solution explained to invoke an action from url.
  4. This link explains the difference between <c:forEach> and <ui:repeat>
    http://www.ilikespam.com/blog/c:foreach-vs-ui:repeat-in-facelets
  5. If you need to redirect from navigation-case to URL with param which is a property of a managed bean. Here is the work around.
  6. EL expressions in JSF are executed multiple times for datatable and other iteration tags hence get method in managed bean might call multiple times. Either initialize your variables in action method or @PostConstruct method or follow lazy initialization. Read here for more explanation.
  7. With JSF implementation submitting form with enter key will not invoke action method. Here is a custom component which will solve this problem.

Wednesday, June 6, 2012

JSF Performance Tuning

Things to be taken care during design/coding:

1) Do not use datatables where it is truly not required. Even If it is search results table, you can manage with datalist. Go for datatable when you need to have links, buttons within the table
2) Do not use panelgrids, JSF components unnecessarily when you can do the same using regular HTML tags. For example: If you want a static table just enclose with f:verbatim tag and use regular HTML table tags. Reduce the burden of component tree creation.
3) Use facelets instead of tiles.
4) If you have an option to switch for JSF 1.2 or above, please do it.
5) Always enclose the JavaScript, stylesheets withing header tag. Write one filter such as cache control filter (I think such filter is used in icefaces) to cache these files. By doing so browser will not request for these files on every screen load. Trust me, this really helps screen response time.
6) Follow the link http://wiki.apache.org/myfaces/Performance and do all tips mentioned for server side state mechanism. You have to be careful when you set org.apache.myfaces.SERIALIZE_STATE_IN_SESSION as false. Especially in distributed/clustered applications, if the app server is supposed to replicate sessions in both the servers, this should rather be turned on. For our application, we set it to true. The number of views need not be 20!!!. For our application we set it to 5. This reduces the memory consumption in JVM.
7) Write your own state manager and override the method which stores objects in session. The myfaces 1.1.6 and below is having a logic wherein it stores the old views in weak hashmap. Modify your statemanger to remove this behavior.
8) Write your own navigation handler to remove unnecessary views from session. For eg: Once the user has logged in, it does not make sense to retain the login screen view in session. Remove them. For our application, we had our own state manager and navigation handler. We then load a static map which will give the list of view ids that need not be stored in session. When the user navigates from one screen to another, the navigation handler checks if the viewid exists in hashmap. If exists it requests the statemanger to remove the state from session. As far as our state manager is concerned, if a particular view id exists in hashmap, it does not spend time trying to serialize the state in session. This way some time is saved and the burden on the memory is reduced.
9) Use ajax as much as you can. 

Friday, November 12, 2010

Tips

Kill Port 



goto command prompt
netstat -aon
it will show you something like
 TCP    192.1.200.48:2053  24.43.246.60:443       ESTABLISHED   248
 TCP    192.1.200.48:2055  24.43.246.60:443       ESTABLISHED   248
 TCP    192.1.200.48:2126  213.146.189.201:12350  ESTABLISHED   1308
 TCP    192.1.200.48:3918  192.1.200.2:8073       ESTABLISHED   1504
 TCP    192.1.200.48:3975  192.1.200.11:49892     TIME_WAIT     0
 TCP    192.1.200.48:3976  192.1.200.11:49892     TIME_WAIT     0
 TCP    192.1.200.48:4039  209.85.153.100:80      ESTABLISHED   248
 TCP    192.1.200.48:8080  209.85.153.100:80      ESTABLISHED   248
check which process has binded your port. here in above example its 248 now if you are sure that you need to kill that process fire
Linux:
kill -9 248
Windows:
taskkill /f /pid 248
it will kill that process

Mysql

Grant Privilege

grant all privileges on *.* to root@localhost identified by root

View opened connection in MySql

show processlist