On 2005-12-15, Michael Peters <[EMAIL PROTECTED]> wrote:
>
>> 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.
Works for me.
>
>> 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(.
Great.
>> 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.
I recently installed svk on my laptop play with as well. I still prefer
darcs, but I'm willing to be cooperative. (My first impression of svk
was that it took 4 steps to do what "darcs get" does in one.)
> 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.
That's a workable solution, although I think it also works to have the
other part be in the standard C::A::P name space, and have the
dependency be documented. I don't think of URL building as a part
of dispatching, just inter-related.
> 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.
I would follow the same conventions we recommend for plugin namespaces:
In order to avoid namespace conflicts within a CGI::Application object, plugin
developers are recommended to use a unique prefix, such as the name of plugin
package, when storing information. For instance:
$app->{__PARAM} = 'foo'; # BAD! Could conflict.
$app->{'MyPlugin::Module::__PARAM'} = 'foo'; # Good.
$app->{'MyPlugin::Module'}{__PARAM} = 'foo'; # Good.
Yes, it means accessing the objects internals, but that's an invitation we
extend to all the current plugin authors anyway.
>> 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.
Sounds good.
Mark
---------------------------------------------------------------------
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]
