Announcement Announcement Module
Collapse
No announcement yet.
Inform a user if another user is editing the same form Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Inform a user if another user is editing the same form

    Hi,

    I need to inform the users of my webapp if another user is editing the same form (the same command-object with a certain id). How could I achieve this?
    I do not want to lock the object, just warn the user, that another user is using the same form.

    Could someone provide me with a pointer where to look for or some ideas?

    Thank you all.

  • #2
    your difficulty will not be recording that someone started to edit a form, but knowing that they are no longer editing it.

    If the user submits the form back, you can hook into it and clear the 'edit' flag: but what if they request the form and then just walk away from their machine? Or click another link and keep interacting with your application but still not submitting the form back (i.e. their session stays alive).

    You'd have to specify an arbitrary time limit after which you assume the user is not going to submit the form back and clear the edit flag for that command id. That might mean a scheduled job around the helper class managing your edit flags.

    It's not ideal by any means and I'd seriously question the reasons for wanting something like that - particularly if you're not going to stop them editing it in the face of a warning anyway.

    Spring WebFlow may offer better options..

    Regards,

    Comment


    • #3
      Thank you for your input.

      your difficulty will not be recording that someone started to edit a form, but knowing that they are no longer editing it.
      I am aware of this problem. But this is a minor problem. I have no experience how to handle an application wide status without a database.

      I just thought about informing the user about a conflict when he submits the form. But mh, then I always have to check abotu differences... Oh my.

      It is a time critical project an I have no time to learn an look for SWF.

      Comment


      • #4
        I am not sure it is the best approach to it here are some ideas.
        when accessing the form/view, you could update the database or store the information in the application scope.

        Then if all your controllers make sure they reset any 'locks' before redirecting to any pages.

        You still need to deal with people hitting the back button, and one option might be to use AJAX (DWR is pretty easy to integrate). AJAX can make a request on the Unload event, with no callbacks needed to reset the 'lock' for current screen. If you do this then there should not need to have the controllers reset the locks but one can never be too careful.

        Other precautions could be to make sure they are reset when the session times out (so you will need a listener). You could also make sure the pages are not cached (with http header) so if they click back the page has expired and they will probably stop doing it.

        That being said I tend to agree that is probably the wrong medium for that type of functionality, but who can argue with requirements

        On a side note I was wondering whether it is the view that should be locked or the record/data being presented in the view.

        Comment


        • #5
          We do something like this for one part of an app I work on.

          We have a datetime field that records when a user 'locked' the record, and a foreign key to the user table to track who has locked it.

          If they press all the right buttons, it will be unlocked when they move off it.

          The record isn't really locked, it's just tagged so if someone else decides to open the record they can hopefully see someone else has it.

          We're using versioning with Hibernate so if someone does update a different version to what they loaded, they receive a message and have to do the edit again.

          If the user closes the browser, etc, then a Quartz job unlocks any record that has been locked for (i think?) 10 minutes.

          This doesn't handle the situation where the user might legitimately need to lock a record for >10 minutes, but this never practically happens.

          It's not perfect, but seems to be working ok.

          Comment


          • #6
            For me I just stored the Vector object as an Singelton in the application scope for this kind of issues. To capture the session event, I HttpSessionBindingListener, when the session invalidate remove a certain id from the vector.

            Comment

            Working...
            X