On 12/12/05, Rob Kinyon <[EMAIL PROTECTED]> wrote: > > Here is my scenario to how the dispatcher could work. Treat every path > > as $app/$rm/@params. The dispatcher loads the $app and is defined > > executes the run mode. The dispatcher would stash the remaining > > elements (@params) for the run mode to optionally do something with. > > The run mode would then assign, validate and handle errors. > > > > To me this is a lot more straight forward and lightweight then > > creating an entire syntax to perform these functions IF you need them. > > A few things you don't seem to be considering: > * I don't want my runmode name in my URL. > - I want to leave refactoring as a possibility in the future > - I want to hide information from potential attackers > * I want to provide human-generatable URLs that map back to my > runmodes. For example, /report/<format>/<report_name>?a=1&b=2 would > map to My::App::Report::run() and the format doesn't get used until > the print() function which is defined in My::App::Base. How does your > system handle this? > * I want to provide /reports?/<format> which maps to > My::App::Report::display()
The addon to what you are commenting on is if a run mode was defined in the dispatch table the run mode is NOT extracted from the URL. I think we moved passed this suggestion though. > Yeah - TABLE needs to be an array, not a hash. That was something that was carried over from how CGI::Application::Dispatch currently operates. I agree that it will have to change to an array reference to work as we are discussing. <tim/> -- Timothy Appnel http://www.timaoutloud.org/ --------------------------------------------------------------------- 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]
