Mark Stosberg wrote: > On 2005-12-10, Michael Peters <[EMAIL PROTECTED]> wrote: > >>That's crazy talk! But seriously, I think we need to keep it as simple as >>possible (I want to avoid having a dispatch parser that implements anything >>close to a full grammar). All it needs to do is cover the majority of the >>cases >>at first. As more and more users try it out and discover real-world use-cases >>where it's not sufficient and then we can look at doing more. > > > My philosophy exactly. So let's take out all forms of pattern matching > out of the v1.0 design spec. We'll have several ideas to start from if > we want to extend it later. > > I've updated the spec on the wiki with the following refinements: > > - "requirements" is gone altogether. > - the "field => undef" syntax which as confusing is gone, replaced with > the ":field?/" syntax which was suggested.
How about "?field" instead. So a full pattern would be articles/list/:year/?month/?day instead of articles/list/:year/:month?/:day? Just 2 characters shorter. I don't know if that would be confusing since we're used to seeing the '?' after the optional token in regexes. > I happy with the outcome and have the some sense we are ready to move > from design and implementation. > > Final feedback? So do we want this to be in CGI::Application::Dispatch? Maybe there's someway to make it backwards compatible with what it currently does, since it's pretty simple. Or we could break backwards compatability and go for a 2.x generation and keep 1.x around... or have a separate module all together. Although "CGI::Application::Dispatch" is the perfect name for this new functionality. -- 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]
