Hey Yehuda,
Ah, this is pretty interesting
On 15/11/2008, at 3:44 PM, Yehuda Katz wrote:
> Julian,
>
> In my opinion, part of the missing link for the fat-model, skinny-
> controller argument is that there's a missing, almost etherial
> object. It's called the "resource". In Rails and current Merb, a
> resource is just a set of router macros that are very difficult to
> extend.
>
> Some scenarios that make implicit use of this etherial object:
> * authorization: "allow only foo users access to do <some action> to
> this resource"
> * cache expiry: "when this resource changes, expire its controller"
> * URL lookup: "give me the URL for <some action> on this resource"
> * multiple models in a single form: "confirm that these associated
> objects are valid"
> * a form that's backed by a non-ORM backend: "this form should
> populate a web-service"
>
> At the moment, a lot of that is done either in the controller of
> model, but it's out of place in both. Why? Because this "resource"
> is really a composite of the current request (and its associated
> session) and the model (which may or may not be backed by an ORM).
> The solution: hydrate this object and make it usable by end-users.
> The timeline: ... ;)
>
> -- Yehuda
>
> On Fri, Nov 14, 2008 at 5:05 PM, Julian Leviston
> <[EMAIL PROTECTED]> wrote:
>
> That seems like a spastic place to put it, to me.
>
> What if you want to re-use your models at a later date? If so, you've
> got some kind of URL-bindings in them... what if the models aren't
> even being used in a merb or rails app?
>
> Way to tie the models to the app forever!
>
> This is the problem with Rails - it doesn't focus on re-use enough. If
> I remember correctly DHH even said something akin to you're better off
> rolling a fresh project each time from memory.
>
> Me? I'd prefer drop-in-reusable code.
>
> This push towards tiny controllers is a bit stupid, IMHO. The
> controllers essentially are the core glue of your app. The view layer
> is the part where the user interfaces with your app, and this (as far
> as I'm concerned) includes the URL - this is a part of the user-
> interface to your app. Thus, the router is part of the view layer.
>
> Therefore, the router should be the place to specify this. The
> documentation is a little light on, isn't it?
>
> So far as I can see, the way to do this would be a named route thusly:
>
> # in your routes file
>
> Merb::Router.prepare do
> match("/location/:id-:name").to(:controller
> => :location, :action
> => :show).name("location")
> end
>
> # usage - in view files
>
> url(:location, location, location.name)
>
> It would be nice to be able to specify methods of arguments:
>
> Merb::Router.prepare do
> match("/location/:id-#{argument_1.id.as(:id)}").to(:controller
> => :location, :action => :show).name("location")
> end
>
> but that looks really messy and convoluted. There must be a simpler
> solution: I'd wager it'd be off the beaten-track of rails-like routes.
> Surely we've outgrown them in flexibility and function. Shit, I know
> Rails has!
>
> Essentially what would we're aiming at is a good way to specify
> matching 'location/' then a named (:id) parameter that represents the
> first object's id method, then a named parameter (:name) that
> represents the first object's name method.
>
> Food for though.
>
> Julian.
>
> On 15/11/2008, at 11:33 AM, [EMAIL PROTECTED] wrote:
>
> >
> > hi,
> > how can i define the routes such that url(:location, location) would
> > generate this url "/location/3-san_diego" rather than "/location/3"
> >
> > I don't understand this help page
> > http://wiki.merbivore.com/howto/router
> >
> > In Rails, I can define the url in the model, not the routes file
> using
> > def to_param "#{id}-#{name}" end
> >
> >
> > O Nov 13, 11:40 am, "Michael Klishin" <[EMAIL PROTECTED]>
> > wrote:
> >> 2008/11/13 [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> >>
> >>> Won't the router just catch urls, not define them?
> >>
> >> Router defines rules for both recognition and generation. Same
> thing
> >> in Django, Rails, Pylons and wherever else you can find the same
> >> routing table approach.
> >> --
> >> MK
> > >
>
>
>
>
>
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"merb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/merb?hl=en
-~----------~----~----~----~------~----~------~--~---
