| I've been looking at Audrey Tang's Jifty::Plugin::Dispatcher::REST (http://pugs.blogs.com/pugs/2006/07/rhox_slides_las.html) and DHH's "Discovering a world of Resources on Rails" (http://www.loudthinking.com/lt-files/worldofresources.pdf) presentation from the 2006 RoR conference. I'm trying to work up something similar for Catalyst. My understanding from reading Catalyst's source, is that its dispatcher exclusively matches on path. I'm finding that I often want to collectively match the path, request method and uri path parameters (i.e., what follows the ';' in the path segments of the path components of the uri). I hacked something into the Path and Regex dispatchers to get collective matching on method and path working in the prototype. But working with path segment params is getting messy. Allowing POST to masquerade as a PUT and DELETE method request in order to allow HTML forms to submit using these methods means my match rules occassional encompass more than I want to match. Which makes me wish an action could decline to process a request which was dispatched to it, letting the next matching action process it. Has anyone else approached these problems? Are there any plugin's or base classes which already address this need? If not, I'm thinking I'll to hack up something that works enough that I could post it to the list for dissection. I've prototyped something similar to Jifty for catalyst. Jifty has a nice REST plugin which provides a click-through introspective interface to explore the model and perform RESTful operations. It uses extensions to specify input and output formats. The examples listed below are working in my catalyst prototype. The input/output extension examples apply to all the operations not just the one's listed in the examples: #lists models w/ DBIC result sources GET http://foo.com/=/model # default response format as html GET http://foo.com/=/model.js # response formatted as _javascript_ GET http://foo.com/=/model.json # response formatted as json GET http://foo.com/=/model.yaml # response formatted as haml GET http://foo.com/=/model.perl # response formatted as perl #list of columns, keys, and relations for "Person" model #list all distinct values for comma delimited columns #list all Person records limited by values supplied for columns #list all specified fields for all Person records limited by values supplied for columns #delete all Person records where column(s) = value(s) #create new person record with columns/values supplied in the body POST http://foo.com/=/model/Person #standard body params POST http://foo.com/=/model/Person.js #reformat from _javascript_ POST http://foo.com/=/model/Person.json #reformat from json POST http://foo.com/=/model/Person.yaml #reformat from yaml #update new person record with columns/values supplied as body parameters In order to allow HTML forms to submit using the PUT or DELETE method, I use the same approach as RoR and .NET... i.e., you submit via POST using a hidden field to specify the PUT or DELETE method. I'm now trying to merge this with DHH's RoR push to crudify everything: <presentation|view> index (GET) list new (GET) add show (GET) view edit (GET) edit <operation|model> create (POST) read (GET) update (PUT) destroy (DELETE) Damn. I have to head out. I'll try to finish up a description of what I'm doing to incorporate DHH's ideas. The short version is that he uses path segment parameters to control the aspect of how an action is handled. For example cheers, Garrett P.S. I didn't have a chance to review my post to make sure it follows an orderly thread of logic. My apologies. I'll try to clear up an questions later this evening. |
_______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
