One of the areas of JSF that I think suffers compared to other models such as JSP, PHP, etc is that it requires two paths instead of one. In JSP, for example, code is compiled directly into Java bytecode. That code is then directly executed when the servlet is accessed. As a result, a single path is executed to render the content to the output stream. In JSF on the other hand, first a component tree is created and renderers associated with it. Once that tree is constructed and JSF enters the render phase, the tree is walked completely and content is written to the output stream. Thus, JSF requires two paths: one to create the tree and one to render it. As a result, JSF has overhead associated with it. On the plus side, that overhead buys the developer a much improved programming model and better MVC implementation. The component tree is a stateful tree that allows state to be associated to components (ie: a value for an input component). This allows JSF to have a very clean model for performing validation, actions, and rendering. However, I believe that the tree mechanism can be improved from a performance standpoint.
(more…)
Posts Tagged ‘components’
JSF: Suggestion for Performance Improvement
Friday, May 1st, 2009JSF Relative Client IDs
Monday, October 13th, 2008Currently in JSF, if you wish to have one component refer to another component, you have to use one of two types of client ids: absolute or relative. A relative id is resolved against its closest parent NamingContainer and searches for a suitable match. An absolute id starts with a separator character (typically a colon) and references the top most view root object of the tree. These solutions both work great and generally you rarely need to use absolute ids, which I always feel should be strayed away from as it adds to maintenance and bug leaks. For example, if you change a parent client id, you may forget to update absolute ids that had depended on that particular id. The result is a broken page that may slip through testing leading to bugs. Thus, I always prefer relative URIs when possible. However, in JSF there is no good way in 1.x to refer to parent element relatively. For example, if you have a component within an iterative component (data table, repeat, etc) and wish to refer to a component outside the iterative section, you must currently use an absolute id. Using a relative id would result in a failed lookup as the relative URI only resolves against the closest naming container, which would be the iterative section. However, using an absolute URI (which does work) results in harder to maintain code. A more ideal solution, IMO, is to use relative paths such as Linux (or most other operating system shells) to refer to the outer parents. For example, given the previous iterative example, you could use an expression such as for=”..:child:id” where “..” goes to the parent naming container of the closest naming container. Now, you have relative URIs and much easier to maintain code by not having to worry about potential id changes to the root element, for example.