Zach Welch
2006-05-21 15:24:02 UTC
Howdy,
I suppose it's too late for 1.33, but I posted this patch and never saw
any reply to it. I am using it in (light) production, so I would at
least like to hear a reply as to why it was not considered. I suppose
"because you posted it to the user's list" is valid, too.
Cheers,
Zach
-------- Original Message --------
Subject: [Mason] patch for task 294: support exec/subexec("comp:method")
Date: Mon, 03 Apr 2006 19:55:43 -0700
From: Zach Welch <zach-***@splitstring.com>
Organization: The Split String Experience
To: mason-***@lists.sourceforge.net
Hi all,
I've been using Mason for five years or so, primarily using it with
mod_perl to develop dynamic websites. Many thanks to all that continue
to contribute to its success; I look forward to the continued support
and growth that the community can bring. That said, the patch mentioned
in the subject line itself deserves a far better introduction.
For a couple of days last week, I time working on the problem of making
the URLs for a web site to be compliant with REST principles (as
outlined in O'Reilly's "Web Services with Perl"). As a result of this
effort, I have developed a series of independent "areas" that contain
dhandlers for handling any immediately subsequent variable portions of
the request path.
After a dhandler consumes its parameters (present in the first part(s)
of its dhandler_arg path), it uses a $m->subexec call to trigger another
"area request", first building up menus and other output through its
chain of autohandlers. This process can be repeated by additional
dhandler/subexec requests, as necessary. Using this structure, dynamic
paths that follow REST principles can be processed sanely using Mason.
At first glance, these changes seemed to be a major win for the site,
but the tricky bit came when I began to update the mechanisms for
retrieving the page title, required authorization levels, and other
dynamic attribute data from these deeply nested components. After some
hacking, I realized that the ideal solution was to add support for
"comp:method" syntax to the core request subexec code path.
Specifically, the subrequest needed to establish proper inheritance for
the requested component (possibly after locating a dhandler), locate the
correct component method (which may have been inherited), and then call
it directly - without any autohandlers. [As often turns out to be the
case, defining my actual problems and the required solutions took orders
of magnitude longer than implementing the proper improvements.]
To start, I made a couple of changes to the initialization method in
HTML::Mason::Request, establishing the proper request_comp for a method
(if specified). Later in the same module, the exec method disables the
wrapping chain for direct requests on subcomponents. In this regard, a
exec/subexec of a method behaves very similarly to a normal "comp" call
(which conforms to my personal intuitive expectations). Together, this
extended the system to allow the direct call of methods located in a
subrequest dhandler (with proper setup of its dhandler_arg path).
After finishing my work, I found task 294 on the MasonHQ wiki, and I
think these specific changes mostly satisfy its (now somewhat dated)
requirements. Since that task has been left open, I assume that this
patch will be welcomed into the main tree, so I am posting it here.
(Actually, I remember seeing that issue a couple of years ago and
somehow worked around the limitation; this time, I put my foot down.)
The changes are as simple and clean as I could make them; for example, I
didn't properly reindent the wrapping chain code block, in order to keep
the patch short and clear. The existing test suite does not show any
obvious regressions, but I have not looked at extending it properly to
cover this new capability. Because of the new permutations of support
that it brings to the exec call, this may not be as easy as the patch.
In theory, this should have broken a previously existing test built to
cover requests which directly specify a subcomponent object; the second
half of my changes break the inheritance chain for such calls. If it
shouldn't have changed in this particular way, the different conditions
could be identified and the behavior regressed, but that could result in
two different outputs for the same subcomponent (depending on whether
the component was called by object or by path). Of course, there is
already an established way way to disable the wrapping chain, but I
don't think it currently applies to subcomponents (for good reason)....
To be fully backward compatible while retaining all of the new features,
I suppose that the proper solution would be to add support to methods to
respect the flags block (and its 'inherit' attribute); however, this
kind of change would go far beyond my current comfort level for hacking
on the Mason code. Since this seems to be the most idiomatic solution,
I would be interested to hear the pros and cons of this approach from
the experts. Personally, the thought of the possible class of site bugs
this could create makes my brain hurt.
Since this feature has significantly helped my site, I'd be interested
in seeing what it takes to have this patch included in a future release.
For obvious reasons, I'm reluctant to update my production site with a
patched version of a core module like this, so I need to start thinking
about my release schedule versus Mason's (versus deploying the patch).
I look forward to any response.
Cheers,
Zach Welch
Superlucidity Services
I suppose it's too late for 1.33, but I posted this patch and never saw
any reply to it. I am using it in (light) production, so I would at
least like to hear a reply as to why it was not considered. I suppose
"because you posted it to the user's list" is valid, too.
Cheers,
Zach
-------- Original Message --------
Subject: [Mason] patch for task 294: support exec/subexec("comp:method")
Date: Mon, 03 Apr 2006 19:55:43 -0700
From: Zach Welch <zach-***@splitstring.com>
Organization: The Split String Experience
To: mason-***@lists.sourceforge.net
Hi all,
I've been using Mason for five years or so, primarily using it with
mod_perl to develop dynamic websites. Many thanks to all that continue
to contribute to its success; I look forward to the continued support
and growth that the community can bring. That said, the patch mentioned
in the subject line itself deserves a far better introduction.
For a couple of days last week, I time working on the problem of making
the URLs for a web site to be compliant with REST principles (as
outlined in O'Reilly's "Web Services with Perl"). As a result of this
effort, I have developed a series of independent "areas" that contain
dhandlers for handling any immediately subsequent variable portions of
the request path.
After a dhandler consumes its parameters (present in the first part(s)
of its dhandler_arg path), it uses a $m->subexec call to trigger another
"area request", first building up menus and other output through its
chain of autohandlers. This process can be repeated by additional
dhandler/subexec requests, as necessary. Using this structure, dynamic
paths that follow REST principles can be processed sanely using Mason.
At first glance, these changes seemed to be a major win for the site,
but the tricky bit came when I began to update the mechanisms for
retrieving the page title, required authorization levels, and other
dynamic attribute data from these deeply nested components. After some
hacking, I realized that the ideal solution was to add support for
"comp:method" syntax to the core request subexec code path.
Specifically, the subrequest needed to establish proper inheritance for
the requested component (possibly after locating a dhandler), locate the
correct component method (which may have been inherited), and then call
it directly - without any autohandlers. [As often turns out to be the
case, defining my actual problems and the required solutions took orders
of magnitude longer than implementing the proper improvements.]
To start, I made a couple of changes to the initialization method in
HTML::Mason::Request, establishing the proper request_comp for a method
(if specified). Later in the same module, the exec method disables the
wrapping chain for direct requests on subcomponents. In this regard, a
exec/subexec of a method behaves very similarly to a normal "comp" call
(which conforms to my personal intuitive expectations). Together, this
extended the system to allow the direct call of methods located in a
subrequest dhandler (with proper setup of its dhandler_arg path).
After finishing my work, I found task 294 on the MasonHQ wiki, and I
think these specific changes mostly satisfy its (now somewhat dated)
requirements. Since that task has been left open, I assume that this
patch will be welcomed into the main tree, so I am posting it here.
(Actually, I remember seeing that issue a couple of years ago and
somehow worked around the limitation; this time, I put my foot down.)
The changes are as simple and clean as I could make them; for example, I
didn't properly reindent the wrapping chain code block, in order to keep
the patch short and clear. The existing test suite does not show any
obvious regressions, but I have not looked at extending it properly to
cover this new capability. Because of the new permutations of support
that it brings to the exec call, this may not be as easy as the patch.
In theory, this should have broken a previously existing test built to
cover requests which directly specify a subcomponent object; the second
half of my changes break the inheritance chain for such calls. If it
shouldn't have changed in this particular way, the different conditions
could be identified and the behavior regressed, but that could result in
two different outputs for the same subcomponent (depending on whether
the component was called by object or by path). Of course, there is
already an established way way to disable the wrapping chain, but I
don't think it currently applies to subcomponents (for good reason)....
To be fully backward compatible while retaining all of the new features,
I suppose that the proper solution would be to add support to methods to
respect the flags block (and its 'inherit' attribute); however, this
kind of change would go far beyond my current comfort level for hacking
on the Mason code. Since this seems to be the most idiomatic solution,
I would be interested to hear the pros and cons of this approach from
the experts. Personally, the thought of the possible class of site bugs
this could create makes my brain hurt.
Since this feature has significantly helped my site, I'd be interested
in seeing what it takes to have this patch included in a future release.
For obvious reasons, I'm reluctant to update my production site with a
patched version of a core module like this, so I need to start thinking
about my release schedule versus Mason's (versus deploying the patch).
I look forward to any response.
Cheers,
Zach Welch
Superlucidity Services