Announcement Announcement Module
Collapse
No announcement yet.
Why does the the formBackingObject get called on a submit ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why does the the formBackingObject get called on a submit ?

    seems like the expected action is for the formBackingObject to be called on both the initial form display and submit, although in all the examples, the returned object is always retrieved from the database ?

    ..... seems a bit pointless unless the form is a subset of the business object ? ...... what is the thinking behind this ?

  • #2
    From the AbstractFormController JavaDocs (but slightly modified due to lack of a table tag :wink: )...
    Exposed configuration properties (and those defined by superclass):
    bindOnNewForm (Default: True) - Indicates whether to bind servlet request parameters when creating a new form. Otherwise, the parameters will only be bound on form submission attempts.
    sessionForm (Default: False) - Indicates whether the form object should be kept in the session when a user asks for a new form. This allows you e.g. to retrieve an object from the database, let the user edit it, and then persist it again. Otherwise, a new command object will be created for each request (even when showing the form again after validation errors).
    Therefore if you are doing a CreateMyEntityController you can set bindOnNewForm to false as there is no command to retrieve, or if you are writing an EditMyEntityController you can set sessionForm to true which should cause the Command to be retrieved from the session on form submit instead of calling formBackingObject.

    Hope this clarifies it for you.

    Jon

    Comment


    • #3
      Still

      Even so :

      - if you've got a number of servers in your env and don't want sticky sessions across your app servers.... therefore set sessionForm to false.
      - and leave it to default bindOnNewForm to true .. which is fine (although it should populate a blank object)

      it still calls formBackingObject which provides a new object and makes a call to the database.....

      I'd expect a method that provides an empty object on submission which get's populated from the form

      .... you could obviously do this by testing for submission, but it seems to be common practice to make the extra call to the database....

      Comment


      • #4
        Your approach works fine if you are using a DTO as your command object but what about the scenario where you are using an ORM tool (such as hibernate) for the data access, and pass a domain object in as the command. If you were to create a new object insead of editing an existing one, this would be seen by the ORM tool as a new entity to persist into the store rather than modifying an existing one.

        Therefore to me the existing solution seems to be the most suited to every scenario as for your requirement there is an easy method of testing for submission. To invert the implementation to create a new command for every submission would be difficult/inefficient to work around for the ORM guys.

        Disclaimer: This is just one persons opinion, and I'm still on the ORM learning curve.

        Jon

        Comment


        • #5
          mmmmm ... Hibernate ...

          Hibernate should only create a new record in the database if the primary field (e.g. id) is empty...... which is the way my/spring's JDBC implementation works too.

          The id would just be stored in the form as a hidden field and would be pushed back into the empty object when it is repopulated from the form.... it should work correctly under hibernate too.....

          Comment


          • #6
            Hibernate should only create a new record in the database if the primary field (e.g. id) is empty
            Sorry, I wasn't 100% sure on that point, that's why I put the disclaimer into my post
            The id would just be stored in the form as a hidden field
            Is this not making an assumption regarding the view technology used? Ok I can't think of an example where this would not be possible but the point still stands, well designed code should not be making this assumption.

            Also this means that this is an extra thing for the developer to remember to place in the template for things to work, therefore adding complexity where it is not needed. At the end of the day it's one less tag for the look & feel guys, or a following developer to mess up accidentally.

            Finally think of the situation where your domain/command object has properties that should not be exposed to the user (e.g. version property for optomistic locking) to have this present in your instance being persisted would require yet another hidden field, therefore more needless complexity in your view layer.

            It would be nice to hear the opinion of other forum members on this issue, although I feel I hit the core of the issue with that last point.

            Jon

            Comment


            • #7
              mmmmm

              As far as making asumptions, I think it's a far greater suusmption to presume that we could store the object in the session more often than not.... on any reasonable system, you're going to have a number of web servers..... and to reload the object from the DB is a killer on performance.......

              but I hear your second point...... data privacy could be the only reason I could see for doing this......


              N.B. .... other opinions from the world would be welcome...... not the most helpfull forum....

              Comment


              • #8
                I think it's a far greater suusmption to presume that we could store the object in the session more often than not.... on any reasonable system, you're going to have a number of web servers
                Valid point, I have no real experience on this scale. Then again, if you are working on this kind of scale, I would assume you have the budget to afford a few consulting hours with Interface 21 to discuss how they have approached these issues before.

                and to reload the object from the DB is a killer on performance
                Fair enough, in that case you have already mentioned your solution to the problem, something similar to the following I would expect....
                Code:
                public abstract class MySimpleFormController extends SimpleFormController {
                	@Override
                	protected Object formBackingObject(HttpServletRequest request) throws Exception {
                		Object myCommand;
                		if( isFormSubmission( request ) ) {
                			myCommand = getCommandClass().newInstance();
                		} else {
                			myCommand = getFormBackingObject( request );
                		}
                		return myCommand;
                	}
                	
                	// Template method to be implemented by subclasses.
                   protected abstract Object getFormBackingObject(HttpServletRequest request);
                }
                And then modify your existing form controllers to extend MySimpleFormController(Sorry couldn't think of a meaningful name).
                not the most helpfull forum
                I joined at the weekend for some help and have come to realise it is a fairly quiet forum, although I have tried to help others where I can (with a fair amount of positive response too )

                Jon

                Comment


                • #9
                  agreed

                  agreed .... cheers for the response....

                  Comment

                  Working...
                  X