Mailing List Archive: View Questions

Catalyzers,

I'm working on a new view for Template::Declare, after taking the time
to really understand [how it works][]. I've based the code on the
functionality of Catalyst::View::TT, in order to have full feature
parity. But I have a couple of questions about how things are
structured and would appreciate feedback.

First, I noticed that `render()` in View::TT and View::Mason does not
throw an exception on failure, but returns an exception object instead
of the content. This is…bizarre. Is there any reason not to change
things so that `render()` only returns content and throws an exception
on failure? If not, I'll patch TT and Mason and make it so in
View::TD, as well.

And second, I notice that View::TT adds TT variables for $c, $c->req-
>base, and $c->config->{name}. Right now I just have a `config()`
method (and an alias, `c()`). How important is it that there also be
`base()` and `name()` methods to correspond to TT's variables?

Thanks!

David

[how it works]: http://justatheory.com/computers/programming/perl/modules/template-declare-documented.html

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On 30 Oct 2009, at 05:34, David E. Wheeler wrote:
> First, I noticed that `render()` in View::TT and View::Mason does
> not throw an exception on failure, but returns an exception object
> instead of the content. This is…bizarre. Is there any reason not to
> change things so that `render()` only returns content and throws an
> exception on failure? If not, I'll patch TT and Mason and make it
> so in View::TD, as well.

I have no idea why it works like this, looks stupid to me. Does the
exception returned get propagated into $c->errors? I'd guess not, so
this just feels broken to me..

i don't see any issue with throwing an exception if the view does,
and I'd certainly support that being changed unless someone can come
up with goes reasons why it's that way.

> And second, I notice that View::TT adds TT variables for $c, $c-
> >req->base, and $c->config->{name}. Right now I just have a `config
> ()` method (and an alias, `c()`). How important is it that there
> also be `base()` and `name()` methods to correspond to TT's
> variables?

I think base() is pretty useful (for example, quite possibly it's a
nicer way to generate paths to static content than bothering to
invoke uri_for?).

name() - much less so, I guess that'd be totally your call :)

Cheers
t0m

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev