Dave - I know you have been a longtime detractor of CTRVs (components
that return values) and I mostly agree with your arguments.
But calling this "probably a very bad idea" is just too strong,
especially coming from a Mason maintainer. One gets the impression
that this will cause imminent death and destruction to a site, which
is just absurd. One also gets the impression that you'd like to
deprecate the feature, and I just want to make clear that this will
never ever happen. :)
The fact is, many large and successful Mason sites use this practice
(e.g. Amazon, quite widely). While it may not be ideal design-wise,
there are far worse development crimes to commit. At least people are
modularizing their code and eliminating repetition.
I agree that IF you are starting a website from scratch and wondering
about best practices, you should strive to put non-view-specific
logic in modules. The easiest way to get started with this is to
start using a database-class mapper (Rose::DB::Object, DBIx::Class,
Alzabo, etc.) That will give you a whole bunch of modules for "free"
and get you accustomed to putting code in modules.
Other people on this thread have touched upon some legitimate reasons
to use CTRVs. Some of these reasons do go away if you are using
Catalyst, which gives you the auto-restarting webserver and caching
and so on.
But there will always be some code that is completely view specific -
we wouldn't be using Mason if we didn't believe this. If such code
gets too large for its surrounding template, then why not break it
into a CTRV? Doing so is not only justifiable, but seems preferable
to splitting it out into an arbitrary "view utilities" module.
Jon
On Jul 3, 2007, at 2:25 PM, Dave Rolsky wrote:
> On Tue, 3 Jul 2007, Alex Robinson wrote:
>
>> In fact calling $m->comp('SELF:want) from within a perl block does
>> the right thing, that is does not make Perl think that wantarray is
>> in effect.
>>
>> It's only <% $m->comp('foo') %> where things go awry.
>>
>> The bug appears to be in how $m->print works. But I don't really get
>> the whole stack/buffer thing.
>
> That's not a bug at all. A substitution tag is more or less
> equivalent to
> calling $m->print(), which in turn works a lot like Perl's built-in
> print.
> That means it's in list context.
>
> If you want to force scalar context you'd do <% scalar ... %>
>
> Of course, that begs the very, very large question of what you're
> trying
> to achieve.
>
> If you want to interpolate the output of a component, use "<& ... &>"!
>
> The idea of using the return value of a component in a substitution
> tag is
> really dubious. As I said before, if the component _only_ returns a
> value,
> then just make it a subroutine in a module.
>
>> Sorry. This was the simplest code I could think to show the problem.
>> It is not dependent on there being output. I wasn't suggesting that
>> you would want to do it, rather showing that those snippets were not
>> equivalent.
>
> You seem to expect that a substitution tag should be in void
> context, but
> that really makes no sense. A subsitution tag basically says
> "evaluate the
> Perl bits inside the substitution tag and use the _return value_ as
> output". The fact that it expects a return value is what makes it
> work,
> and that's why it can't be in void context.
>
>>> If it's only returning something, it should be a subroutine in
>>> a module anyway.
>>
>> I think that that is not your call. I think it is perfectly
>> legitimate to use Mason components instead of, or alongside modules
>> to return stuff.
>
> It's not my call? You asked for help on the mailing list and I gave
> advice. You don't have to follow it, but don't get annoyed when
> someone
> crticizes your design. It's pretty typical of discussion on mailing
> lists
> to get to a stage where your respondents try to figure out your
> underlying
> goal, rather than directly answering your questons. That's life in the
> programming world.
>
>> Of course, if you want us to all piss off to Catalyst and
>> Template::Toolkit, that is your prerogative ;)
>
> I certainly would encourage people to use Catalyst these days. I've
> been
> using Mason with Catalyst and I'm pretty happy with it. And if someone
> wanted to try TT I'd explain why I didn't like it, but some people
> really
> do love it, so it can't be bad for everyone.
>
>> Alternatively annotate all references in the manual to say that you
>> can return values but that you shouldn't ;)
>
> The manual is, uh, old. There is, however, a chapter in the book that
> basically says more or less "don't use Mason components instead of
> modules" (http://www.masonbook.com/book/chapter-10.mhtml).
>
> Massive changes to the docs probably belong as part of the Mason 2.0
> project, which will be out by Christmas.
>
>> Is wantarray a legitimate perl function (name aside) or not?
>
> That is the name of the Perl built-in, yes.
>
>
> -dave
>
> /*===================================================
> VegGuide.Org www.BookIRead.com
> Your guide to all that's veg. My book blog
> ===================================================*/
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Mason-users mailing list
> Mason-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mason-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
