"Michael Peters" <[EMAIL PROTECTED]> ???????/???????? ? ???????? ?????????: news:[EMAIL PROTECTED] > > > Viacheslav Sheveliov wrote: >> "Michael Peters" <[EMAIL PROTECTED]> ???????/???????? ? ???????? ... >> 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/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
