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

[Mark Stosberg <suppressed>]

Viacheslav --

On 2006-02-10, Viacheslav Sheveliov <suppressed> wrote:
>
> 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.

Thanks for the explanation. It does sound interesting. Here's a "use
case", which I believe must be implemented like this.

Drupal [1] has a feature called "URL aliases". For any given resource,
an administrator can give it an "alias" URL uses a web based interface.
So you might alias:

  node/28245

To: 

 about_us/staff

Then, these alias links are used throughout the application in
preference to the original version. (So they are used for linking as
well as dispatching). 

To implement this, I imagine a trip to the database is made as part of
the dispatching. 

Clearly it requires the dispatcher and the application framework to be
more closely coupled.

So I look forward to seeing what you come up with. I think it would be
nice to keep a simpler dispatcher like the one we have now, and also
have a more integrated one, like the concept you have in mind. If this
can be done by sub-classes the current dispatcher as you suggest-- that
would be ideal.

    Mark

1. http://www.drupal.org

I use URL aliases throughout: http://www.richmondcomputes.org/ if you
want to see them in action. I love the feature, and it probably helps
with some search engine rankings, too, not to mention more pleasant
bookmarks.




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