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

["Viacheslav Sheveliov" <suppressed>]

"Michael Peters" <suppressed> ???????/???????? ? ???????? 
?????????: news:suppressed
>
>
> Viacheslav Sheveliov wrote:
>> "Michael Peters" <suppressed> ???????/???????? ? ????????
...
>> 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.

Nothing personal. Your module is quite new and just developing. Very much 
things to implement.
Current development state brings less flexibility and automation ability. 
It's my opinion only .

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

It's not quite 2-table approach. First one is like PerlHandler directive for 
different paths.
Dispatcher in C::A philosophy can't know more than module name and runmode. 
Rest bunch of parameters rely on module creators fantasy.

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

I meant Catalyst, where dispathing done with sub attributes. I don't 
remember exactly, seems there are at least 4 ways - regexp,path something 
else.
It's really - dispatch table spread over all module. IMO it's better to keep 
it in single variable, constant or sub. It's point, where package interface 
is described. Dispather queries package to determine it's capabilities.

Separating dispatch table from package, is more pain, I think. Dispatch 
table is very tightly bunded with package structure, logic and runmode 
names.
Dispatch table can be created dynamically on C::A init stage, after fetching 
some data. How can we do it with hardcoded dispatch table?
So there are no reasons to divide package and dispatch table.

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

Why. My reasons see higher. Quite common way - from less specific to more 
specific things.

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

Well, let me to guess, please .
It translates PATH_INFO according to given set of rules (dispatch table and 
some other params) into equivalent set of CGI parameters, figure out which 
module to load, figure out which runmode to invoke, load them, invoke it, 
pass calculated parameters. As a result, it provides centralized routine to 
analyze PATH_INFO.

Great thing. But IMO "centralized routine" is really great thing, but 
hardcoded "given set of rules" - is not very. And that's why I think so:

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

"Component Auto-Discover"(c) can't be done by default due to nature 
ofdispatch table storage method. One need to write dispatch table in 
instance script  or config file to "explain" rules for dispatcher. Making 
more complicated things on dispatching stage is awkward, cause we are faced 
with chicken-and-egg -like problem. Instance script or dispatcher becomes 
applications by themselves, although they are bootstrappers only. I prefer 
to load C::A - derived modules first and let them to do really 
application-specific things.

Well, Michael. It seems, you will stand with your opinion.
Anyway, I sincerely wish you luck. 




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