-
1. Re: Mapping UI Fields directly to Beans, Entity Home
luke.poldo.mailinator.com Mar 30, 2009 2:46 PM (in response to zahidmaqbool)You could map the field to a @Transient method and then assign the real field, but I think that Seam is meant to be so like you said.
-
2. Re: Mapping UI Fields directly to Beans, Entity Home
mwohlf Mar 30, 2009 4:49 PM (in response to zahidmaqbool)That's how I write my seam stuff too, no need for tons of glue code and reusing the hibernate validators is great I think.
Problem is sometimes the database doesn't match the UI, for example an additional validation field for password changes in the UI, I tend to abuse the Home Object for this additional value, any better ideas for this usecase?
-
3. Re: Mapping UI Fields directly to Beans, Entity Home
norman Mar 30, 2009 5:07 PM (in response to zahidmaqbool)Using the home object is very good. Another option is for your home object to manage the extra form data in a separate object and merge that into the managed entity. It's pretty straight forward with Seam in either case.
-
4. Re: Mapping UI Fields directly to Beans, Entity Home
zahidmaqbool Mar 31, 2009 11:15 AM (in response to zahidmaqbool)Also one more thing from a design perspective, is it ok to override the persist method and do some pre-processing before persisting?
or is there any other recommended way?
-
5. Re: Mapping UI Fields directly to Beans, Entity Home
norman Mar 31, 2009 11:58 PM (in response to zahidmaqbool)Yes, though I think a slightly better approach in that case is probably to create a new myPersist() method that provides the enhanced behavior, calling the original plain persist().
-
6. Re: Mapping UI Fields directly to Beans, Entity Home
zahidmaqbool Apr 1, 2009 11:42 AM (in response to zahidmaqbool)Thanks everyone for your reply.
I had another question dont know if its ok to post here, or shall I start a new topic. The question is say I have a Master Table called Applicant, and this Applicant table has 2 child tables with one to one relationship called Individual and Developer.
Based on the user selection data will be stored in the respective table, i.e.
Some Common details will be stored in Applicant Table and then if the user selects applicant is of type Developer then the form will be customised and records will be stored in Developer table.
However what is happening when I persist this it stores everything properly, but then there will be an entire row in the Individual Table which will be blank, all records null, cause the user had selected the developer table. Is there a way to not store these records as null in Individual table.
I am using EntityHome for this, should I consider some other approach with this scenario.
-
7. Re: Mapping UI Fields directly to Beans, Entity Home
andygibson.contact.andygibson.net Apr 1, 2009 4:18 PM (in response to zahidmaqbool)Yes, we do this to handle validation. Since we have some forms that have validation and are part of flows, there is no way to save the form (with errors) go to another page, come back and finish the form since JSF validation won't let anything through even if you promise to come back and fill it in. So, we do validation before we persist the object in the persist and update methods.
-
8. Re: Mapping UI Fields directly to Beans, Entity Home
zahidmaqbool Apr 1, 2009 4:29 PM (in response to zahidmaqbool)Ok, but I have noticed that if you do normal validations in persist and update methods, then the values are saved no matter whether validation fails or succeed, this only happens when your trying to update a record in the database which already exists.
Howeever to overcome this we use JSF and Hibernate Validations.
Can you tell me how do you keep the validation part in the persist or update method without this update still happening.