<br><br><div class="gmail_quote">On Sat, Mar 6, 2010 at 12:59 PM, J. Shirley <span dir="ltr"><<a href="mailto:jshirley@gmail.com">jshirley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
</div></div>I don't think the path taken with Catalyst::Action::REST is the best,<br>
but it does work very very well in my opinion and I certainly can't<br>
think of anything better. Being able to send to a serialization<br>
method based on the content-type solves a lot of these issues. You<br>
could just setup a content type for your feed in configuration and<br>
write a custom serialize class and get exactly what you are asking<br>
for.<br></blockquote><div><br></div><div>I agree, ::REST works well for what it does, but doesn't provide a framework for a View that is action-specific. ::REST assumes that the actions set an entity in the "rest" stash that can be serialized. But, if the same action is used for a TT View then probably want to just pass model objects in the stash instead of creating a "rest" structure in the stash.</div>
<div><br></div><div>One could argue that actions should always result in the same data in the stash regardless of the View (the Controller has no idea about the final View). The reality is that a request to /blob/recent_posts would return different data in a JSON response than would be use to render a web page with a TT view.</div>
<div><br></div><div><br></div><div><br></div><div>The "problem" I'm up against is we have an existing application written for the web -- so actions expect GET and POST requests and place objects in the stash. Then TT uses the objects in the stash to render the markup.</div>
<div><br></div><div>Now we need to expose these same methods (which means same URLs really) for two similar purposes. New development for the web app is all client side. Fat AJAX that talks to the application via JSON serialized (mostly) requests and responses. Plus, we need to expose a REST API for third party customers. So, really it's just an API for both.</div>
<div><br></div><div>::REST will work fine for new actions, but there's a lot of existing actions that need to work both for TT rendered pages and for JSON responses.</div><div><br></div><div>I think the action's job should be to take a request, validate, authenticate, authorize, etc, then either generate error or place model objects in the stash. Then pass off to the view to render/serialize.</div>
<div><br></div><div>The problem is that a request coming from a browser may be slightly different than from an AJAX or API request. (Request might come in a as a POST on the web and a PUT via the API and parameters might be slightly different.) So, either need to dispatch to different actions for same request URL or have some kind of filtering code that runs before the action to "normalize" the request for the action depending on where it's coming from.</div>
<div><br></div><div>Obviously, it makes sense to share the actions where possible.</div><div><br></div><div>Likewise, the TT View passes control to an action-specific template to render the markup for the request, but the same action might need to return JSON so in that case would need to also have action-specific code to build the json stash from the objects the action fetched.</div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
I don't want to evangelize ::REST too much, so to address your </blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">suggestions more directly I'd have to say that relying on $self->can<span class="Apple-style-span" style="border-collapse: separate; font-family: arial; font-size: small; "> </span></span></blockquote>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">seems a bit too limited for my tastes.</span></blockquote><div><br></div><div>I don't like it either. Still, to me it seems the act of taking the model objects loaded by the controller and building the "json" stash is a View action -- not something that should happen in the controller action. </div>
</div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br>
</span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'd lean on configuration more so than $self->can. Then a call to<br>
$self->get_serializer_for('JSON') that returns some serialization<br>
object (or whatever handler you have) is simple, and coupling it with<br>
Moose would work very well. Then you can work out adding new<br>
serialization calls just in config.<br></blockquote><div><br></div><div>So are you suggesting that $self->get_serializer_for('JSON') would return code that would be action-specific? That is for a request to</div>
<div>/blog/recent_posts would return code that would know what to put in the "json" stash for that specific request?</div><div><br></div><div>I like the idea of leaning on the configuration implementation -- just not sure what that looks like. ;)</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
However, I'm having a hard time thinking about any valid use cases for<br>
this, especially since ::REST does things fairly well (especially for<br>
how old the code is) so I'd automatically use that for all the cases I<br>
can think of. Anything else that doesn't fit, I'd just defer to having<br>
separate views (and possibly a different RenderView+end action as<br>
appropriate).<br></blockquote><div><br></div><div>If I was starting fresh I'd be tempted to write all the controller actions with ::REST. I'd like it if the various _<METHOD> actions were real actions for dispatching (they aren't right?). Real actions would mean could test things like Args:</div>
<div><br></div><div> sub blog_GET : Local Args(1) { # GET requires an argument</div><div> sub blog_POST: Local Args(0) { # POST creates and must not have an argument</div><div> sub blog_PUT : Local Args(1) { # PUT requires and argument</div>
<div> sub blog_DELETE : Local Args(1) {</div><div><br></div><div>Then layer the web app on top -- especially if it's all client side. But, again I still think the action's job would be to just place model objects in the stash -- not build a "json" structure as that is only needed when the response is actually json.</div>
<div><br></div><div> </div></div><br>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org">moseley@hank.org</a><br>