Perhaps this is intentional, but it seems unlikely:
class Person < ActiveRecord::Base
belongs_to :school
end
p = Person.find(:first)
p.school # nil
p.school_id = School.find_by_name('High School').id
p.school.name # High School
p.school_id = School.find_by_name('Primary School').id
p.school.nam
p = Person.find(:first)
p.school # nil
p.school_id = School.find_by_name('High School').id
p.school.name # High School
You should be assigning .school= here. Why are you working with the id?
p.school_id = School.find_by_name('Primary School').id
p.school.name # High School <= Shouldn't this b
Isn't the standard way of updating relationships like this to have a
select box with name="person[school_id]" which will be updated with
update_attributes, like in the second example?
I've attached a patch which fixes the behaviour. I guess school_id
could access school.id, and school_id= would h
Hello all,
I've just generated a migration with a very long and descriptive
name, weighing in at 78 characters. Unfortunately this class name
causes Rails to generate an exception because it blindly subtracts 75
from the length of the string in the announce method of Migration.
This raise
Right now, filters run for as many times as you call, eg.,
before_filter.
If you do something like:
5.times { before_filter :foo }
it might be expect, but I think the more common case of:
@ ApplicationController
before_filter :foo
@ SubController
before_filter :foo, :except => :ba
On Jul 31, 2006, at 11:17 AM, Caio Chassot wrote:
Do you really think it's a good idea to run filters more than once?
How about maybe adding a uniq option to pre/append_filter_to_chain,
that would ensure a filter is never added twice (but related
conditions may be changed)?
It would seem t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This seems like the reasonable and expected behavior. Many of my
filters are reused as part of higher level DSL methods and my app
would become unusable if Rails decided to begin ignoring my explicit
instructions and refusing to run filters as I
I don't see the need for a :uniq option, when you can use :only
and :except on the before_filter and skip_before_filter flavors...
I think of it as way to remove the burden from the programmer to
think about whether or not the filter was already present in the
inheritance chain or not.
Sp
> I don't see the need for a :uniq option, when you can use :only
> and :except on the before_filter and skip_before_filter flavors...
I think of it as way to remove the burden from the programmer to
think about whether or not the filter was already present in the
inheritance chain or not.
Plea
On 2006-07-31, at 13:48 , David Heinemeier Hansson wrote:
Please do come up with some real life examples that skip_* can't deal
with. Unless there is a very compelling set of those, I don't think
its worth it.
I think skip_* can handle it all, I'm just wondering if there are
filters running
and then grep your RAILS_ENV.log for "called repeatedly"
So I tested this on an old app of mine and got this:
Filter :check_login called repeatedly
... only this one, a on a few certain pages
I dug in and it was due to code similar to example I first showed,
using:
before_filter :foo, :ex
On 7/31/06, Caio Chassot <[EMAIL PROTECTED]> wrote:
> and then grep your RAILS_ENV.log for "called repeatedly"
So I tested this on an old app of mine and got this:
Filter :check_login called repeatedly
... only this one, a on a few certain pages
I dug in and it was due to code similar to examp
I have the opposite. I have authentication levels monitored by before
filters from the application level down and refactored them up from gobs
of REST controllers.
Rick Olson wrote:
On 7/31/06, Caio Chassot <[EMAIL PROTECTED]> wrote:
> and then grep your RAILS_ENV.log for "called repeatedly"
On 2006-07-31, at 15:14 , Rick Olson wrote:
I rarely put before filters in my application controller, and do very
little controller inheritance. I don't see this as an issue at all.
I can't say I do either all the time, but I do it enough that I
noticed this behavior.
But I'm not bringing
When running ruby 1.8.5 (latest, stable) a bunch of warnings show up.
activerecord/lib/active_record/connection_adapters/oracle_adapter.rb:500:
warning: colon will be obsoleted; use semicolon
It seems that edge ruby wants this form for case statements:
case stuff
when 5; something
when 6; som
Hey guys, David just committed the simply restful plugin to core.
Upgrade to edge if you want to try it on your Restified apps and let
us know if there are issues. I'm currently seeing one or two edge
cases that I'm looking at right now.
The API is slightly different now:
map.resource :comment
Since trac is still out to lunch...
It's great to see SimplyRestful at last being rolled into trunk. The
code refactoring looks nice, however there is a bug in handling extra
actions in the collection/member/new options. flip_keys_and_values
(hash) will lose all but one of the actions that
On 7/31/06, Josh Susser <[EMAIL PROTECTED]> wrote:
Since trac is still out to lunch...
It's great to see SimplyRestful at last being rolled into trunk. The
code refactoring looks nice, however there is a bug in handling extra
actions in the collection/member/new options. flip_keys_and_values
(
In working out a fix for the flip_keys_and_values bug in
map.resources, I got to thinking that the current API for specifying
extra actions is backwards. The code doesn't use the un-flipped hash
at all, and the flipped version is actually more compact to specify.
For example:
map.resour
Damn that's ugly. I'd rather stay on 1.8.4...On 7/31/06, Courtenay <[EMAIL PROTECTED]> wrote:
When running ruby 1.8.5 (latest, stable) a bunch of warnings show up.activerecord/lib/active_record/connection_adapters/oracle_adapter.rb:500:warning: colon will be obsoleted; use semicolonIt seems that ed
On 2006-07-31, at 19:07 , Josh Susser wrote:
and the flipped version is actually more compact to specify. For
example:
map.resources :articles, :member => { :get => :reply,
:post =>
[:create_reply, :spawn, :split] }
That's what I thought just by lo
Here's a patch that changes map.resources to use the "flipped" hashes
for optional actions. Tests pass for new arrangement. Looks like
postback actions seem to work again too, though the
#filtered_named_routes method in your routing_navigator only shows
one of the routes with the same nam
Haha.. it kinda makes sense, since the semicolon is breaking a line..
I guess my reason for the patch was that there is inconsistency across
rails, with a mix of then, colon, semicolon, and newline.. any
thoughts on what it should be?
On 7/31/06, Nicholas Seckar <[EMAIL PROTECTED]> wrote:
Dam
I guess my reason for the patch was that there is inconsistency across
rails, with a mix of then, colon, semicolon, and newline.. any
thoughts on what it should be?
Very much depends on what makes sense in the context. I often use
different conditional styles depending on the particulars. Not us
On 7/31/06, Josh Susser <[EMAIL PROTECTED]> wrote:
Here's a patch that changes map.resources to use the "flipped" hashes
for optional actions. Tests pass for new arrangement. Looks like
postback actions seem to work again too, though the
#filtered_named_routes method in your routing_navigator o
Here's a patch that changes map.resources to use the "flipped" hashes
for optional actions. Tests pass for new arrangement. Looks like
postback actions seem to work again too, though the
#filtered_named_routes method in your routing_navigator only shows
one of the routes with the same name (but
> map.resources :comments, :member => { :get => :reply, :post =>
> [:reply, :spawn, :split] }
I totally forgot about this feature:
:member => { :reply => :any }
Look at line 151
http://dev.rubyonrails.org/browser/trunk/actionpack/lib/action_controller/resources.rb#L151
--
Rick Olson
http://t
ah! but is consistency a strength?
On 7/31/06, David Heinemeier Hansson <[EMAIL PROTECTED]> wrote:
> I guess my reason for the patch was that there is inconsistency across
> rails, with a mix of then, colon, semicolon, and newline.. any
> thoughts on what it should be?
Very much depends on what
ah! but is consistency a strength?
Context beats consistency every time. But if the context is
unimportant, then consistency is preferable to randomness.
I'm saying that the context probably did matter in quite a few of the
choices. I know I've personally used all the different styles at
differ
On Jul 31, 2006, at 8:33 PM, David Heinemeier Hansson wrote:
When do you feel that you need postbacks? In some sense, I'm seeing
the use of a richer verb set as a way of rescuing us from postbacks.
Do you have a few examples in a REST-powered app where they feel like
a good fit? I'm starting to
Postbacks aside, I still think inverting the optional actions hashes
(key by method instead of action) is still a better way to go. It's
less to type, less to transform, and I tend to think of the actions
grouped by http method anyway (at least when doing restful routes).
It's not a huge differen
> ah! but is consistency a strength?
Context beats consistency every time. But if the context is
unimportant, then consistency is preferable to randomness.
Yeah!!
I'm saying that the context probably did matter in quite a few of the
choices. I know I've personally used all the different style
On Jul 31, 2006, at 9:41 PM, David Heinemeier Hansson wrote:
Postbacks aside, I still think inverting the optional actions hashes
(key by method instead of action) is still a better way to go. It's
less to type, less to transform, and I tend to think of the actions
grouped by http method anyway
33 matches
Mail list logo
