Dave,
I agree. Implicit variable substitution in problematic at best and makes
the code more complicated and error prone.
- James
David Primmer wrote:
I just chatted with Ben Bangert, who ported Routes form Ruby to Rails
and he says that urlFor in those libs just works like a plain ol'
function and ignores the current request. When using a named route,
you must 'fill in the blanks' or else it doesn't return anything.
There is no magical pulling request variables in during expansion.
This is a pretty easily understood behavior and I'd recommend we
change it before it's too late. Once people start using routes with
the implicit token substitution, their code will break if we want to
make it explicit.
Is this what James was saying we need to fix?
davep
On Fri, May 16, 2008 at 5:20 AM, David Calavera
<[EMAIL PROTECTED]> wrote:
this patch solves the query params bug but I continue thinking of the best
behavior for the "urlFor" method:
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12396195
On Fri, May 16, 2008 at 10:41 AM, David Calavera <[EMAIL PROTECTED]>
wrote:
David, what abdera version are you using? can you include one of your test
cases? I'm trying to fix it but I don't have the same results.
On Fri, May 16, 2008 at 12:12 AM, David Primmer <[EMAIL PROTECTED]>
wrote:
I just tested another use case, for the situation where I'm sending in
a map with a nulled out param 'id=null' and in this case, I have send
a request with query params '/feed/1?format=atom' and in this case,
when it builds the link, it actually adds '?id=' onto the end of the
url that is created so '/feed/?id='. So this seems to get complicated
if there are query params already in the request context.
davep
On Thu, May 15, 2008 at 2:10 PM, David Primmer <[EMAIL PROTECTED]>
wrote:
I was thinking that if you passed in null, the urlFor would not
replace any of your tokens. But on the other hand, this behavior lets
you get a url by just sending in one arg: the route name.
I'm not sure off the top of my head how the Ruby and Python Routes
libs handle this. It is hard to know what users would expect but at a
minimum it should be in a code comment. As it is, if I have two tokens
in my route and I only one one of them to be replaced with the request
var, i can get this by sending in a map with only one of the params
set to null for the one i don't want and the other one will magically
get resolved. Seems a little to implicit to me.
davep
On Thu, May 15, 2008 at 2:02 PM, David Calavera
<[EMAIL PROTECTED]> wrote:
Hi David, what do you think could be the expected behavior?
On Thu, May 15, 2008 at 5:09 PM, James M Snell <[EMAIL PROTECTED]>
wrote:
Ok, we need to fix that. Want to open a jira issue?
- James
David Primmer wrote:
I need to correct myself here. After investigating the code more, I
was able to get the result I wanted by sending in a map with id=null
as params instead of sending in a null param arg. The code only pulls
in values from the request if they're not explicitly included in the
params map in urlFor. I still don't know if this is the desired
behavior. It's certainly not what I expected.
davep
On Wed, May 14, 2008 at 11:21 AM, David Primmer <
[EMAIL PROTECTED]>
wrote:
I'm trying to implement getHref in an adapter, which returns the url
for the collection. I'm also using RouteManager and it's urlfor
for (String var : route.getVariables()) {
Object value = context.getTarget().getParameter(var);
if (!map.containsKey(var) && value != null) {
map.put(var, value);
}
}
say my route is /feed/:id
and my request is /feed/1
if i'm doing urlFor("myroute", null), hoping that it produces /feed/
as a url, but instead, the code above pulls the id out of the
request
context and fills in those params, giving me a url of /feed/1. I
don't
understand why it would do this and it limits the use of urlFor for
generating collection urls.
davep
--
David Calavera
http://www.thinkincode.net
--
David Calavera
http://www.thinkincode.net
--
David Calavera
http://www.thinkincode.net
