After playing with a reimagined version of attr_accessible/
attr_protected in my plugin, I'm much happier with the model-side
filtering approach. I think it allows for more interesting and useful
defaults.
Since this API is to live only as a plugin for a bit, I'm unsure
whether this thread is the
ax reads better than "attributes =
params[:user].slice(...)", but that alone isn't enough reason to
change an API.
On May 26, 3:42 am, Hongli Lai wrote:
> On May 24, 8:25 am, Michael Koziarski wrote:
>
>
>
> > cainlevy wrote:
> > > Which points to an inter
I've put the core assign() method into a plugin. Feedback is always
desired.
http://github.com/cainlevy/mass_assignment
On May 24, 1:33 am, cainlevy wrote:
> Hey Matt, I did some thinkng about this and I'm not sure if the
> simpler use cases are actually simpler with attr_a
ention the maintenance headache when adding a
> new field...
>
> --Matt Jones
>
> On May 24, 2009, at 12:16 AM, cainlevy wrote:
>
>
>
> > Ok, primary ticket:
> >https://rails.lighthouseapp.com/projects/8994/tickets/2704-allow-call...
>
> > An
Ok, primary ticket:
https://rails.lighthouseapp.com/projects/8994/tickets/2704-allow-calltime-list-of-allowed-attributes-for-mass-assignment
And the bonus round:
https://rails.lighthouseapp.com/projects/8994/tickets/2705-deprecate-attr_accessible-attr_protected
On May 23, 5:40 pm, cainlevy
e evaluated independently.
On May 23, 4:40 pm, Damian Janowski wrote:
> On Fri, May 22, 2009 at 11:42 PM, cainlevy wrote:
> > We're all familiar with attr_accessible and attr_protected. These methods
> > provide rudimentary support from malicious mass assignment ... when peop
Hello!
I'd like to refactor the code for mass assignment to support a new security
paradigm, but figured that I might save some time getting feedback from the
gatekeepers of the code. :-)
We're all familiar with attr_accessible and attr_protected. These methods
provide rudimentary support from ma
d to writing bi-directional association
validations in my home-grown validation library. Granted, I've always
had to set the "reverse" association manually which looks a little
shoddy in my controllers, but the key to making it all work was:
http://github.com/cai
"I can agree that its dangerous to destroy attributes in this means,
but for my case there is no other way"
That's a pretty strong claim. Could you explain a little?
On Apr 5, 6:10 pm, Josh wrote:
> I can agree that its dangerous to destroy attributes in this means,
> but for my case there is n
==The Problem:
The parameter structure in the current implementation of nested attributes
does support both modification and replacement of existing has_one records.
==The Solution:
Move ids inside the hash. That is, instead of:
@pirate.birds_attributes = {
'12' => { :name => 'Polly' },
iated. I'm feeling very positive about
this approach at the moment.
-Lance
On Dec 13, 2:18 am, cainlevy wrote:
> Hey, this turned out alright!
>
> http://github.com/cainlevy/complex-form-examples/tree/cainlevy
>
> Some notes on my implementation:
> * I made a point to show t
Hey, this turned out alright!
http://github.com/cainlevy/complex-form-examples/tree/cainlevy
Some notes on my implementation:
* I made a point to show that everything works without JavaScript. But
it would be easy to sprinkle some JS in to hide the template row and
clone it for "add an
After reading previous discussions on the topic ([1] and [2]), I have
tried to take the best ideas and create a working plugin that adds
nested mass assignment to ActiveRecord. Please see
http://github.com/cainlevy/nested_assignment/tree/master.
My paradigm parameters are:
{
# singular
Hello,
I've been digging into the discussion around nested mass assignment,
and am trying my hand at a plugin that adds what I consider the
optimal model behavior. But I'm running into a solid problem trying to
use association proxies without modifying anything in the database.
My take is that t
Hello,
I ran into a problem recently that was previously reported as ticket
#802 [1]. The issue, briefly, occurs when a model definition runs a
class method (such as for a plugin) that checks table information. In
this case, loading the model requires the database table to already
exist. Running
On Aug 21, 8:35 am, Frederick Cheung <[EMAIL PROTECTED]>
wrote:
> On 21 Aug 2008, at 16:15, cainlevy wrote:
>
>
>
> > You can actually call the preload_associations method whenever you
> > want.
>
> I know, I wrote it :-)
Hey thanks! Love it. :-)
>
>
You can actually call the preload_associations method whenever you
want. It's not public, though, so you need to use send() -- perhaps
that should change?
On Aug 20, 6:08 pm, Frederick Cheung <[EMAIL PROTECTED]>
wrote:
> On Aug 18, 10:40 pm, cainlevy <[EMAIL PROTECTED]> wro
I like the preloading functionality in ActiveRecord. Can we expose an
API option for it? I know it's important to be careful with adding AR
options, but I believe that adding a :load option would complement the
existing :include and :joins options as follows:
* :include names associations that sh
18 matches
Mail list logo
