Mapping UI Fields directly to Beans, Entity Home

[zahidmaqbool]

Hello Everyone,

I just had a question related to design of an application. What I see from the seam documentation is that there are EntityHomes which provide persist(), update() etc methods and the instance is also available.

In all the examples, I have seen that the fields in the UI is directly mapped to the instance in the Entityhome

for example in UI the mappings are {personHome.instance.firstname}

What I wanted to know is that is this the correct way of doing things when we do actual projects, and what are its benefits.

Correct me If I am wrong, what I understand is that it is ok to map your User Interface fields directly to the instance and take care of all the validations in the Validation phase of JSF or do Hibernate Validations.

Please comment on your thoughts on this, because I have been working on some applications where users interface fields where mapped to a form bean and then the form bean was mapped to another Database Bean.

Thanks in Advance.

[luke.poldo.mailinator.com]

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.

[mwohlf]

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?

[norman]

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.

[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?

[norman]

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(). 

[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.

[andygibson.contact.andygibson.net]

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.

[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.