> > On Thu, 1 Jan 2009, Mark Hedges wrote: Talking to myself
> > again. I think I can make it work either way.
> > Apache2::Controller won't use Apache2::Request as a
> > base, but it will still instantiate the Apache2::Request
> > object and put it in $self->{r}. Then if you want to
> > use Apac
On Fri, 2 Jan 2009, David Ihnen wrote:
> Mark Hedges wrote:
> > I wonder how easy it would be to add controller
> > subroutine attributes for which ones are allowed or not,
> > ala Catalyst, instead of the controller having to
> > provide an 'allowed_methods' method.
> >
>
> It would have been n
Mark Hedges wrote:
I wonder how easy it would be to add controller subroutine
attributes for which ones are allowed or not, ala Catalyst,
instead of the controller having to provide an
'allowed_methods' method.
Sounds like something JSON::RPC::Server::CGI does with :private and
:public modifi
Mark Hedges wrote:
On Thu, 1 Jan 2009, Mark Hedges wrote:
Regarding your comment about inheritance vs. references -
something I hadn't thought much about. A) I need to prefix
all my internal method names with 'a2c_' to stay out of
the controller namespace. B) You can't have any controller
s
On Thu, 1 Jan 2009, Mark Hedges wrote:
>
> Regarding your comment about inheritance vs. references -
> something I hadn't thought much about. A) I need to prefix
> all my internal method names with 'a2c_' to stay out of
> the controller namespace. B) You can't have any controller
> subroutines
> > - a lot of times people use references to other
> > structures when they should subclass... these references
> > function only to re-map arguments to other modules,
> > which is ridiculous.
>
>
> Careful on the should. It can seem extra and possibly
> confusing but isn't always. Delegation is
