As you know, by default the TT View maps actions to template files based on the action's name. The controllers place data into the stash and the templates render that into markup.
I need to do something similar with JSON output. The current JSON View will turn data in the stash into JSON, but what I need is code that sits between the controller action and the JSON view that is action-specific (just like the templates are action-specific). This code would take the objects in the stash and build a hash used by the JSON view. I need to do this for a large number of actions, so I'm looking for something to work for all controllers. I could do this in the controller (map the data into the stash for the JSON view), but the same controllers are used for many views, so the controller's job is just to populate the stash with model objects. The rendering of HTML, as well as rendering to JSON, is a View task. The TT View has a system for running code (the templates) for each action. I'm looking for suggestions how to implement something similar when rendering JSON. That is, having the view call methods based on the action name -- and suggestions were those methods should live. Those action-specific view methods would be responsible for mapping to a hash structure the JSON view will render. In case the question wasn't clear: how should I implement a View that has methods associated with specific controllers and where should that live? Of course, I'm interested in hearing other approaches, too. There's a part 2 of this question: For the JSON responses the view will be mostly returning column data fetched from the model (using DBIC queries). The database column names are not CamelCase, but the front-end/Javascript programmers favor CamelCase. That means for every action we need to map data from the stash to a JSON response and at the same time map to the CamelCase names. I'm not thrilled about that mapping -- I'd prefer to use the column names to reduce confusion and simplify code, but that's another story. Also, these JSON responses will become part of the public API, so once we start down the CamelCase path we are there for good... Maybe this is a DBIC-list question, but I'm wondering if anyone has a clever way where I could map the DBIC objects to a hash but where the CamelCase names are used instead of the existing column names. It's painful enough without having to do it for every action explicitly. Something similar to DBIC's HashRefInflator. -- Bill Moseley mose...@hank.org
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/