> -----Original Message-----
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 31, 2000 10:35 AM
> To: Geoffrey Young
> Cc: [EMAIL PROTECTED]
> Subject: RE: [ANNOUNCE] Apache::Dispatch
>
>
> On Mon, 31 Jul 2000, Geoffrey Young wrote:
>
> >
> > I'll remove Foolish (the name was a dead givaway that it
> would be gone soon
> > :), but I think that Brave would greatly enhance the
> development process by
> > allowing you to test handlers without having to stop and
> start the server to
> > add location tags to reload the module. I'll be sure to
> add documentation
> > to that extent.
>
> OK, I think the documentation then should suggest (obviously not
> enforce) that this is useful primarily for testing new
> handlers, not as a
> way to build your application due to the inherent security issues.
ok - I might even change the name to Development or something like that...
>
> > > [basically the way I saw it working was you specified a
> > > namespace prefix
> > > for each <Location>, so you'd have DispatchPrefix MyApp, and
> > > http://server/location/Foo would call MyApp::Foo->handler,
> > > assuming that
> > > /location is the entry in <Location> for the above config line]
> >
> > I did re-read the archives and I saw you mention this. I
> think I may add an
> > additional directive
> > DispatchClass that only works from a <Location> tag that
> does just that. It
> > would be in addition to the existing API and would allow
> only one class per
> > location. I'll also add documentation suggesting that it exists for
> > security reasons, so using it like
> > <Location /Foo>
> > DispatchClass Foo
> >
> > defeats the purpose :)
>
> Of course, but thats not likely to happen too often :)
>
> I don't think DispatchClass is a great name though. It
> implies that you'll
> always be calling methods in that class. Prefix sounded better to
> me... But you're the boss :)
Because you won't always be calling Foo, but also Foo::Bar::Blarg?
That makes sense...
>
> > >
> > > > But maybe we're missing eachother on this? Or you
> > > > have something in mind that I don't? I'll admit, I'm
> > > > far from a web security expert, and this does need to
> > > > be quite secure to be a benefit to anyone...
> > > >
> > > > as for method restrictions, I can't remember if it was
> > > > talked about - I'll have to go over the archives
> > > > again.
> > > > however, having to specify Foo::Bar->method for each
> > > > method you want to use seems like overkill to me,
> > > > almost as limiting as having to add all those location
> > > > tags.
> > >
> > > Thats not what I meant. If you just force a method prefix,
> > > the same way I
> > > suggest above using a namespace prefix, and default to cmd_
> > > or something,
> > > then its much easier to design a complex app in a class
> where you have
> > > web-space functions (those beginning with cmd_) and non-web space
> > > functions (i.e. private functions that implement parts of your
> > > application, where you don't want people directly calling the
> > > method). Without that, it would be trivial for someone to
> > > call new() or
> > > something, which might not be intended (and might have
> side effects).
> >
> > right, now I remember. I still think that implying
> handler() should be an
> > option, however, since some people do write one handler per
> module for
> > mod_perl. How about changing DispatchMethod Subroutine to
> Prefix and having
> > that prefix all method calls with dispatch_ , which seems a
> bit more self
> > documenting?
>
> Sure. And have http://server/location/Foo/ call
> MyApp::Foo->dispatch_index() (or if you want to be microsoftian,
> dispatch_default() ;-)
wow - maybe later. right now I have it declining directory requests so that
mod_dir can handle them. that's a really good idea, though - I'll see what
I can do with it...
--Geoff
>
> --
> <Matt/>
>
> Fastnet Software Ltd. High Performance Web Specialists
> Providing mod_perl, XML, Sybase and Oracle solutions
> Email for training and consultancy availability.
> http://sergeant.org | AxKit: http://axkit.org
>
