-
1. Re: Seam Best Practises - Designing, architecting, and Client side validation
jamesjmp Aug 12, 2009 3:44 PM (in response to bharathiya)Hi!
In the seam distribution go to the path //doc/reference/en-US/
There you´ll find in three ways the reference documentation. If you´ve never used seam before I advise you to read at least chapters from 1 to 10 and 13 and 14 as well. According to your needs, you´ll find really useful chapter 10, which covers JSF validation, and chapter 13, which focuses on the framework.
You have an examples directory in the distribution as well, that could be very helpful for you to understand it all.
As for books, if you have the chance try Seam in Action, and last but not least the following link is where seam dev team have their blog
http://relation.to/ (or http://blog.hibernate.org/)
Enjoy seam tech! -
2. Re: Seam Best Practises - Designing, architecting, and Client side validation
asookazian Aug 12, 2009 5:34 PM (in response to bharathiya)From an architecture perspective, Seam does not require nearly as many layers as Spring, for example, and also typically much less XML
code
. JSF does not have a front controller that Spring MVC has (DispatcherServlet).However, you should consider adding layers as necessary. A popular design pattern which should be considered is DAO which is discussed in detail in JPA/Hibernate book. DTO is now an anti-pattern because JPA entity classes implement Serializable interface and can be accessed directly as a backing bean in a JSF page. For example, I use a DAO class to access stored procs.
The Seam framework is a stateful framework so typically we use SFSB as backing beans and have JSF action EL expressions bound directly to methods in the local interface of the SFSB. You can do business and CRUD operations directly in this component or abstract additional layers like DAO. You can also delegate any business logic to a helper component so that separation of concerns is maintained in the presentation tier and business tier.
In Seam, we use RichFaces or ICEFaces AJAX frameworks and thus there is very little need for custom Javascript coding like in J2EE 1.4 apps. For validation, there is Hibernate Validator annotations on the entities, custom Seam validators and live validation using <a4j:support> and <s:validate>.
You should also read about the factory component pattern (@Factory) and the manager component pattern (@Unwrap) which are used extensively.
Seam in Action and the Yuan book are good starts as well as the ref doc but there is no Seam best practices book (yet).
-
3. Re: Seam Best Practises - Designing, architecting, and Client side validation
bharathiya Aug 12, 2009 7:32 PM (in response to bharathiya)Thanks Arbi for the suggestions.
I am new to Seam but have worked on few examples and have gone through booking examples, so I have a over all understanding of it.
I went through these topics again to see if I can get a clear answers for 'best design practices for Seam' but these topics are more syntax references.
You have an examples directory in the distribution as well, that could be very helpful for you to understand it all.
The validation part does not explain how to perform client side (javascript) validations on submit of the form and how to display localised error messages as pop-ups. I have read that MyFaces has Trinidad which can be used for this purpose, but not sure if we can use it with RI.
So, I am still trying to find more specific answers. -
4. Re: Seam Best Practises - Designing, architecting, and Client side validation
asookazian Aug 12, 2009 10:03 PM (in response to bharathiya)
Devil Developer wrote on Aug 12, 2009 19:32:
The validation part does not explain how to perform client side (javascript) validations on submit of the form and how to display localised error messages as pop-ups. I have read that MyFaces has Trinidad which can be used for this purpose, but not sure if we can use it with RI.
So, I am still trying to find more specific answers.JSF validates server-side. There is no need for client side validation in JSF/Seam apps. So you can validate twice. One via live validation (say event="onblur") per input field, one at a time with a4j:support and s:validate. And the 2nd is before the tx is commited to db on the server-side again via Hibernate (Hibernate validators).
Read more about this in SiA book.
-
5. Re: Seam Best Practises - Designing, architecting, and Client side validation
yilmaz_ Aug 12, 2009 10:12 PM (in response to bharathiya)I agree with Arbi. Most tutorials are about EntityHome approach which is fine. But i recommend using DAO pattern to build your software. You can build dao's and inject them in to your application. I recommend you Seam in Action and Seam Framework 2nd edition. Those are great books.
-
6. Re: Seam Best Practises - Designing, architecting, and Client side validation
bharathiya Aug 17, 2009 11:57 AM (in response to bharathiya)
JSF validates server-side. There is no need for client side validation in JSF/Seam appsSince JSF validates at the server side, the performance mght be an issue due to the round trips. Its faster to validate at the client side and we prefer to have client side javascript validation apart from the server side validation through hibernate validator.
.. live validation (say event="onblur") per input field, one at a time with a4j:support and s:validate.Though we can do the validation on onchange/onblur, there are some browser inconsistencies (IE triggers onchange only on onblur unlike mozilla etc.), so we want to do perform client side validation something like this:
Option 1: Have client side validation triggred ONLY on onsubmit of the form and utilise the hibernate validation annotations (so that we dont have to duplicate the validation reqirements).
Option 2: Same as 1 except the validation requirements are declared separately (without using the Hibernate Validation)
Option 3: Can we use the MyFaces Trinidad validation with Seam in RI ? How do we do it?
Option 4: Can we use Commons-validator framework with Seam ? How do we do it?
Many thanks,
Devil