Hey Martin, That sounds great! I would love to give it a try but I could not figure out how to install a plugin for Merb. I guess from this post (http://blog.antarestrader.com/?p=70) that it might not happen so smoothly. Standing in the root directory of my Merb app I did:
gem install snusnu-merb_resource_controller -i ./gems/ which installed your gem and all its dependencies into the 'gems' directory. I added the following line to dependencies.rb below all the others: dependency "merb_resourceful_controller" After that, when I started merb I received the following error: FATAL: The gem merb_resourceful_controller (>= 0, runtime), [] was not found (I tried the same with "snusnu-merb_resourceful_controller" to no avail.) I also read Yehuda's guide (http://yehudakatz.com/2007/09/19/merb- plugins-oh-yeah-theyre-pretty-frickin-cool-too/) -somewhat old- about how to install a Merb-plugin and that seemed to be consistent with what I do but I am surely missing soemthing. If that's an easy one, could you point me to what I am doing wrong? Thanks a lot! Balint On Dec 3, 2:34 am, "Martin Gamsjaeger" <[EMAIL PROTECTED]> wrote: > Hey Balint, > > Unless I misunderstand something > important,http://github.com/snusnu/merb_resource_controller/tree/mastermay > well > be an option? > > It basically knows how to CRUD under different nesting strategies > (i.e. /recommendations vs. /users/1/recommendations). > > It will always load your resource properly scoped (i.e. > Recommendation.all vs. @user.recommendations), without any before > filter abusing. > > It will also setup all the instance variables you would expect to find > for use in your views (i.e. @recommendations vs. @user AND > @recommendations) > > You would use it like so: > > class Application < Merb::Controller > extend Merb::ResourceController::Mixin::ClassMethods > end > > class Users < Application > controlling :users > end > > class Recommendations < Application > controlling :recommendations do |r| > r.belongs_to :user > end > end > > Maybe this helps? Let me know if anything doesn't work the way you > expect, if you try it out. Also don't be afraid to dive into the code, > read it (and the specs), fork it, throw it away, whatever ... It > currently does a nice job for me! Let's make it better by using it > more :-) > > That said, I'm all for Justin's suggestions to separate the > controllers when needed! If the only thing is avoiding nasty > conditionals for scoping queries and redirecting though, this may be a > reasonably easy alternative ... > > cheers > snusnu > > On Tue, Dec 2, 2008 at 8:24 PM, Justin Reagor <[EMAIL PROTECTED]> wrote: > > On Dec 2, 2008, at 1:47 PM, baaz wrote: > > > Clearly, the data I should show in these two cases is different, so > > the controller code should handle this somehow. > > The "create" action in the controller is even messier, redirecting to > > different URLs depending on where we came from, etc. These dual-duty > > controllers will be bloated and not nice. > > > I think you nailed it on the head yourself, sounds like two different > > resources to me. Regardless of what the data model looks like on the back > > end, the exposed resources through the public API are probably going to need > > separate controllers. > > Unless I'm misinterpreting what your trying to achieve here. > > :: Justin Reagor > > :: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
