Re: [cgiapp] Re: Re: feedback on CGI::Application::Dispatch

[Michael Peters <suppressed>]

Viacheslav Sheveliov wrote:
> "Michael Peters" <suppressed> ???????/???????? ? ???????? 

>>>Or we can determine dispatch table in module to be called. In dispatcher 
>>>we
>>>know module name and can retrieve dispatch table as 
>>>$Module::DISPATCH_TABLE
>>>or $Module->dispatch_table().
>>
>>You can do this by subclassing. In a current project of mine I have a 
>>separate
>>class for my dispatch table.
> 
> 
> Yes I can. I even can rewrite dispatcher from scratch. But I don't want to.
> My hands are getting tired from typing. May be I'm lazy... ;-)
> 
> Simply, I want new CGI::Application::Dispatch will do The Right Things
> and will be flexible enough to avoid subclassing in most cases.

In my option, it does "do The Right Thing". I'd welcome an example as to how it
doesn't.

> That's what I propose. More detailed.
> 
> In our stuartup script we will define which module for which path to use.
> No runmode or parameter defined.
> ===============================
> CGI::Application::Dispatch->dispatch(
>     PREFIX => 'MyCgiApp::Modules',
>     TABLE   => {
>         'default' => 'Default', # only path-module relation
>         'admin'   => 'Admin',
>         'user'    => 'User',
>         'etc.' => 'Etc',
>     }
> );
> ===============================
> 
> In C::A module:
> 
> ===============================
> package MyCGIApp::Module;
> use base 'CGI::Application';
> 
> use constant DISPATCH_TABLE => {
>   ':app/view/:cat?/:id?/:type?' => {},
> };
> 
> # or
> 
> sub DISPATCH_TABLE {
>  return {
>   ':app/view/:cat?/:id?/:type?' => {},
>  };
> }

So you would split the dispatch table into 2 parts. The first to obtain the
module name and the second to get the runmode and everything else? I can
honestly say that I think the 1 table approach is much cleaner.

> So we have our code & dispatch table scoped in one module. Separate for each 
> module. Almost as in Cat... another nice cgiapp framework.

Well, it's not in 1 module, it's in 1 module and an instance script (or config
file). Plus by having your dispatch rules scattered across your application, it
could become a real pain to see how URLs are routed.

IMO, the dispatching of URL to module/run mode should not be *inside* of your
application modules. It should be outside. And especially not half-in and half-out.

> It allow us to install/uninstall modules very easily. Almost like another 
> framework does.
> 
> It's "Compontent Auto-Discovery" and with Dispatcher without 'table' arg 
> it's full "Compontent Auto-Discovery" (yes, unsecure). Almost like... Well, 
> you guess...

I think you're still missing what Dispatch does by default. It will do full
"Component Auto-Discover" by default. It's only where you want to do something
more application specific can your dispatch rules become more complicated and
become more tied to your modules.

-- 
Michael Peters
Developer
Plus Three, LP


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed