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

["Viacheslav Sheveliov" <suppressed>]

"Mark Stosberg" <suppressed>
ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:
news:suppressed
> On 2006-02-07, Viacheslav Sheveliov
> <suppressed> wrote:
>>
>> "Component Auto-Discover"(c) can't be done by default due to nature
>> ofdispatch table storage method.
>
> Viacheslav,
>
> I believe this line could be described as providing "Component
> Auto-Discovery":
>
> ':app/:rm'  => {},
>
> It means that the first part of PATH_INFO will be used as the module name,
> and the
> the next part as the run mode.

And what to do with the rest bunch of parameters in PATH_INFO? How to do
more complicated things?
That, what I meant, when wrote: "Dispatcher in C::A philosophy can't know
more than module name and runmode."

IMO, to make dispatcher with real auto-discovery, one must provide
negoatiation/quering procedures ("asking" module).

Currently I'm trying to write C::A::D v2.* subclass with dispatch_args sub.
As extra parameter this subclass gets dir->module mapping table
(DirectoryMatch - like Apache directive).
It loads module, queries it to get detailed dispatch table and parse
parameters according to this table.

Not completely what I whant, but in this way it's compatible with existing
C::A::D.

What I whant is dispatcher, that follow the following flow:

1. Determining name of module according to PATH_INFO (dir->module mapping or
@PATH_INFO[0] translating to module name).
2. Creating instance of application ($module->new)
3. Fetching further details on dispatch table from application object
(feedback method).
4. Matching PATH_INFO against newly fetched dispatch table.
5. Runing application with parsed parameters.

The key feature is, that after stage #2 dispatcher has more freedom of
action,
using application methods. ( ex. $app->get_dispatch_table() )

Advantages:

1. Creating instance of application allows to do more complicated things to
determine dispatch table - get it from DB, flat files or something like that
(those methods should be done in application).
2. Dispatch table can be created on-the-fly - according to data structure in
DB or elswhere.
3. Installing/upgrading third-party modules is easier, cause installer
should not care much about dispatch table changes.
4. Dispatch table can be related to currently loaded module only, hence
less conflicting and smaller, and parsing of dispatch table will be faster.

Disadvantages:
1. It can be hard to implement 'uri_to' method, if dispatch table is not
stored in centralized store, or calculated during $app->new() process.











---------------------------------------------------------------------
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