Em 07-04-2012 05:51, Robert Pankowecki escreveu:
On Sat, Apr 7, 2012 at 4:09 AM, Rodrigo Rosenfeld Rosas
<[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.
