Mark Stosberg wrote:
> Michael,
>
> First, thanks for picking up the torch of implementation on this.
No problem. I'm just trying to finalize the API and haven't actually started the
implementation yet, so you might want to wait to thank me :)
>>:app - will be converted into the module name using the same current rules. So
>> module_name
>>will become
>> Module::Name
>>I'm also thinking about adding the rule that
>> module-name
>>would become
>> ModuleName
>
>
> As long as no one has underscores in their module names, we're safe.
> That could be worked around if it comes up.
That's a pretty rare case, but right now, the user can just override
get_module_name(). I don't plan on taking this method away.
>>I'm pretty sure at this point I can keep all of the old stuff functioning the
>>same if the old interface is used. But I would encourage users to use the new
>>API to accomplish the same goals.
>
>
> That works for me. I haven't yet started using the module.
>
> One detail you didn't cover in your write was named params:
>
> ':app/:rm/:id'
Right, sorry about that.
:app and :rm would be reserved key names, but anything else would simply
populate $self->param(.
> I think that's Rails default dispatching, and is a pattern I like.
>
> Adding named params for me is the most significant functionality
> difference over what's there now.
>
> I could help wit the code for it, if you'd like.
Right now I have this module in a svn repo, but I've been recently intrigued by
svk, so I wouldn't mind trying it out with others to see how it works with this.
> One detail to keep in mind for implementation is that functions like
> 'uri_for' and 'link_to' will be accessing the same internal data
> structure. I suppose all that means for now is that '@TABLE' be
> accessible somewhere as part of the CGI::App object.
Right, another thing I forgot to mention. CAD would probably come with an
additional module to be used as a plugin for you C::A based modules as well if
you want uri_for() and link_to().
I'm thinking about naming this module C::A::Dispatch::Plugin. This would put it
under the CAD namespace since it's part of the same distro, but would mean it
doesn't follow the C::A::Plugin namespace that other plugins go in. Will this be
a problem? I wouldn't think so, since it's not a plugin that can be used on it's
own, but only if CAD is sending the request to app.
This will mean that CAD will have to pass the dispatch table to the C::A object
so that plugin can get to it. So maybe $self->param('dispatch_table') ? I just
want to make sure that I don't clobber something someone's app already has.
> When we get to implementing 'uri_for', we may possibly want to create an
> alternate representation of it that is easier to do reverse lookups on.
Yeah, I think this table should be optimized for reverse lookups (if CAD::Plugin
is loaded) and also changed into a some sort of compiled/cached version for
normal dispatches to make them faster under persistent environments (probably
with the option to turn this on/off, maybe named 'cache'?). There's no reason
the table needs to be parsed on each request if that can be avoided.
--
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]
