You can use the same code with a call like:
model.attributes = {}
where the example was update_attributes({}). That won't attempt to save the
model. And either of those calls will assign with any overridden accessors
too, so you won't be bypassing them.
James Coleman
On Sat, Apr 7, 2012 at 9:29 AM, Rodrigo Rosenfeld Rosas
<[email protected]>wrote:
> Em 07-04-2012 05:51, Robert Pankowecki escreveu:
>
> On Sat, Apr 7, 2012 at 4:09 AM, Rodrigo Rosenfeld Rosas<[email protected]>
> <[email protected]> wrote:
>
> Okay, I see that you don't share the same feelings I have about this. No
> problem. Usually I'd want my overridden method to notice any change to those
> values and I find annoying have to write code like this in my controller:
>
> [:deleted, :disabled].each{|p| model.send :"#{p}=", params[p] == 'true' }
>
> model.update_attributes(params.slice(:deleted, :disabled)).
>
> And let your model handle the conversion of attribute values.
>
>
> This is not equivalent.
>
> First, update_attributes will attempt to save the record, but it wasn't
> time to save it yet in my action.
>
> I can't let the model handle the conversion because I'm converting a
> Grails application to Rails in parts, so the views are actually implemented
> in Grails at this moment and the parameters are being set by JavaScript, so
> I can't be sure they'll fit the Rails default rules for casting to boolean.
> I need to be sure that only 'true' should be handled as a true value for
> this request.
>
> I'm using a proxy for redirecting the new implementation to the Rails
> application. I've been willing to convert this application to Rails for a
> long time, but I never had the chance. But last week I found a critical bug
> in Grails and I couldn't find any workaround to it:
>
> http://jira.grails.org/browse/GRAILS-8994
>
> So, I decided to take this path for fixing the application. First I needed
> to make sure I was able to handle authentication and authorization the same
> way.
>
> For that I implemented an action in the Grails application that would
> return me the id of the logged in user. Then all I had to do was:
>
> require 'open-uri'
> user_id = open(user_id_url, 'Cookie' =>
> "JSESSIONID=#{cookies['JSESSIONID']};
> rememberMe=#{cookies['rememberMe']}").read.to_i
>
> I created a new Devise authentication strategy and this part was completed
> so that I could focus in the fix for the buggy Grails action.
>
> Also I had to change the Devise session routes to match those of the
> Grails application.
>
> And finally, since the cookies are specific to the context path, I needed
> my Rails application to be mounted in the same context path. So I tried the
> instructions in the Configuring Rails guide, but it didn't work for me:
>
> https://github.com/rails/rails/issues/5754
>
> And I had to make some more changes to Devise routes as well as putting
> all my routes inside the context path namespace.
>
> So now I'm able to convert the Grails application to Rails in small steps
> and that is great! :)
>
> Actually my current authentication setup is a bit different and I handle
> the rememberMe cookie directly. Since I use the Shiro library to decrypt
> the cookie and I didn't want to implement everything in Ruby nor use JRuby
> on Rails as it is a slow platform for development, I implemented the
> authentication service using JRuby and Drb and created another strategy
> using the Drb client for handling the rememberMe cookie without requiring
> the Grails application to be alive for remembered sessions.
>
> Well, anyway I'll try to write an elaborate article on the details of this
> setup for anyone else willing to take the same approach as me for
> converting an application to Rails.
>
> But in those cases, the Rails API doesn't help much on dealing with such
> special cases where the Rails conventions are not always followed.
>
> Currently I don't override any property, but I wouldn't like to have to
> remember that I'm bypassing any overrides if I decide to do so in the
> future...
>
> I mean, if there is an override, there is a reason for it to exist... They
> shouldn't be just bypassed.
>
> Best,
> Rodrigo.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
