ok I see,
its a nice pattern
if we had
def people_scope
@account ? @account.people : Person
end
this would need overriding/changing if suddenly we wanted this
controller to be used in any other route. i.e tags/merb/persons
so I was kind of thinking something along the lines of
http://pastie.org/282729
sticking to defining specifications in the routes this is more then
possible, I even think the code as is would even handle singleton
resources, via defining the specification collection_method
I like the idea of ORM api, because I dont want to have to cater for
everyone when building a plugin I just want datamapper, but people can
then easily put in the ORM of their choice.
Richard
On Oct 1, 7:35 am, "Michael Klishin" <[EMAIL PROTECTED]>
wrote:
> 2008/10/1 [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
>
>
>
>
> > good work on the handbook by the way.
>
> > my thinking behind defining at the route level would enable the
> > scoping to be automatically known, as the resource_route would hold
> > the specifications.
> > These can then be parsed on the controller just b4 dispatching to the
> > controller action, from the specifications we would automatically know
> > what scope we where in.
>
> > so basically a route would have specifications sent through the
> > options when generating from the behaviors.
>
> > images_controller.resource_specifications == [comment_spec,
> > images_spec] from the url "comment/1/images"
> > images_controller.resource_specifications == [myhome_spec,
> > images_spec] from the url "myhome/images"
>
> > then just as the controller has some nice remixes for the
> > authentication and conditional_get goodness we could also mixin
> > resourceful type goodness,
>
> That is what I personally would go for, mixins. I use this pattern a lot in
> my resource controllers and I think we can incapsulate that into the same
> set of methods, #parent, #object, etc, that resource_controller has.
>
> http://gist.github.com/14042
>
> To customize it, you just override what you need. To provide base
> class I'd use mixins, too,
> something like
>
> class Tickets < Merb::Controller
> include GenericActions::Show
> end
>
> If you want to create a singleton resource, like a profile, you can
> use something like
>
> is SingletonResource.
>
> where is method is just alias for include or some simple wrapper to
> allow options, similar to DataMapper.
>
> Keep in mind display method already does some help with simplifying of
> code of generic actions.
> It smartly uses template if it is available or falls back to
> to_whatever call on the object.
>
> About ORMs, we need to some up with some "Merb ORM API" that every ORM
> has adapter for, and
> we can use it in lots and lots of plugins.
>
> What do you think?
> --
> MK
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
