On 5/31/06, Michael Koziarski <[EMAIL PROTECTED]> wrote:>
Sadly, HABTM has to support those 'rich attributes'. Pulling in
those values is a 'feature' not a bug. The consequence of this is
that HABTM cannot support join tables with a column called id.
Regardless of whether its a feature, b
Sadly, HABTM has to support those 'rich attributes'. Pulling in
those values is a 'feature' not a bug. The consequence of this is
that HABTM cannot support join tables with a column called id.
Just a thought, but adding this patch might be way to transition folks
from habtm to has_many :thr
On May 30, 2006, at 6:35 PM, Nicholas Seckar wrote:
It would not be hard to make a plugin to do this...
Actually Nicholas, putting this into core would be a good idea, as we
could 'fix' caching -- we could save page caches to all the paths for
a parameter set, and sweepers would be able t
On May 30, 2006, at 4:04 PM, Charlie Bowman wrote:
Charlie, I'm afraid I don't understand. How would it know to
build /pragmatic/ index from {:controller => "pragmatic", :action
=> "index"}, when you've connected it to ''? You can't have one
route that maps to two paths, I'm afraid. - Jamis
I can understand habtm is moving towards deprecating support for extra
attributes in join_table, and to use :through for those cases instead.
To clarify, patch for #5216 wasn't looking to support populating extra
attributes in join table. But rather, it was meant to make habtm resilient
against e
On May 30, 2006, at 3:11 PM, Charlie Bowman wrote:
Will there now be a way to get the long url back? Here's an example.
map.connect '', :controller => "pragmatic", :action => 'index'
Can we now map this back to /pragmatic/index by using url_for? I
don't know if anyone else uses this, but
Charlie,
I'm afraid I don't understand. How would it know to build /pragmatic/
index from {:controller => "pragmatic", :action ="" "index"}, when
you've connected it to ''? You can't have one route that maps to two
paths, I'm afraid.
- Jamis
That's what I thought. I spent quite a l
ah but a documentation patch is being worked on:
http://dev.rubyonrails.org/ticket/5165
Please, write a decent documentation, since the current one is kinda
missing. :)
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyo
On May 30, 2006, at 1:11 PM, Charlie Bowman wrote:
Will there now be a way to get the long url back? Here's an example.
map.connect '', :controller => "pragmatic", :action => 'index'
Can we now map this back to /pragmatic/index by using url_for? I
don't know if anyone else uses this, but
It would be nice if route parameters could be dinamicly accessible by default values.
Something like this:
map.dashboard ':module', :controller => '#{module}/dashboard'
So http://thedomain.com/organizer would actually call :controller => "organizer/dashboard', :action ="" 'index'
But there's a p
Hi Jamis,
Thanks for the notice. I'll keep an eye on it and make adjustments to
the Request Routing plugin as necessary. I'm looking forward to a
rewrite of the routing code, it's the most difficult to extend of part
of Rails.
Cheers,
Dan
On 5/30/06, Jamis Buck <[EMAIL PROTECTED]> wrote:
Ni
Will there now be a way to get the long url back? Here's an example.
map.connect '', :controller => "pragmatic", :action ="" 'index'
Can we now map this back to /pragmatic/index by using url_for? I don't know if anyone else uses this, but it would really help me out on the page expiration
Nicholas Seckar and I have been working on a rewrite of the routing
code, making it leaner, faster, and easier to understand. It will
also be easier to extend, so it is an all-around win.
However, because it is a rewrite, the internals have changed
significantly. If you have code (a plugin
Hi,Posting here since issue tracking isn't the best place to discuss.I
can understand habtm is moving towards deprecating support for extra
attributes in join_table, and to use :through for those cases instead.
To clarify, patch for
#5216 wasn't looking to support
populating extra attributes in
This afternoon I was looking at the tickets posted in Trac, and I saw
that there we quite a few stale tickets and patches. A lot of these
are filed against very old versions of Rails, I think it's fair for
the people posting these tickets that they get resolved. Either by
just removing them
There's some confusion as to what the :limit option should mean when
used against integer columns in migrations.
Patch #2900 added support for limits in PostgreSQL mapping mapping
limit < 4 to smallint, > 4 to bigint, and anything else to integer (so
the limit is the number of bytes)
However, th
16 matches
Mail list logo
