On Thu, Jul 17, 2008 at 12:14 PM, Clemens <[EMAIL PROTECTED]> wrote:
>
> I'm generally in favor of this for pretty much the same reason as
> Hique.
> One thing, though: If this kind of behavior was merged into core, the
> fields_for method should also be updated to accept an array as its
> first p
I'd love to see something like this make it to core.
I'm a bit late in weighing in here, but for completeness, I should
mention that I attempted to solve the same problem with a plugin I
wrote called single_save (http://github.com/zilkey/single_save/tree/
master), based in large part off of Ryan'
paypal wholesale bag (paypal accepted)( http://www.super-saler.com)
paypal wholesale clothing (paypal accepted)(http://www.super-
saler.com)
paypal wholesale clothes (paypal accepted)(http://www.super-
saler.com)
paypal wholesale lrg,jeans,hoody, (paypal accepted)( http://www.super-saler.com
p
paypal wholesale bag (paypal accepted)( http://www.super-saler.com)
paypal wholesale clothing (paypal accepted)(http://www.super-
saler.com)
paypal wholesale clothes (paypal accepted)(http://www.super-
saler.com)
paypal wholesale lrg,jeans,hoody, (paypal accepted)( http://www.super-saler.com
p
Hi thomas,
Sorry to top reply so briefly, but have you seen what david dollar and
co have been discussing in the recent :accessible thread?
http://groups.google.com/group/rubyonrails-core/t/4049b4b313fa8be2
Sounds like your plugin here has some changes which could get merged
along with his stuf
Thanks, that worked.
The reason I'm updating attributes in this "complicated" way is that
I've overridden the credentials= assign method, so that I can handle
CUD (create, update, delete) operations on the association from the
same form w/o special-casing in the controller. The controller just
c
On Jul 16, 6:57 pm, Pratik <[EMAIL PROTECTED]> wrote:
> Has anyone any strong opinions against this ?
I think the key here is that the new :accessible=>true option allows
for mass assignments on create, but doesn't support a good method for
doing updates. It should be both or neither, therefore
Hi,
A few months ago I fixed a Rails bug that was yielding weird, unexpected
results when parsing form parameter names: effectively HWIA semantics
were screwing up UrlEncodedPairParser's parameter parsing when dealing
with nested values. This fixed the defect in question -- and thus solved
my