I understand that it is just a simple symbol match and you have to
write your own business logic behind it:
If we imagine we have a role system along these lines, where a
#the_current_user method returns a User instance that has a
#roles_list method that returns an array of roles (as Symbols)
Then we could imagine something like the following logic to make it a
bit more convenient and logic DSL like (IMO):
# as_role current_user_roles do |role|
# role.update_attributes_of(Project).with params[:project]
# role.create(Project).with params[:project]
# end
def as_role role, &block
yield RoleModelManager.new role
end
def as_roles *roles, &block
yield RoleModelManager.new roles.flatten
end
class RoleModelManager
attr_accessor :roles
def initialize *roles
@roles = roles.flatten
end
def update_attributes_of model_clazz
AttributesUpdater.new model_clazz
end
def create model_clazz
ModelCreator.new model_clazz
end
class AttributesUpdater
attr_accessor :clazz
def initialize clazz
@clazz = clazz
end
def with attributes = {}
clazz.constantize.update_attributes(attributes.merge(:as =>
roles))
end
end
class ModelCreator
attr_accessor :clazz
def initialize clazz
@clazz = clazz
end
def with attributes = {}
clazz.constantize.create(attributes.merge(:as => roles))
end
end
end
def current_roles
the_current_user.roles_list
end
What do you think? My question is, if the current logic relating to
the :as option can evaluate according to an array of symbols (using
#include? fx) ?
On May 18, 6:11 pm, Michael Koziarski <[email protected]> wrote:
> On Wed, May 18, 2011 at 11:52 AM, Kristian Mandrup <[email protected]> wrote:
> > I'm curious whether you can define the :as option as a list of roles?
> > All the examples I have seen only has the :as linked to the single
> > role :admin.
>
> In short, no, it's not a 'role' in the sense that you mean here,
> rather the name of a parameter filter to use. Your app itself will
> need to have it's own logic and semantics for figuring out which
> filter to use based on your own business rules.
>
>
>
>
>
> > How would I use this with a roles system?
>
> > Say I had a #current_user_roles method available from my Controller or
> > whatever.
>
> > def update
> > Project.update_attributes(params[:project], :as =>
> > current_user_roles)
> > end
>
> > One possible DSL tweak allow something like this:
>
> > as_role current_user_roles do |role|
> > role.update_attributes_of(Project).with params[:project]
> > role.create(Project).with params[:project]
> > end
>
> > Here the #as_role should return some object that has the methods
> > #update_attributes #create and so on and a method/reader for the roles
> > to apply the role permission check.
>
> > On May 13, 2:00 am, Pan Thomakos <[email protected]> wrote:
> >> Hi,
>
> >> I think it's awesome that Rails 3.1 introduces the attribute accessible
> >> roles/permissions:
>
> >> class User
> >> attr_accessible :name, :as => :admin
> >> end
>
> >> User.create(params[:user], :as => :admin)
>
> >> But would it be possible to make this a chained function as was done with
> >> find, where and
> >> scopes from Rails 2.x to Rails 3.0? Here's a little more on the
> >> topic<http://ablogaboutcode.com/2011/05/12/activerecord-3-1-mass-assignment...>.
> >> Maybe ARel could be
> >> leveraged to do this?
>
> >> I can see that there might be conflicts with user defined scopes, but isn't
> >> chaining functions
> >> just so much more elegant than passing multiple hash parameters to a
> >> function?
>
> >> Thanks,
> >> Pan
>
> > --
> > 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
> > athttp://groups.google.com/group/rubyonrails-core?hl=en.
>
> --
> Cheers
>
> Koz
--
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.
