[Catalyst] An MVC logic separation conundrum

[Trevor Leffler]

Chris,

Related to this, I've a scheduled job that sends email that include URLs 
back to my catalyst app, so... can't really use a callback here.  URL 
details such as hostname and path are configuration info.  It would be 
nice to have a light-weight method for accessing the app's routing, but 
I'm okay with the balance and separation of concerns achieved via some 
minor "duplication."

As a second example, my app does something similar to yours...

   my $cj = $c->model('Collection::JSON');
   $cj->add_links({href => $c->uri_for(...)->as_string);

This model holds data returned via my Web API.  It's bothered me that if 
I wanted to use it outside of a web app I'd need some other way to 
supply URIs, but I've also shrugged this off because, um... *it's for a 
Web API* and the coupling seems necessary.  ;)  Regardless, the model's 
interface is clean, and it's not the model's job to figure out what the 
end-point URIs are supposed to me.

Okay, enough with my ramblings!

Cheers,
--Trevor

On 03/10/2016 04:03 PM, Aristotle Pagaltzis wrote:
> * Chris Welch <welch.chris at gmail.com> [2016-03-10 15:45]:
>> My original question was not about passing the method call in per se,
>> but the return value from that method call
>
> You could do that of course.
>
> The question I’d ask is, does the caller have to know which values from
> the match object it needs to pick out and put together to produce the
> required value?
>
> If yes, then that would leak responsibility from generate_ical_data back
> into its caller – which means e.g. if you want to change exactly how the
> iCal data is generated then you also have to change the caller, not just
> generate_ical_data.
>
> If not, such as if the values you pass to uri_for_action depend on the
> action only, then you can just pass the return value without causing
> problems, sure. And if you *can* do that, then it’s the better choice,
> because the code will be more readable that way – not just the caller
> but more importantly generate_ical_data itself. Callbacks will be quite
> a bit more clunky than simple values there.
>
> Like I said, it depends on the exact specifics.
>
> Regards,
>