Sorry if I've been unclear. Yes, I'm suggesting a modification to link_to that would check for :lock_with options and translate that into `data-params` with locking_column=lock_column_value. I don't think any change would actually be needed to jquery-ujs to support this.
To be clear, here is a gist of what I've monkey patched in my current application: https://gist.github.com/bdmac/5032984 On Monday, February 25, 2013 12:21:24 PM UTC-8, JangoSteve wrote: > > I thought you were talking about remote forms. Correct, UJS only creates a > form for links that have data-method but are not data-remote. For remote > links, it just creates an ajax request with the proper method. > > So, e.g. `link_to(@model, method: :delete)` would turn into a form, but > `link_to(@model, remote: true, method: :delete)` would not. > > To clarify though, you're suggesting that rails would have a `:lock_with` > option that would translate to `data-lock-with` on the link and fill it > with the value of @instance.lock_version, and that UJS would just need to > be aware of `data-lock-with` and append it to the parameters? > > If that's the case, it'd be fairly easy to handle on the UJS side, so this > would be more of a discussion on the side of the implementation in > ActionView::Helpers::UrlHelper#link_to. > > -- Steve Schwartz > > On Monday, February 25, 2013 at 2:24 PM, Brian McManus wrote: > > That's right, that would not be necessary for remote: true forms. Correct > me if I'm wrong but I don't think UJS generates a form for link_to(remote: > true, method: :put). It just generates an AJAX request to the server with > appropriate options. > > There are two ways to get this working that I know of currently: > > 1. Use link_to with a url instead of a model object and stick the > lock_version in as a param. > link_to(@model, remote: true, method: :delete) becomes... > link_to(model_path(@model, lock_version: @model.lock_version), remote: > true, method: :delete) > In this case the ajax request has the lock_version supplied as a query > string parameter. In the case of a :post or :put it would be more > appropriate to be part of the post/put data. > 2. Use link_to with data-params specified: > link_to(@model, remote: true, method: :delete) becomes... > link_to(@model, remote: true, method: :delete, 'data-params': > @model.lock_version) > > My idea would add a simple helper option to link_to along the lines of > :remote, :method, :confirm that would add the appropriate data-params for > you. > > link_to(@model, remote: true, method: :delete, lock_with: @model) > > if link_to(:remote/:method) DID generate a form using the standard > form_for under the covers then you're right, this would be unnecessary and > we could simply patch form_for/fields_for but I don't think that's the case > with UJS as mentioned. > > On Monday, February 25, 2013 11:07:39 AM UTC-8, JangoSteve wrote: > > I'm not sure I understand what would be needed from the UJS side. If it's > in the form, UJS will simply pick it up and send it as a parameter. Are you > saying it should be sent as a request header instead of a form parameter? > > -- Steve Schwartz > > On Monday, February 25, 2013 at 12:28 PM, Brian McManus wrote: > > I'm working on an app that makes use of rails' optimistic locking > feature and seeing some possibilities for improvements. It seems a bit > tedious to have to add :lock_version to forms wherever the model is used. > You also have to "hack" around rails' UJS feature to add it as a URL > parameter when using remote: true, method: [:put, :patch, :post, :delete]. > On the controller side in rails 4 (or if you're just using the > strong_parameters gem in 3.x) you have to remember to permit the > :lock_version parameter wherever you're using that model or it will just be > silently ignored rendering the protection useless. > > It seems like this could all be handled in rails core by introspecting the > form object and injecting the lock_version as we do with the id and :method > currently. I'm having problems figuring out how to address it on the UJS > side. My current idea is to add a lock_with: option to link_to that works > similarly to :remote, :method, :confirm, etc. Also, I can't see any > obviously clean way to handle this magically wrt strong_parameters since > there is nothing inherent in strong_parameters that provides knowledge > about the model that may eventually be created/updated from said > parameters. Current plan there would be to create a module you can include > in ActionController::StrongParameters that would automatically append > :lock_version whenever permit is called. Not sure how to handle if you > change the lock column name in your model though... > > Is this a viable approach for core or would this be better served as a gem > that just monkey patches everything it needs to if they are present in the > user's app? > > Thanks in advance! > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
