Rails - Dec 2009 - RFC: conflict_warnings plugin

Greetings,

I was hoping to get some feedback on a plugin I wrote.

The plugin is called conflict_warnings and is currently available from
my github repository at http://github.com/EmFi/conflict_warnings

The purpose of the plugin is to provide a simple methods of preventing
data inconsistencies that could arise from multiple users interacting
with the same resource.

Under basic operation a before filter will be triggered if the
resource was modified between the time the referring page was loaded
and the request was received. The goal being to halt the request,
update the referring page and inform the user that the resource has
changed and their action may not have the desired effect.

Under more advanced use it can conceivable be used for so much more:
 - Only update portions of a record that have changed and highlight
them with Prototype or jQuery (requires some kind of model version
tracking, maybe acts_as_audited)
 - Simplify actions upon failing to acquire a lock.
 - Enabling/Disabling some actions by when they occur.


Usage/Examples.

class ExamplesController < ApplicationController
   filter_conflicts :only => :confirm do
     respond_to do |format|
        format.html {render :action => "show"}
        format.js {
          render :update do |page|
            page.replace_html :notificaiton_area, :text => "Your
request could not be processed because the example has been modified
recently. Please try again"
            page.replace_html :status, :text => @example.status
            page.visual_effect :highlight, :status
            flash.discard
          end
        }
     end
   end
end

If the a user loads the the show page for an example, and that same
example is modified by another user before that first user confirms,
that first users'' attempt to confirm is blocked.

LockingResource example:

  class LockingResourcesController < ApplicationController
      before_filter :login_required, :acquire_lock

      protected
      def acquire_lock
          catch_resources_unavailable current_user, :accessor
=> :acquire_lock_for_user,
             :message => "Could not acquire lock"
      end
    end

If  user cannot acquire a lock they are redirected back to the
referring page with the message
"Could not acquire lock" contained in flash[:warnings]

The documentation describes the plugins'' usage and options in much
more detail.

I know there are other ways of solving this problem, validations take
care of many cases covered by this plugin, and periodic remote
requests could be used to keep the pages updated. But, the
asynchronous nature of periodic requests were not good enough for my
needs.

As I said, I''m looking for any kind of feedback, let me know if any of
the documentation or examples are unclear. Feature requests and of
course criticism is also welcome.

Thanks in advance for any time you may spend checking it out.

--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

The underlying model mechanism appears to have re-invented optimistic
locking (by checking updated_at rather than lock_version), but the
view code stuff looks like it might be useful...

--Matt Jones

On Dec 17, 8:21 am, Emery Finkelstein
<emery.finkelst...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Greetings,
>
> I was hoping to get some feedback on a plugin I wrote.
>
> The plugin is called conflict_warnings and is currently available from
> my github repository athttp://github.com/EmFi/conflict_warnings
>
--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

I remember looking at optimistic locking before I started to write
this thing. I dismissed it because optimistic locking was used for two
requests that enter memory at about the same time. I had a need for
that same behaviour that persists across controller requests. Which
optimistic locking doesn''t do easily.

When I got around to extracting my application code into a plugin, I
had completely forgotten about optimistic locking. I am completely
amenable to either reworking things so hooking into optimistic locking
instead of attempting to replacing it.

Thanks for pointing that out. Referencing Optimistic Locking
definitely makes the documentation cleaner. It almost makes me want to
change the name of the plugin, to reference Optimistic Locking,
something like optimistic locking extension. But I''m hesitant to do
so, because it deals with so much more than that.

Emery




On Dec 18, 12:29 pm, Matt Jones
<al2o...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> The underlying model mechanism appears to have re-invented optimistic
> locking (by checking updated_at rather than lock_version), but the
> view code stuff looks like it might be useful...
>
> --Matt Jones
>
> On Dec 17, 8:21 am, Emery Finkelstein
<emery.finkelst...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
>
> > Greetings,
>
> > I was hoping to get some feedback on a plugin I wrote.
>
> > The plugin is called conflict_warnings and is currently available from
> > my github repository athttp://github.com/EmFi/conflict_warnings
>
>
--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.