Discussion:
[Mason-devel] Weekly todo activity, Aug 25 to Sep 01
m***@asimov.net
2002-09-01 07:01:01 UTC
Permalink
Weekly todo activity, Aug 25 to Sep 01

Task #286: Make tests for class overriding
Sun Aug 25 Dave Rolsky writes: Additionally, the
HTML::Mason::Request::WithApacheSession tests only work if
Mason's Request subclassing mechanisms work.
http://www.masonhq.com/docs/todo/access.html?id=286

Task #361: Add documentation about busy_lock replacement
Sun Aug 25 Dave Rolsky changed status from Start to Checked In
Dave Rolsky writes: It's in Devel.pod as "Avoiding Concurrent
Recomputations". I'm blind.
http://www.masonhq.com/docs/todo/access.html?id=361

Bug #367: Current ApacheHandler version confuses CPAN
Sun Aug 25 Dave Rolsky changed status from Start to Checked In
Dave Rolsky writes: only ApacheHandler and Exceptions had
version numbers set from CVS, so I simply bumped AH to 1.69
and Exceptions to 1.43 (which is 1 higher than the current
CVS version). When we move the Mason::* namespace, we can
stop setting $VERSION entirely.
http://www.masonhq.com/docs/todo/access.html?id=367

New bug #372: %ARGS cannot be accessed in <%filter>
The implementation of <%filter> changed from being inline in
the main subroutine to its own subroutine, and %ARGS is
declared in the main subroutine. Thus <%filter> no longer
has access to %ARGS.

Moving the "my %ARGS" outside the "->new" won't work because
each subcomponent and method has its own %ARGS hash. Could
the filter sub take the %ARGS in its parameter list as well,
just as each component does?
Thu Aug 29 Jonathan Swartz created bug
Jonathan Swartz set severity to Minor
Jonathan Swartz set version_found to 1.09_01
Jonathan Swartz set version_goal to 1.14
http://www.masonhq.com/docs/todo/access.html?id=372

New bug #373: Documentation of ApacheHandler initialization in handler.pl incorrect
The docs imply that ApacheHandler can be initialized without
comp_root or data_dir in a handler.pl outside of the
handler(), which is incorrect. There's no way to get
DocumentRoot without an active request.
Thu Aug 29 Jonathan Swartz created bug
Jonathan Swartz set severity to Minor
Jonathan Swartz set version_found to 1.09_01
http://www.masonhq.com/docs/todo/access.html?id=373

New bug #374: Switch.pm no longer works in file-based components
In 1.0x one could use Switch.pm in standard file-based
components. In 1.1x this no longer works (along with,
presumably, any Filter-based module). The reason is a subtle
change in the way that component files are loaded: do($file)
versus eval($buffer).

We need to either figure out how to support this again in a
limited way, or document that it no longer works.
Thu Aug 29 Jonathan Swartz created bug
Jonathan Swartz set severity to Minor
Jonathan Swartz set version_found to 1.09_01
http://www.masonhq.com/docs/todo/access.html?id=374

New task #375: Improve Admin docs re: configuration
There is still confusion over the difference between
httpd.conf and handler.pl configuration.

I think this can be helped with the following:

- Distinguish between these two as basic (httpd.conf) and
advanced (handler.pl) configuration methods

- Completely separate the two in the docs, and don't refer
back and forth between them

- Put the basic config stuff early in the admin docs, and
the advanced stuff much later, not one after the other.
Basically, the advanced part should be near the end and
totally separate. When explaining how to do something like
decline image requests, we should not show both ways of
doing this in one section. Rather, we show how to do it via
httpd.conf in one place and via a handler.pl line elsewhere.

- Explain what the handler.pl is actually doing (creating a
handler() sub to be used directly by mod_perl) in terms of
hooking together mod_perl & Mason. It is not a magic
incantation. Stress that people using this method should
understand how mod_perl works.

I think by doing these things we can greatly reduce
confusion.
Thu Aug 29 Dave Rolsky created task
Dave Rolsky set difficulty to 3
Dave Rolsky set version_goal to 1.14
http://www.masonhq.com/docs/todo/access.html?id=375
Jonathan Swartz
2002-09-02 11:23:31 UTC
Permalink
I agree, these would be welcome changes.

We could also reduce confusion by making Params.pod the chief source for
information on parameters. Right now Params.pod contains just single line
descriptions; the full descriptions are in the respective object pages,
which most users would otherwise have no reason to visit. I'd like to move
the full descriptions into Params.pod, and change the rest of the manual
pages to link to Params.pod when referring to a parameter. What do you
think?

The dual name issue (comp_root / MasonCompRoot) is a huge mess. The problem
is that it makes parameters difficult to mention casually in the
documentation; seems like there's no choice but to mention both names
*everywhere* we mention a parameter.

Another thing we should strongly consider doing is look for MasonXYZ
parameters when an ApacheHandler is created manually (i.e. outside of the
configure-by-httpd case), and warn that said parameter has no effect. This
would aid the numerous handler.pl users that try to use a MasonXYZ parameter
in their httpd.conf.

Jon
Post by m***@asimov.net
New task #375: Improve Admin docs re: configuration
There is still confusion over the difference between
httpd.conf and handler.pl configuration.
- Distinguish between these two as basic (httpd.conf) and
advanced (handler.pl) configuration methods
- Completely separate the two in the docs, and don't refer
back and forth between them
- Put the basic config stuff early in the admin docs, and
the advanced stuff much later, not one after the other.
Basically, the advanced part should be near the end and
totally separate. When explaining how to do something like
decline image requests, we should not show both ways of
doing this in one section. Rather, we show how to do it via
httpd.conf in one place and via a handler.pl line
elsewhere.
Post by m***@asimov.net
- Explain what the handler.pl is actually doing (creating a
handler() sub to be used directly by mod_perl) in terms of
hooking together mod_perl & Mason. It is not a magic
incantation. Stress that people using this method should
understand how mod_perl works.
I think by doing these things we can greatly reduce
confusion.
Ken Williams
2002-09-03 00:31:03 UTC
Permalink
Post by Jonathan Swartz
The dual name issue (comp_root / MasonCompRoot) is a huge mess.
The problem
is that it makes parameters difficult to mention casually in the
documentation; seems like there's no choice but to mention both names
*everywhere* we mention a parameter.
The easy alternatives aren't particularly attractive if we want
to merge them:

my $ah = HTML::Mason::ApacheHandler->new(MasonCompRoot=>$comp_root,
MasonDataDir=>$data_dir,
MasonDeclineDirs=>0);

Not only is that redundant and ugly, it breaks perl style
guidelines, which were designed to make things easier for
non-native English speakers.

The other choice would be:

PerlSetVar comp_root /blah
PerlSetVar data_dir /foo
PerlSetVar decline_dirs 0

which pollutes the PerlSetVar namespace quite badly.

I think the only real alternative to this is to create a
top-level MasonSetVar/MasonAddVar configuration directive. This
would require custom C/XS development, something I'm not
necessarily looking forward to doing, and which I'm not keen on
pushing on users.

It would be better if there were a generic Apache::Directive
module or something to make this easier, and which would push
the responsibility away from Mason somewhat.

-Ken
Jonathan Swartz
2002-09-03 02:44:01 UTC
Permalink
Post by Ken Williams
I think the only real alternative to this is to create a
top-level MasonSetVar/MasonAddVar configuration directive. This
would require custom C/XS development, something I'm not
necessarily looking forward to doing, and which I'm not keen on
pushing on users.
Yup, this seems like the only reasonable option. Which is why this will have
to be solved with major redundancy in the docs, for now.
Post by Ken Williams
It would be better if there were a generic Apache::Directive
module or something to make this easier, and which would push
the responsibility away from Mason somewhat.
Yah, that would be nice.

Jon
Dave Rolsky
2002-09-03 14:54:04 UTC
Permalink
Post by Ken Williams
I think the only real alternative to this is to create a
top-level MasonSetVar/MasonAddVar configuration directive. This
would require custom C/XS development, something I'm not
necessarily looking forward to doing, and which I'm not keen on
pushing on users.
I was looking at doing this but with mod_perl 2.0 (hopefully) imminent,
I've been holding off on it because I'm hoping it will be easier with mp
2.0. Otherwise, it basically consists of writing a custom Apache C module
that hooks into Mason. It wouldn't actually be too hard because Matt
Sergeant did basically just this except for AxKit, and he's happy to let
us steal the code.
Post by Ken Williams
It would be better if there were a generic Apache::Directive
module or something to make this easier, and which would push
the responsibility away from Mason somewhat.
There is such a module (Apache::ModuleConfig, I believe), but I've never
been able to get it to do anything without segfaulting, which is why I was
looking into going the same route Matt did (I think he had similar
problems).


-dave

/*==================
www.urth.org
we await the New Sun
==================*/
Ken Williams
2002-09-03 21:53:02 UTC
Permalink
Post by Dave Rolsky
Post by Ken Williams
I think the only real alternative to this is to create a
top-level MasonSetVar/MasonAddVar configuration directive. This
would require custom C/XS development, something I'm not
necessarily looking forward to doing, and which I'm not keen on
pushing on users.
I was looking at doing this but with mod_perl 2.0 (hopefully) imminent,
I've been holding off on it because I'm hoping it will be
easier with mp
2.0. Otherwise, it basically consists of writing a custom
Apache C module
that hooks into Mason.
Oh, is that different with 2.0?
Post by Dave Rolsky
It wouldn't actually be too hard because Matt
Sergeant did basically just this except for AxKit, and he's
happy to let
us steal the code.
Yeah, I'm not concerned about how hard it would be to write, I'm
concerned about the extra burden on Mason users who don't
currently have to deal with any C compilation.

-Ken

Loading...