Hey Paul - thanks much for the feedback.
> I have found the documentation lacking. I am in the middle of building
> a site and every step of the way is a struggle. I find myself digging
> into code - Mason, Moose, Plack/PSGI, various plugins, ... - just to
> figure out how to do basic, simple things. Mason 2 may look a lot like
> Mason 1, but it is actually a very different beast. I should not have
> to dissect someone else's code to figure out something that could be
> documented.
Indeed, the documentation of Mason 2 is currently way behind the
implementation. Not an
uncommon situation in open source projects :), but still undesirable. Moose
for example
was this way before Dave Rolsky and others put much time and effort into
Moose::Manual.
There is definitely a cookbook of common Maosn recipes in the works but I
haven't found
the time - been swamped with paying work.
> I think a community effort, like a wiki would be a terrific idea.
I like the wiki idea very much in principle - it's why I started the masonhq
wiki years
ago. The reason it was disabled was because of the constant spam (including
obnoxious porn
spam) - it was too much effort to keep up with. If someone has a good solution
to this, or
is willing to volunteer to keep a wiki clean :), I'm all ears. The best defense
against
wiki spam is a sufficient audience mass, and unfortunately Mason HQ fell below
that.
> 1) Different configurations for the web server side. How do I make this
> work with:
> - Apache / mod_perl (for production)
> - Apache /Fast CGI (for production)
> - Standard CGI (for development or servers I cannot change significantly)
> - other servers such as AOL, etc.
>
This is the provence of Plack/PSGI, not Mason specifically. But sure it would
be useful to have a place to share this information.
> 2) The current documentation states simply that some things have been
> removed, like <%shared> and says to use <%class> instead. Huh? First,
> from a psychological standpoint, they are different things and it takes
> a bit of a leap of faith to see how they relate. Sure, I can define an
> attribute and have it inherited from Base.mc to index.mc, but it will
> not share with some random a utility component that I call - at least I
> have not found a simple way of doing that.
There was never a magical way to share with a random utility component - you
would have to
had passed along the value in Mason 1, just as you have to in Mason 2. Unless
you want
to use true globals, see #5.
> As a side note, Jonathan has been removing things like <%shared>,
> <%args>, %% and so on, because they are redundant. Perl is popular
> because of the multiple ways to do things. Experts will use <%class> to
> share and pass variables. Beginners can use <%shared> and %<args>
> because they are easy to understand. In the background, Mason
> translates it all to the same object code anyway. What's the harm?
Yes, I found when writing my initial Mason 2 sites that I would start with
shortcuts like
<%args> and %% but then move to <%class> after the components got a little more
complex,
leading to a mix of styles and a constant shifting back and forth between
syntaxes. It
felt like the bad kind of TMTOWTDI rather than the good.
Things like <%args> would (or should) be easy to implement in a plugin, that
way they'd be
available if you wanted them but the core of Mason could stay small.
> 3) How do I make Mason 2 recognize posted elements that have the same
> name and put them into an array in $.args? See Mason book pages 35-36
> for the way it used to work - which was nice. I have not been able to
> get Mason 2 to do that, and I have found no documentation that lists how
> it can be done or even states that it cannot be done.
Yes sorry, this is hidden in documentation but definitely needs to be in an
FAQ/cookbook. See
http://search.cpan.org/perldoc?Mason::Plugin::PSGIHandler#Run_parameters
If you declare an attribute as an ArrayRef, then multiple values will go into
the array.
> 4) While it may be obvious to some, it is not obvious to everyone and
> certainly not beginners, what the data types of the special variables
> are. Example is $.args. What is this and how do I access the data in
> it? A simple statement in the documentation that $.args is a pointer /
> reference to a HASH would save a lot of unnecessary work and gnashing of
> teeth.
$.args is an abbreviation of $self->args, and $self is a Mason::Component
object,
so this is documented here:
http://search.cpan.org/perldoc?Mason::Component#OTHER_METHODS
Again, needs to be in a FAQ.
> 5) How can I have global variables? Can I make them read-only? Do not
> tell me globals are evil and I should be burned at the stake for
> suggesting them.
I will not say any such thing; I'm all for judicious use of globals. This is
easy to do with:
http://search.cpan.org/perldoc?Mason::Interp#allow_globals
http://search.cpan.org/perldoc?Mason::Interp#set_global
> 6) Moose is slow. So slow, that even the Moose people address it in
> their FAQ. What can I do to speed it up? What if I can only run on a
> standard CGI server that does not have mod_perl? Is it possible to use
> Mouse instead? Will Mason2 have a conniption? Are there things I can
> do with Mason so that it will not utilize some of the slower Moose features?
Have you actually found Moose to affect your site's performance under profiling,
or is it just that you've heard it is slow?
Most of Moose's slowness, at least AFAIK, is in compilation/startup. In a
persistent web
environment such as mod_perl or FastCGI the importance of this is greatly
reduced (though
not eliminated - I myself am similarly frustrated by the startup cost of
Rose::DB::Object
even though "it's just startup").
I'm interested in creating the most powerful Perl templating framework that I
can, even if
that means having dependencies like Moose and requiring a little extra startup
time.
I have not considered Mouse support although I suppose it is a possibility down
the line.
I'm really hoping that Moose will gradually get faster to the point where this
won't matter. :)
I've little interest in trying to make Mason 2 "lightweight" enough for
standard CGI.
Honestly given the ready availability of mod_perl, FastCGI, and Starman, I don't
understand why standard CGI is even considered a viable option anymore (but I'm
sure
diehard CGI fans will yell at me for saying this).
> I could go on and on, but I am not trying to get answers to these
> questions - most I have already figured out.
I wanted to answer them anyway, to get them out here and in case our answers
differed. :)
> Traffic on the list has dropped to a tiny trickle since Mason2 came out and I
> think that
> is unfortunate. In my mind, that means one of two things: Mason 2 is so easy
> that no
> one has any questions about it, or it is so difficult, that people try it and
> quickly
> get frustrated and give up, moving on to the likes of PHP and such. I
> suspect it is the
> latter.
Actually traffic on the list was really light even before Mason 2 came out -
http://marc.info/?l=mason&r=1&w=2 - it has been steadily decreasing for years.
My best guess
is that existing Mason users already have their questions answered, and there
just aren't
nearly as many new Mason developers as there used to be. (You can also
s/Mason/mod_perl/ and
to a lesser extent s/Mason/Perl web/).
Anyway, thanks again for your feedback. If you can think of a way to have a
wiki or other
collaborative editing platform that does not run afoul of the spam problems we
had before,
I'd be eager to help make that happen and would certainly contribute handily to
it. I
just don't necessarily have the time to solve these problems or launch a new
site. :/
Best
Jon
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
