• Post Reply Bookmark Topic Watch Topic
  • New Topic

JSF Best Practices  RSS feed

 
Nick Nickolov
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been using JSF for quite some time and I have adopted some tricks for my app. I'd like to see your opinions for each of them - is it good or bad? Assume it's not a trivial project (5+ people, more than several months).


- Wrap&trap: I went for creating my own wrapper components, as extensions of MyFaces' ones. The benefits are:
= I can enable only a subset of their attributes and thus create some discipline among page developers (e.g. the HTML 'pass-thru' attrs do not seem to fit into JSF's paradigm, so we do not use them, and they only crowd up autocomplete)
= I can add missing functionality - e.g. MyFaces' table component with sorting.

- Naming conventions: JSP names are like 'ItemView.jsp' - camelhumped with an initial capital letter. Suffix is normally '...View'; Bean names are like 'itemView' - initial letter is small. Most beans are in the session scope.

- Jsp-to-bean: I adopted the principle that JSP pages and backing beans should be in one-to-one correspondence.

- 'This': In order to encourage one-to-one jsp-to-bean, I implemented a VariableResolver which resolves the variable 'this' to the backing bean with the same name as the JSP. E.g. '#{this.itemFilter.price}' in ItemView.jsp is equivalent to '#{itemView.itemFilter.price}'

- Computed properties: I implemented a PropertyResolver for (rare) cases like the following: Imagine a class Person with a field birthday. We want to show the age of each Person in a list, but we do not want to add a 'getAge()' method because we want to keep our entity classes clean of code related to visualization. So, if my PropertyResolver doesn't find 'Person.getAge()' (by invoking the default impl), it will look for 'BackingBean.getAge(Person p)'

- I18n: I didn't like the <f:messages> tag, so I ended up with a special bean registered under the name 'messages' in application scope, which is capable of producing the expected result from expressions like #{messages['KEY_IN_RESOURCE_BUNDLE'][p0][p1]}, where p0 and p1 are the actual {0}, {1} parameters of the localized message.

- <p:column> (p: is our prefix) contains two more attributes - headerText and cellText - just to avoid putting a subtag in the common case when the data is simply <f utputText>.

- <p:inputCalendar> is ugly. I re-implemented it.

- 'label': Some components have a 'label' attribute which renders a fixed-width label just before the component. The label attribute recognizes '_' as a marker for the accelerator key, e.g. label='Primary _name' - alt-n would move focus to the text field.
[ September 25, 2005: Message edited by: Nick Nickolov ]
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most beans are in the session scope.

I typically view this as bad. I deal with a lot of forms that must start fresh and keeping the backing beans in request allows me to not have to supply a lot of initialization code in my backing bean in the event the form needs to be fresh and new.

'This': In order to encourage one-to-one jsp-to-bean, I implemented a VariableResolver which resolves the variable 'this' to the backing bean with the same name as the JSP. E.g. '#{this.itemFilter.price}' in ItemView.jsp is equivalent to '#{itemView.itemFilter.price}'

Put aside your naming convention and I am not sure this is a good idea. If you handed someone your JSP then they will have no clue what backing bean 'this' refers to. However, if your naming scheme is consistant then I guess it is not a problem. Except that the page goes through an extra process for a not much benfit. Is it really easier to type 'this' than 'itemView'? Not to me.

I18n: I didn't like the <f:messages> tag, so I ended up with a special bean registered under the name 'messages' in application scope, which is capable of producing the expected result from expressions like #{messages['KEY_IN_RESOURCE_BUNDLE'][p0][p1]}, where p0 and p1 are the actual {0}, {1} parameters of the localized message.

I am not sure what you gain with this either. The f:messages works fine for me. Your expression looks overly complicated.

<p:inputCalendar> is ugly. I re-implemented it.

Maybe you should submit your changes to the MyFaces team (assuming that is the component you re-implented). Maybe the community could benefit. With that said, I am not sure how that fits in with this post of 'JSF Best Practices'.

Everything else looks pretty interesting. It would be easier to determine their benefits seeing them in use. As I said earlier, maybe these are some things you can contribute to the community via MyFaces or a library you release on your own. Good post.
 
Nick Nickolov
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

'This': ...

Put aside your naming convention and I am not sure this is a good idea. If you handed someone your JSP then they will have no clue what backing bean 'this' refers to. However, if your naming scheme is consistant then I guess it is not a problem. Except that the page goes through an extra process for a not much benfit. Is it really easier to type 'this' than 'itemView'? Not to me.


Extra processing is ignorable. And yes, 'this' is easier to type, otherwise you have to take care and always supply the proper name of the backing bean (which is the name of the JSP in our case). Copy-paste of JSP fragments, and renaming of JSPs are easier too.
You're right about readability - if I handle a JSP to someone external, they would have no idea what 'this' means. But I can live with that.


I18n: ... #{messages['KEY_IN_RESOURCE_BUNDLE'][p0][p1]}

I am not sure what you gain with this either. The f:messages works fine for me. Your expression looks overly complicated.


Any idea how to internationalize messages with parameters through an EL expression?


<p:inputCalendar>
I am not sure how that fits in with this post


Agreed, I shouldn't have made a point out of it.


you can contribute to the community via MyFaces or a library


I can invest a little time to share stuff which proves useful. But at this stage I just want to comment on how to put JSF to serious work, though it is not a mature enough framework yet.

Thanks for your comment
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!