[cgi-prototype-users] content-type and content: do they deserve separation / methods

[Terrence Brannon]

CGI::Prototype is remarkably flexible, scaleable and practical. That
being the case, this is more of a philsophical question than any.

However, it is a fact that for most websites, the content-type will be
text/html for most of the pages and that the actual content will vary
on each page.

This being the case, should these two aspects of the CGI response be
two different methods, with $self->content_type existing in a base
class and re-used for most of the app and $self->content (which is
known as $self->render) be variant on each page?

[A. Pagaltzis]

Post by Terrence Brannon
This being the case, should these two aspects of the CGI
response be two different methods, with $self->content_type
existing in a base class and re-used for most of the app and
$self->content (which is known as $self->render) be variant on
each page?

That used to bug me until I started using CGI::Prototype::Hidden,
where the WRAPPER template takes care of this adequately. The
variables are all shared between the main template and the
wrapper, which includes `self`, so you just can do something like

Content-type: [% self.content_type %]

at the top of the wrapper and have a `content_type` method which
sets the default in your application class, and then change it
for pages which deliver a different type of content.

I found responsibilities are actually separated more cleanly this
way.

Regards,

[Randal L. Schwartz]

A> That used to bug me until I started using CGI::Prototype::Hidden,
A> where the WRAPPER template takes care of this adequately. The
A> variables are all shared between the main template and the
A> wrapper, which includes `self`, so you just can do something like

A> Content-type: [% self.content_type %]

A> at the top of the wrapper and have a `content_type` method which
A> sets the default in your application class, and then change it
A> for pages which deliver a different type of content.

A> I found responsibilities are actually separated more cleanly this
A> way.

Correct. Not knowing (really) what would happen when you say
->render, the best thing is to leave the content-type to the renderer,
and if you wanted to push some part of that back to controller
callbacks, the framework is definitely there.