> This leads me to another scenario. Namespaced models quite simply
> as it stands you can in /app/models/ make a folder called /customer/
> there add tag.rb and note.rb. With models Customer::Tag and
> Customer::Note. One thing is the table_name will remain "tags" and
> "notes", which in t
To not have naming collisions. You can't have two classes named Tag
in the same namespace (and not using one is still in a namespace.. the
default one). Pretty standard namespace stuff.
+1 for namespaced models! :)
On 7/18/07, Pratik <[EMAIL PROTECTED]> wrote:
>
> > This leads me to another sc
So what will the table be for those namespaced models ?
On 7/18/07, Andrew Kaspick <[EMAIL PROTECTED]> wrote:
>
> To not have naming collisions. You can't have two classes named Tag
> in the same namespace (and not using one is still in a namespace.. the
> default one). Pretty standard namespac
Hey,
so you're saying that you are using the same resource names (notes,
tags) but you want those routes to go to different controllers?
map.resources :customers do |customer|
customer.resources :notes, :controller => 'customer_notes'
customer.resources :tags, :controller => 'customer_ta
On Jul 18, 4:17 pm, Pratik <[EMAIL PROTECTED]> wrote:
> On a totally unrelated note, I'm completely against the idea of
> namespaced models. Putting them in a separate directory is perfect,
> but not naming them like Customer::Tag. Why would u need to do that ?
I don't like namespaced models eith
Exactly. config.load_paths was my point when I said "Putting them in a
separate directory is perfect,".
Also, if you're gonna namespace your models as Customer::Tag - and put
them inside models/customer/tag.rb - you better name your model
CustomerTag and keep it as models/customer/customer_tag.rb
I have read over everyone's comments and I agree to a point. I'll go
over each proposed solution and add my comments.
1. Use :controller => 'customer_notes' when specifying resources to
have unique controller names
2. Use longer model names like CustomerNote instead of Customer::Note
3. Use load
> 1. The same reason that rails core named their classes
> ActiveRecord::Base, not ActiveRecordBase, or
> ActonController::Caching::Actions, not ActionControllerCachingActions,
> etc., is its poor style/design/foresight to use
> CustomerNotesController instead of Customers::NotesController. We
>
Peter,
When you invoke "convention over configuration" you have to bear in
mind that *your* convention is a product of the problems you're
trying to solve - and those problems may not match the majority's
problem-space.
There's nothing in your proposal that I can see which would make any
> This leads me to another scenario. Namespaced models quite simply
> as it stands you can in /app/models/ make a folder called /customer/
> there add tag.rb and note.rb. With models Customer::Tag and
> Customer::Note. One thing is the table_name will remain "tags" and
> "notes", which in t
I appreciate everyone sharing their own perspective. It's insightful.
Trevor, I absolutely agree with you in saying that "convention over
configuration" applies to a universal solution. But how does what I'm
proposing take away from that? Namespaces should by no means be an
enforced axiom, but
To add to that.. Rick, that type of parent/child functionality in
models is exactly what I have envisioned but with controllers. So if
that means instead of putting everything in the /app/models/customer/
directory, there exists a parent model and then child models under the
directory of the pare
However,
as it stands in edge it might work that:
map.resources :customers
map.namespace(:customers) do |customers|
customers.resources :tags
customers.resources :notes
end
This would _almost_ work. Except that there wouldnt be a reference
(at least not apparent through this routing) that
Peter,
your original ideas don't "take-away" from anything. They just don't
speak to me and they wouldn't make my apps better organized. Note
that I'm talking strictly about the controllers issue - the
namespaced models thing... I use that all over the place.
But as far as interactions b
I didn't mean for my explaination enforce a strict mapping between
controllers and routes. Only to the same extent that it already is
now. This is already becoming apparent with the map.namespace route.
I'd just like to see as I said a parent/child resource relationship in
a namespace.
Peter
O
Hello again,
For information purposes I wanted to follow up on this discussion with
an already existing solution in edge.
map.resources :customers do |ns|
ns.namespace(:customers) do |customers|
customers.resources :tags
end
end
GET/customers/
{:action=>"index", :controller=>"custom
16 matches
Mail list logo
