Mailing List Archive

A View is fine but because there is a format for files and it's
natural to show/deliver content with a view.

The view is going to be very THIN though. Basically nothing but a
wrapper around what iCalendar really is which is data and therefore
the Model domain. The view will essentially be Data::ICal->as_string +
Content-Type => text/calendar + file disposition name something
reasonable with a .ics or .ifb. I think the model should do all the
heavy lifting. That allows it to be easily repurposed in other places,
tools, and tests.

I'm somewhat surprised no one has already done this. Casual searches
look like maybe it's been solved before but not released to the CPAN.
I was toying with a similar project years ago but never got the buy-in
from the project leader. :P

_______________________________________________
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/

Thanks for the reply - may I ask what the model would be doing, given that
presumably it would have to go through a view in the end anyway? Because
the data itself already exists in a model, all I'm wanting to do
effectively is extract that and display it in a slightly different format,
so I'm surprised that another model is the way to go - but then I've sort
of been learning as I go with this stuff, so I may well be missing
something fundamental!

Thanks

looks to me like you'd want Catalyst::Model::Adaptor + Data::iCal + an
optional very thin view that did something like:

$c->res->content_type($ical_content_type);
$c->res->body($c->stash->{calendar});

in the process method, and not much else.

The reason you don't see views for stuff like this much in catalyst land is
that this kind of thing is usually pretty simple.

On Fri, Mar 4, 2016 at 8:22 PM, Chris Welch <welch.chris@gmail.com> wrote:

> Thanks for the reply - may I ask what the model would be doing, given that
> presumably it would have to go through a view in the end anyway? Because
> the data itself already exists in a model, all I'm wanting to do
> effectively is extract that and display it in a slightly different format,
> so I'm surprised that another model is the way to go - but then I've sort
> of been learning as I go with this stuff, so I may well be missing
> something fundamental!
>
> Thanks
>
> _______________________________________________
> 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/
>
>

If you don't have a lot of view only logic (the view is just a dumb 'take this perl data structure, convert it to a display format using default serialization rules and send it to the response) then a thin view adaptor with Catalyst::Model::Adaptor might be the easiest thing.  If you are using the most recent Catalyst you could even avoid the need for a boilerplate proxy class using component injection.
Then main thing is thinking about how to shuffle data to the view.  Most current art uses the stash, but lately I prefer to avoid that and use either a dedicated view model, or the default model, so that I can properly constrain my data and offer the view better view only logic.
In general think 'how can I do something generally useful' over 'what is the Catalyst way to do this'.  Ideally your Catalyst components (models, views, etc) are the thinnest possible layer to adapt a stand alone model.
jnap

On Friday, March 4, 2016 4:28 AM, Kieren Diment <diment@gmail.com> wrote:


looks to me like you'd want Catalyst::Model::Adaptor + Data::iCal + an optional very thin view that did something like:

    $c->res->content_type($ical_content_type);
    $c->res->body($c->stash->{calendar});

in the process method, and not much else.

The reason you don't see views for stuff like this much in catalyst land is that this kind of thing is usually pretty simple.

On Fri, Mar 4, 2016 at 8:22 PM, Chris Welch <welch.chris@gmail.com> wrote:

Thanks for the reply - may I ask what the model would be doing, given that presumably it would have to go through a view in the end anyway?  Because the data itself already exists in a model, all I'm wanting to do effectively is extract that and display it in a slightly different format, so I'm surprised that another model is the way to go - but then I've sort of been learning as I go with this stuff, so I may well be missing something fundamental!
Thanks
_______________________________________________
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/




_______________________________________________
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/

If you don't have a lot of view only logic (the view is just a dumb 'take this perl data structure, convert it to a display format using default serialization rules and send it to the response) then a thin view adaptor with Catalyst::Model::Adaptor might be the easiest thing.  If you are using the most recent Catalyst you could even avoid the need for a boilerplate proxy class using component injection.
Then main thing is thinking about how to shuffle data to the view.  Most current art uses the stash, but lately I prefer to avoid that and use either a dedicated view model, or the default model, so that I can properly constrain my data and offer the view better view only logic.
In general think 'how can I do something generally useful' over 'what is the Catalyst way to do this'.  Ideally your Catalyst components (models, views, etc) are the thinnest possible layer to adapt a stand alone model.
jnap

On Friday, March 4, 2016 4:28 AM, Kieren Diment <diment@gmail.com> wrote:


looks to me like you'd want Catalyst::Model::Adaptor + Data::iCal + an optional very thin view that did something like:

    $c->res->content_type($ical_content_type);
    $c->res->body($c->stash->{calendar});

in the process method, and not much else.

The reason you don't see views for stuff like this much in catalyst land is that this kind of thing is usually pretty simple.

On Fri, Mar 4, 2016 at 8:22 PM, Chris Welch <welch.chris@gmail.com> wrote:

Thanks for the reply - may I ask what the model would be doing, given that presumably it would have to go through a view in the end anyway?  Because the data itself already exists in a model, all I'm wanting to do effectively is extract that and display it in a slightly different format, so I'm surprised that another model is the way to go - but then I've sort of been learning as I go with this stuff, so I may well be missing something fundamental!
Thanks
_______________________________________________
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/




_______________________________________________
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/