Rob Mills wrote:
> I'm really liking CAP::Dispatch and have been trying to customise some
> URL's with CAP::Dispatch::Regexp. Question is how can I include an
> actual query string in the url?
Honestly I don't use Dispatch::Regexp. It was more of a proof of concept of how
to subclass Dispatch than anything else.
> For example: www.myapp.com/search/?query=test
>
> qr|/search/\?query=(.*)/?| => {app => 'Search', names => ['query']}
>
> I was trying to escape the query string by "\?" but the dispatch table
> can't recognise it.
On a more general note about Dispatch and query strings... don't. I'll get to
that more below.
> I have another more general question. As CAP::Dispatch is matching
> variables the sytax changes later in your Apps. ie: to get access to a
> variable you would use:
>
> my $variable= $self->param('variable');
>
> I'm running in a plain CGI environment and before I would have
> collected the variable with CGI ie:
> my $q = $self->query();
> my $variable= $q->param('variable');
>
> Does this mean CGI.pm isn't being used anymore to parse the variable,
> and is it still necessary to untaint the variable?
Application dispatching is different than parameter passing. By default
application dispatching using C::A is a mixture of the url (script) and a query
parameter. C::A::Dispatch's aim is to make it all contained in the URL. This
doesn't necessarily replace the query string. Although I find that the more I
use Dispatch, the less need I see for having a query string.
But the difference still exists. Take the following dispatch rule and url
(ignore the "rightness" of this example with respect to GET vs POST and
idempotency):
':app/:rm/:id'
/admin_user/update/23?name=Michael
The 'id' parameter is not part of the query string, so CGI.pm knows nothing
about it, only Dispatch does. So 'id' is accessed as $self->param('id') and
'name' is accessed as $self->query->param('name').
Does that clear anything up?
I have thought about adding a put-params-into-query (still need a good name)
argument to dispatch that would make 'id' accessible as
$self->query->param('id') as well. Then in your application, the following urls
could work exactly the same way (this would help with application migration,
etc):
/admin_user/update/23?name=Michael
/admin_user?rm=update&id=23&name=Michael
--
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]
