<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:#000066">Thank you for the validation - I thought that was the case.</div><div class="gmail_extra"><br><div class="gmail_quote">On 9 March 2016 at 22:11, Darren Duncan <span dir="ltr"><<a href="mailto:darren@darrenduncan.net" target="_blank">darren@darrenduncan.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The best option is to keep the concerns separated. Models should always take their inputs via explicit arguments for a Model-specific API, and they should not have any knowledge of or direct access to a Controller. If this means you have to bundle up a larger amount of data in the Controller so the data passage is clean, so be it, that is the lesser evil. -- Darren Duncan<div><div class="h5"><br>
<br>
On 2016-03-09 11:03 AM, Chris Welch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
<br>
This is more of a general MVC question, but hopefully it's okay to ask in here.<br>
<br>
I've set up a model to generate data in iCal format (see my previous thread and<br>
thanks for the responses on that), but it has thrown up an interesting general<br>
logic separation question that I don't know the answer to.<br>
<br>
By way of an example, I'm generating iCal events for a data table called<br>
team_matches (DBIx::Class model name TeamMatch). I was hoping, as would seem to<br>
be the cleanest way to do it, to have a result class "helper" method, such that<br>
on each match object I could call something like: $match->generate_ical_data,<br>
which would generate a hashref of calendar values to be passed through to my<br>
MyApp::Model::ICal module that will generate the actual data. The problem with<br>
this is that certain properties require access to the Catalyst application: for<br>
example, there's a uri property, the value for which will need to be generated<br>
by $c->uri_for_action and since this particular application has the ability to<br>
be multi-language (via CatalstX::I18N) the description value needs to be<br>
generated by $c->maketext.<br>
<br>
All of this brings up a quandary: there are only two ways around this that I can<br>
see:<br>
* Pass $c into the $match->generate_ical_data method (which I know is<br>
STRONGLY discouraged and very very bad).<br>
* Generate the hashref in the controller (which potentially makes for a<br>
'fatter' controller than you ideally want and I'm trying to stick to the ideals<br>
here).<br>
<br>
I'm guessing the preference of the above options should really be the latter<br>
(which is what I'm currently doing in the interim), but I am hoping that there's<br>
a super-clever way that I've not thought of that someone can tell me I've<br>
completely overlooked?<br>
<br>
Thank you in advance.<br>
<br>
<br>
Chris<br>
</blockquote>
<br>
<br></div></div>
_______________________________________________<br>
List: <a href="mailto:Catalyst@lists.scsys.co.uk" target="_blank">Catalyst@lists.scsys.co.uk</a><br>
Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" rel="noreferrer" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
Dev site: <a href="http://dev.catalyst.perl.org/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/</a><br>
</blockquote></div><br></div></div>