Can I use bound values to populate an edit FormController?

[pgpx]

Hi,

I'm just starting to use Spring's MVC framework, and am attempting to create a SimpleFormController to edit an object stored in Hibernate.

All of the examples that I've managed to find (step-by-step, Petclinic, Petstore, Spring Live) retrieve the object in formBackingObject, using the id retrieved from the request object.

However, I can't find a way of using the id in the command object instead. I think that this oould be nicer, since then I don't have to worry about parsing the id (since binding will take care of that), and my request could also be validated (though this would require another validator). Since the id is passed into the command, I could re-load the command object using that id (and maybe also use other command parameters). Unfortunately, the only place that I think that I could do this is in showForm, and that's really a bit late (and probably doesn't work).

Or does nobody really do this? Are bound objects really only used for form submission (and not other actions)? Most of the examples of other actions all seem to use request parameters (e.g. RemoveItemFromCartController in JPetstore).

Thanks!

[kantorn]

I think it's wise to implement your own apps like the samples are implemented. After all, it's the Spring team that publish them, and they ought to know "best practice"

I don't fully understand your question. The command object is the model-part of "Spring MVC web layer" way of doing it. Why would you store an id or request parameter in the command object??? Seems like an oxymoron. Isn't it better to populate the comkmand object in formBackingObject()-method using the requestparamethers at hand?

So... do it the way the sample apps indicate.

[egervari]

I think he's talking about object references, like a User object containing a UserRole or a collection of UserGroups. With the spring approach, there isn't a great way to edit these kind of mappings, so you have store ids and do the individual mapping yourself. I wrote a little framework called aurora that solves these problems, however it's really just getting started and there is still a lot of stuff that I want to add. In some ways, it's a lot better than Spring MVC (more productive, less plumbing required) and in others, it still has some more work to do. kantorn, you can check it out at auroramvc.org if you want. Let me know if it solves your problem.

[kantorn]

OK, that might be it.

No, that kind of task isn't easily implemented, I've had to tweak things a bit myself in apps to solve it. But it still is manageable in the formBackibgObject(), tricky part is to find a suitable representation object and transform say your relational database model to this representation. But of course it tends to produce a bit "hairy" and somewhat incomrehensible code.

BTW, looking forward to hear more about your effort in Aurora.

[rharing]

Also, that technique is more confenient (sp?) if you use Hibernate. If on page x you get an object from the database using hibernate, and you store this object in the httpsession, then update it after page x has been submitted, you will get an hibernate exception, because you are then trying to bind an object with a certain id to the database, while it has not yet been retrieved from the database in this hibernate session.

Therefor, store the id, get the object from the database again and then update the object.

However this is how I understand it

Cheers
Ronald

[egervari]

Actually, Aurora solves this problem by taking that id and uses it to fetch the real object on your behalf, thus never just modifying the id value on the wrong object reference. It does this through the form's reference data. That was one of the problems that Aurora set out to fix because while Spring MVC handles single objects just fine, it does not handle graphs of objects very well. Aurora does this for collections of objects as well, so you no longer need to deal in arrays or comma-seperated values. The ids can be of any time as well. Lastly, Aurora does proper intersections and unions when mapping collections, so Hibernate won't complain about object references since the collection reference and the object references stay exactly the same. This makes the performance much better with Hibernate since it won't delete all the references and re-add them.

Part of me wishes I never made Aurora. I think Spring MVC is amazing compared to the other MVC frameworks, but it only needed few other things to make it unbeatable. Instead of contributing to Spring right away, I just built my own code as I worked on projects and it just grew, eventually to the point where it was bigger than Spring's MVC module itself. I think I lost sight of what Spring MVC really does now since I haven't followed it for some time. Anyway, if I knew all the things I know now, I'd be lobbying to add features into the current Spring using it's own approach rather than building my own framework. It's just so much work to build the framework for public use, make the website and documentation :/ I just didn't want all of this code to go to waste. Anyway, try out Aurora if that really is your problem, because this is a feature that has been working since 0.1. It was redesigned to be more generic in .2 and has been very stable for a long time. Hope it helps.

[pgpx]

Hi! Thanks for your replies. My question was really motivated by trying to (re)use a single controller for Create / Edit / Delete commands (where create and edit would need at least an id parameter). For now I'll go with the standard way and/or also take a look at Aurora.

[brianstclair]

I realize that I'm jumping in late on this one...

Are you asking, more or less, if it's possible to use/reuse a "normal" domain object to bind to the form instead of creating what is basically just a form data object, specific to each form?

This is my question, and I'm not sure if it's the one being asked in this thread. So, for example, I've got a Customer domain object written already, including business logic and possibly some association to a persistence layer. This is part of my "application" logic, and is independent of my view. Is there a reason not to use this same domain object to back my form, rather than creating a redundant class to deal solely with databinding in my view?

Thanks in advance, and sorry if this is off-topic.

Brian

[davison]

Is there a reason not to use this same domain object to back my form, rather than creating a redundant class to deal solely with databinding in my view?

There seems to be a lot of community support at present to get rid of dumb DTO's when moving between the business and persistence layers, recommending persisting your domain objects directly. With the presentation layer I'm not sure - views such as JSP, Velocity and FreeMarker would be able to call business methods on your command object directly within the template. There may not be issues if you control the templates, but it's a less than clean separation of concerns that I'm not convinced should be encouraged - particularly if some of those methods deal with persistence themselves.

[deepakjacob]

Hi! Thanks for your replies. My question was really motivated by trying to (re)use a single controller for Create / Edit / Delete commands (where create and edit would need at least an id parameter). For now I'll go with the standard way and/or also take a look at Aurora.

Hi, I would i like to know how you were able to (re)use a single controller for Create / Edit / Delete commands


deepakjacobATrediffmail.com

NTE : Please replace '@' for 'AT'.