On Tue, Jun 9, 2009 at 2:00 PM, Devin Austin <[email protected]> wrote:
> > Are you creating plugins for each of those user actions? C::P:: is the > plugin naming convention. I could have missed something though. Hi Devin, No, I'm not creating plugins. You didn't miss something; I did. I'm just creating controllers. My bad. Anyway, check out this Chained tutorial I've written, it covers the type of > chaining you want to do. Not quite as in depth as your example, but there > is a "nested" chain, so I'm sure you could figure it out from there. If > not, you have the list :-) > > http://www.catalyzed.org/2009/05/chained-the-awesomesauce.html > You've written a really good and useful article. I wish I'd run into it a few months ago. I've spent a lot of time reading up on Chained, and working out method flows, so I am at least over the initial shock of the steep (to some of us mortals) learning curve. I don't have a "Eureka!" yet, tho. Let me see if I can clarify the problem I'm having. In many of the examples I've seen, where you have a url like /account/*org/*, they show a parent controller, and a child controller. For example, on the catalyst wiki, http://dev.catalyst.perl.org/wiki/gettingstarted/howtos/chainedexamples: ========================================== package MyApp::Controller::Account; # match /account sub base :Chained("/") :PathPart("account") :CaptureArgs(0) {} # match /account/* sub id :Chained("base") :PathPart("") :CaptureArgs(1) {} package MyApp::Controller::Account::Org; # match /account/org sub base :Chained("/account/base") :PathPart("org") :CaptureArgs(0) {} # match /account/org/* sub id :Chained("base") :PathPart("") :CaptureArgs(1) {} ========================================== But I have a situation where I need to flow thru methods that aren't tightly bound to a parent/child relationship. Or I need to be able to create parent/child methods 'on the fly.' In the scenario above, /account is anchored to the root url, /. Makes sense, you have to start somewhere, right? As a user, I want to create actionitems, and since they belong to me, I'm initially ok with a parent User controller class in which base is anchored to '/' and a child Actionitems controller class. (But that gets me into trouble later...) MyApp::User; MyApp::User::Actionitem; I have my CRUD methods for actionitems in the child class. This is fine for 'items that are unassociated to meetings or projects. But when I tell the 'item it now is attached to Meeting 37, and the meeting leader does a search on Actionitems people have attached to the meeting, things get complicated. Let's say the team leader is user # 16. She logs into her /user/profile, clicks on 'meetings,' selects meeting 37, and does a search for actionitems people have sent to that meeting. Now we need a method flow like this: /user/16/meeting/37/actionitem/list The list displays. Each 'item has links to edit, delete, reassign, yada yada. But my CRUD methods for actionitems are all located in MyApp::User::Actionitem. I haven't figured out how to flow thru the User class to get $user_obj, then Meeting class to pick up $meeting_obj, and finally Actionitem class to get you know what. And when we throw /projects/ into the mix, we get even more complicated. Have I succeeded in making the issue clear? Or have I convinced you I'm completely insane? (Or maybe both...) /dennis
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
