Cees Hek wrote: > On 1/26/06, Michael Peters <[EMAIL PROTECTED]> wrote: > >>Please feel free to use the public svn repo. Since this plugin would be >>heavily >>dependent on C::A::D, I think it should be bundled together. >> >>svn://svn.cromedome.net/CGI-Application-Dispatch > > > Hi Michael, > > I'll drop it in there as soon as I get a chance. Not sure if I need > an account to get write access, but I'll resolve that with Cromedome.
When he set it up, he said he'd give anyone who asked write access. > I agree that it should be distributed with the Dispatch module, > although I wonder if it would be useful to also have a standard URL > generating plugin that works exactly the same way for non-Dispatch > users? Then the two can be drop in replacements for each other, > making it easier to switch back and forth. The Dispatch URL generator > could probably even use the standard URL generator, since they would > work in a very similar fashion, with the Dispatch version just > handling some extra path_info stuff. Now I'm wondering whether it should be distributed with Dispatch or not. If, as you said, it could be useful to non-Dispatch users then maybe it should be it's own separate distribution that just behaves slightly differently when Dispatch is also used (just look for the dispatch table). >>Another thing missing from Dispatch is multiple "versions" of the dispatch >>table. I see needing at least the following: >> >> + a cached reverse look up version to more easily create URLs (no need to >> create this multiple times if we don't have to). >> + a cached version of the regex mapping (each rule becomes a regex that >> Dispatch uses internally. No need to create this for each rule tried on >> each >> dispatch attempt). >> + and a cached version of URL-to-Rule mappings. If we've already seen a URL, >> why should we run it through the table again? We already know which rule >> matched. > > > All of this caching stuff can easily be added after we have a stable > working model. My aim will be to get everything working properly > first. Yeah, that was my thought too. I might even release it as 2.0 before all the caching stuff is done. As long as the API doesn't change, most of that stuff is under the hood anyway. > On that note, I did need to add one line to the Dispatch code. > Currently, the code throws away the dispatch table after the call to > 'dispatch'. I just stored all the config args in $self->param for now > so that the URL generation code can get access to it. It probably > makes sense to normalize that data to ease URL generation like you > mention above. Yeah, I thought you'd need to add something to pass the table into the application object. -- Michael Peters Developer Plus Three, LP --------------------------------------------------------------------- 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]
