[Catalyst] An MVC logic separation conundrum

[Chris Welch]

Thank you for the validation - I thought that was the case.

On 9 March 2016 at 22:11, Darren Duncan <darren at darrenduncan.net> wrote:

> 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
>
>
> On 2016-03-09 11:03 AM, Chris Welch wrote:
>
>> Hi
>>
>> This is more of a general MVC question, but hopefully it's okay to ask in
>> here.
>>
>> I've set up a model to generate data in iCal format (see my previous
>> thread and
>> thanks for the responses on that), but it has thrown up an interesting
>> general
>> logic separation question that I don't know the answer to.
>>
>> By way of an example, I'm generating iCal events for a data table called
>> team_matches (DBIx::Class model name TeamMatch).  I was hoping, as would
>> seem to
>> be the cleanest way to do it, to have a result class "helper" method,
>> such that
>> on each match object I could call something like:
>> $match->generate_ical_data,
>> which would generate a hashref of calendar values to be passed through to
>> my
>> MyApp::Model::ICal module that will generate the actual data.  The
>> problem with
>> this is that certain properties require access to the Catalyst
>> application: for
>> example, there's a uri property, the value for which will need to be
>> generated
>> by $c->uri_for_action and since this particular application has the
>> ability to
>> be multi-language (via CatalstX::I18N) the description value needs to be
>> generated by $c->maketext.
>>
>> All of this brings up a quandary: there are only two ways around this
>> that I can
>> see:
>>    * Pass $c into the $match->generate_ical_data method (which I know is
>> STRONGLY discouraged and very very bad).
>>    * Generate the hashref in the controller (which potentially makes for a
>> 'fatter' controller than you ideally want and I'm trying to stick to the
>> ideals
>> here).
>>
>> I'm guessing the preference of the above options should really be the
>> latter
>> (which is what I'm currently doing in the interim), but I am hoping that
>> there's
>> a super-clever way that I've not thought of that someone can tell me I've
>> completely overlooked?
>>
>> Thank you in advance.
>>
>>
>> Chris
>>
>
>
> _______________________________________________
> List: Catalyst at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/catalyst/attachments/20160310/68a48b6f/attachment.htm>