#444: Use matched incoming parameters for same route generation on a hierarchial
basis
---------------------+------------------------------------------------------
Reporter: david | Owner: dominik
Type: task | Status: new
Priority: highest | Milestone: 0.11
Component: routing | Version: 0.11.0RC2
Severity: blocker | Resolution:
Keywords: |
---------------------+------------------------------------------------------
Comment (by david):
We had a discussion on IRC this morning:
10:38 * Wombert slaps v-dogg around with a large channel
topic[[BR]]10:38 < Wombert> slaps RossC0 around with a large channel
topic[[BR]]10:39 < Wombert> slaps MrJeep around with a large channel
topic[[BR]]10:39 * Wombert slaps _cheerios around with a large channel
topic[[BR]]10:39 * Wombert slaps digitarald around with a large channel
topic[[BR]]10:39 < _cheerios> *ouch*[[BR]]10:40 < ttj> Wombert: You going
to do that to each of us? ;-)[[BR]]10:40 < Wombert> TO YOU TOO!
[[BR]]10:41 -!- MikeSeth_ is now known as MikeSeth[[BR]]10:42 < v-dogg>
Wombert: hey! no slapping! [[BR]]10:45 < RossC0> cheeky[[BR]]10:46 <
v-dogg> Wombert: I read the ticket and have no strong opinion on the
subject[[BR]]10:46 < RossC0> OT: any ideas how to set up a port proxy on a
linux box - so I can have multiple xdebug remote hosts?[[BR]]10:46 <
v-dogg> just go with the less ambiguous and less hacky way[[BR]]10:52 *
MikeSeth adds the new base classes to his now aging application[[BR]]10:53
< _cheerios> the 'null' solution sounds good[[BR]]10:57 < RossC0> which
ticket?[[BR]]10:58 < v-dogg> topic :)[[BR]]10:59 < RossC0> ah reading
that... :)[[BR]]11:02 < ttj> No strong opinions either.[[BR]]11:04 <
RossC0> I have opinions! [[BR]]11:05 < v-dogg> yeah, but they are
wrong[[BR]]11:05 < v-dogg> "I have opinions, if you don't like them, I
have others"[[BR]]11:06 < ttj> v-dogg: Apologize to Groucho! [[BR]]11:06 <
RossC0> oww - moody v-doog[[BR]]11:06 < RossC0> *v-dogg :p[[BR]]11:07 <
v-dogg> :)[[BR]]11:08 < RossC0> I think our routes are better than Rails -
which has a mess of code for routing[[BR]]11:12 < RossC0> I think the
right hand side null, solution works. However, before #434 would
$ro->gen('profile'); produce:[[BR]]11:13 < RossC0>
/profile/woodstock/[[BR]]11:13 < v-dogg> Wombert: (or anybody) when I
setRedirect or forward in a view, what filters get executed
afterwards?[[BR]]11:14 < digitarald> ok ... got slapped ... which
ticket?[[BR]]11:15 < digitarald> #444?[[BR]]11:15 < splatch`_> #666
[[BR]]11:15 < splatch`_> :>[[BR]]11:15 -!- splatch`_ is now known as
splatch`[[BR]]11:15 < splatch`> oi! [[BR]]11:15 < v-dogg> The End will
come after #666[[BR]]11:16 < digitarald> i like it #444 ...[[BR]]11:16 <
digitarald> this year its moved to 7.7.2007[[BR]]11:17 < RossC0>
org.agavi.controller.forwards. ?[[BR]]11:17 < RossC0> erm - filters
nm[[BR]]11:19 * RossC0 curses himself and his wrong opinions[[BR]]11:19 <
v-dogg> :D[[BR]]11:20 < v-dogg> don't feel bad[[BR]]11:20 < v-dogg> you
don't get to choose whether or not you become Brittish[[BR]]11:21 -!-
digitarald [EMAIL PROTECTED] has quit ["... is gone
... www.digitarald.de ... but he is coming back!"][[BR]]11:21 * RossC0
slaps v-dogg with a finnish salted herring[[BR]]11:28 < v-dogg> I'm
hungry[[BR]]11:32 < ttj> Wombert: Is AgaviExecutionContainer supposed to
be able to return the response through getResponse()?[[BR]]11:33 < ttj> Or
has this issue been resolved already?[[BR]]11:33 -!- Arme[N]
[EMAIL PROTECTED]/armen/x-394205] has joined #agavi[[BR]]11:34 -!-
Arme[N] is now known as Arme[0][[BR]]11:35 < ttj> Hmm...[[BR]]11:36 -!-
Xylakant [EMAIL PROTECTED] has joined
#agavi[[BR]]11:36 < Xylakant> hi[[BR]]11:36 < ttj> AgaviController has the
global response and ExecutionContainer only the one from the currently
executed action? And I should tap into response through the controller,
right?[[BR]]11:36 < ttj> If I were to want to setRedirect()s.[[BR]]11:37 <
ttj> No wait, I'm messed up.[[BR]]11:38 < ttj> Right,
getGlobalResponse...[[BR]]11:38 < ttj> Nevermind. :-)[[BR]]11:39 <
Xylakant> ttj: in almost all cases you'd want to use the containers
response[[BR]]11:39 < ttj> Well, yeah, except it's empty.[[BR]]11:39 <
ttj> Or null.[[BR]]11:43 < Xylakant> i'm no expert on that topic, but i
don't think that this should happen. [[BR]]11:45 < ttj> I'm trying to
redirect from within an Action to some other URL, and if I try to get the
response through the container (i.e. getContainer()->getResponse()) it
returns null.[[BR]]11:47 < Xylakant> ah. [[BR]]11:47 < v-dogg> afaik
response is constructed only after the action execution[[BR]]11:47 <
v-dogg> and you should redirect in the view[[BR]]11:48 < Xylakant> while
the core devs and me are in dispute about this, you should probably
redirect in the view ;)[[BR]]11:48 < ttj> So you mean I have to create
some stupid View just so I can redirect?[[BR]]11:48 < v-dogg>
yep[[BR]]11:49 < ttj> (Wait a minute, deja vu. I've had this conversation
before...)[[BR]]11:49 < v-dogg> most of us have :)[[BR]]11:50 < ttj> Ok,
for some reason or another I apparently gave up before. So apparently that
was a good reason or I wouldn't have given up. So I guess I'll just do the
view even though right now I don't feel like agreeing. :P[[BR]]11:53 <
RossC0> ttj: Action classes remit is business logic - Views remit is
presentation logic - redirects fall into the presentation
category[[BR]]12:02 < Xylakant> RossC0: one might argue that redirection
is not always presentation, but may be control flow (which would be
action). but let's not start this over again.[[BR]]12:08 < RossC0> we need
a flow controller! :)[[BR]]12:11 -!- digitarald
[EMAIL PROTECTED] has joined
#agavi[[BR]]12:23 < MikeSeth> god this is such a bliss[[BR]]12:23 <
MikeSeth> I just deployed the agavi refactored application into
production[[BR]]12:24 < MikeSeth> it was so easy, and went without a
glitch[[BR]]12:24 < MikeSeth> check out from svn - fill production
configuration - go go go! [[BR]]12:25 < RossC0> :-)[[BR]]12:30 < Wombert>
v-dogg: all filters get run. no aborting after setRedirect. no content is
sent back[[BR]]12:30 < Wombert> ttj: getResponse() on the container is so
you can work with it, but the returned response is what counts[[BR]]12:30
< Wombert> (the one returned by execute())[[BR]]12:31 < Wombert> RossC0:
that's correct, before #434 that would have produced /profile/woodstock
but that wasn't good IMO[[BR]]12:31 < Wombert> Xylakant: please look at
the ticket in the topic and give your opinion[[BR]]12:32 < Wombert>
MikeSeth: your opinion on ze topic[[BR]]12:35 < Xylakant> hmm. need to
read that twice :)[[BR]]12:36 * MikeSeth tries to figure out what the
topic is[[BR]]12:36 < MikeSeth> ah[[BR]]12:36 < MikeSeth> the
*topic!*[[BR]]12:37 < Wombert> Xylakant: that's pretty much the rails
behavior then[[BR]]12:37 < Wombert> just like you wanted it :p[[BR]]12:37
< v-dogg> Wombert: so, speed-wise, it would be good to disable filters
(fpf) in the view when redirecting?[[BR]]12:37 < Xylakant> yes.[[BR]]12:37
< MikeSeth> hm[[BR]]12:37 < MikeSeth> the fundamental question is of
course whether /foo/bar/ always equals to /foo/bar/1/2/ if 1 and 2 are
considered default parameters for /foo/bar/[[BR]]12:38 < MikeSeth> I think
there should be no default values for parameters[[BR]]12:38 < Wombert> and
I believe it's a fair balance between pre-#434 behavior (which was uhm...
broken) and post #434 behavior (which was... inconvenient)[[BR]]12:38 <
Xylakant> i think foo/bar/ would be fine[[BR]]12:39 < Wombert> it will be
/foo/bar/ if the other two parameters are optional[[BR]]12:39 < Xylakant>
the defaults get filled in when the request gets matched, so no need to
specify them explicitly[[BR]]12:39 < MikeSeth> if they are optional they
must not have default values[[BR]]12:39 < Wombert> if the parameters
aren't optional in the pattern, and gen() cannot use the incoming param,
it will use the default[[BR]]12:39 < Xylakant> that's fine as
well[[BR]]12:39 < Wombert> it always did that btw and that's okay because
otherwise it would generate urls that don't match[[BR]]12:39 < Wombert>
MikeSeth: wrong! [[BR]]12:40 < Wombert> if they're optional, then the
default value is for the _incoming_ request! [[BR]]12:40 * MikeSeth
blinks[[BR]]12:40 < Wombert> €xample[[BR]]12:40 < Wombert>
search/baseball/1/[[BR]]12:40 < Wombert> if the page is
optional[[BR]]12:40 < Wombert> then it would be empty for
search/baseball/[[BR]]12:41 < Wombert> with the default set to "1", your
action gets that in case it wasn't given in the url[[BR]]12:41 < MikeSeth>
uhm[[BR]]12:41 < Wombert> v-dogg: good catch maybe the FPF and exectime
filter should pay attention to that... hmm[[BR]]12:41 < MikeSeth> how
would this behave for URLs that do not use rewriting and thus there's no
order of parameters?[[BR]]12:41 < Xylakant> but if i am on
search/baseball/ and generate an url to the same page, will it generate
search/baseball/ or search/baseball/1/ ?[[BR]]12:42 < Wombert> MikeSeth:
not at all :p[[BR]]12:42 < Wombert> Xylakant: /1/[[BR]]12:42 < Xylakant>
that's not good[[BR]]12:42 < Wombert> if you gen to ('search')[[BR]]12:42
< Wombert> why[[BR]]12:42 < Xylakant> confusing caches[[BR]]12:42 <
Wombert> ?[[BR]]12:42 < Xylakant> two urls pointing to the same
page[[BR]]12:42 < Wombert> it _is_ the same page[[BR]]12:43 < Xylakant>
same for search engines: if you use a crawler to index your
page[[BR]]12:43 < Xylakant> and search for baseball, you get the same
result *twice*[[BR]]12:43 < Wombert> yes okay then you simply don'T make
the page optional :p[[BR]]12:44 < Xylakant> is it possible to check every
optional parameter against it's default (if any) and omit it if it
matches?[[BR]]12:44 < MikeSeth> Wombert: So this works only for positional
parameters and forces the developer to assert that order matters and that
no inner parameter may be present without an outer one?[[BR]]12:44 <
Xylakant> so that always the shortest possible url gets
generated[[BR]]12:44 < Wombert> yes, MikeSeth, that's the idea.
/foo/bar/baz urls always represent hierarchies of values[[BR]]12:44 <
Wombert> e.g. /2006/08/23 makes sense but /08/23/ doesn't[[BR]]12:45 <
Wombert> Xylakant: we could do that I think[[BR]]12:45 < Xylakant>
MikeSeth: as urls resemble directory structures it is recommended that
they represent hierarchies[[BR]]12:45 < Wombert> the thing is that you
want it this way, but someone else will come here within ten minutes and
start whining about it... :([[BR]]12:45 < Xylakant> Wombert: that would be
the best solution imho.[[BR]]12:45 * Wombert cries[[BR]]12:45 < Wombert>
this is difficult :|[[BR]]12:46 < Xylakant> a selffulfilling
prophecy.[[BR]]12:46 < Wombert> we can't hack in a "URL workaround for
search engine crawlers" hack like rails does[[BR]]12:46 < Wombert> our
routing is too generic for that[[BR]]12:46 < MikeSeth> Wombert: but then
there should be different routes. E.g. /search/14 and /search/foo should
be two different routes since their meaning is entirely different and one
should be able to refer to them in gen() separately[[BR]]12:47 < Wombert>
MikeSeth: sure if you want, you can do that[[BR]]12:47 < MikeSeth> you
can, and you should. Otherwise you end up with a pattern that resolves
ambigously, and the behaviour with default values is undefined.[[BR]]12:47
< Wombert> remember you can have pattern="^/search/(id:\d+)/$" and
pattern="^/search/(term:[a-z]+)$"[[BR]]12:47 < MikeSeth> perhaps order of
default values should matter?[[BR]]12:47 -!- _stachu
[EMAIL PROTECTED] has left #agavi [][[BR]]12:47 -!-
_stachu [EMAIL PROTECTED] has joined
#agavi[[BR]]12:48 < Wombert> huh?[[BR]]12:48 < MikeSeth> Wombert: yeah,
for incoming mapping, yes. But its useless for generation, there's no
information telling it how to produce an URL based on default
values.[[BR]]12:48 < MikeSeth> ...which may be added[[BR]]12:49 <
Xylakant> why? [[BR]]12:49 < MikeSeth> why what?[[BR]]12:49 < Xylakant>
default values are tied to a parameter and those have an implicit
order.[[BR]]12:49 < Xylakant> how is there non information how to produce
an url based on default parameters?[[BR]]12:49 < MikeSeth> well if the
default parameter lookup order matters during the url generation then
there's no problem at all[[BR]]12:51 < MikeSeth> I mean as far as I
understand it.. if that's true, there's no ambigousity[[BR]]12:51 <
Xylakant> Wombert: if generating the shortest possible url is a problem, i
think that then the routing should try to generate the same url at all
times - i.e. fill in the default values[[BR]]12:51 < Wombert> lookup
order... I don't get it[[BR]]12:52 < MikeSeth> Wombert: if the generation
considers the order in which default parameter values are set, it can
assert that some default values take priority over others, and build a
default URL based on them, thus resolving the ambigousness[[BR]]12:52 <
Wombert> Xylakant: I'm afraid it's not that simple... I guess[[BR]]12:52 <
MikeSeth> s/set/specified in configuration/[[BR]]12:52 < Wombert> I don't
get it, MikeSeth [[BR]]12:52 < MikeSeth> Wombert: chances are, *I* don't
get it ;)[[BR]]12:52 < Wombert> default values are tied to
parameters[[BR]]12:53 < Wombert> yeah :D[[BR]]12:53 < Xylakant> where can
there be ambigousness in the generation of urls?[[BR]]12:53 < MikeSeth>
Wombert: yes. And default values are specified in a certain
order.[[BR]]12:53 < MikeSeth> Xylakant: "hen $ro->gen('search',
array('term' => 'snoopy')); could produce two things:[[BR]]12:53 <
MikeSeth> * /search/snoopy/1/[[BR]]12:53 < MikeSeth> *
/search/snoopy/ "[[BR]]12:54 < MikeSeth> or you could add an attribute to
the route telling the routing whether to attempt to generate a shortest
possible or a longest possible URL[[BR]]12:54 < MikeSeth>
(shortest/longest means number of positioned parameters is length, not the
resulting character length of the generated URL string)[[BR]]12:55 <
Wombert> uuuuh that's getting complicated then[[BR]]12:55 < Wombert> I
think it should be /search/snoopy/1/ unless the page parameter is
optional[[BR]]12:55 < Xylakant> MikeSeth: i think that the behaviour
should be defined, but fixed[[BR]]12:56 < Wombert> Xylakant: I thought
about it. the system would NOT set the /1/ in the next call because it
wasn't set in the input[[BR]]12:56 < MikeSeth> Wombert: I can't think of
anything else that is not an ugly hack[[BR]]12:56 < RossC0> I like:
Xylakant: is it possible to check every optional parameter against it's
default (if any) and omit it if it matches?[[BR]]12:56 < RossC0> +1 vote
:)[[BR]]12:57 < Wombert> Xylakant: the question is though... should we
have the check against the default... hmmmh...[[BR]]12:57 < Wombert> must
say I don't like that... you're on page /2/, you click back, and then
you're not on /1/[[BR]]12:57 < Wombert> hmmh[[BR]]12:57 < Xylakant> this
would generate the shortest possible url in all cases - which is nice
because it makes urls easy to remember and type and is consistent - good
for search engines and caches[[BR]]12:57 < Xylakant> Wombert: then make
the page non-optional :)[[BR]]12:57 < Wombert> Xylakant: it's _not_
consistent that's the issue[[BR]]12:57 < Wombert> yep okay good
point[[BR]]12:58 < Wombert> always shortest url possible[[BR]]12:58 <
Wombert> could do that[[BR]]12:58 < Wombert> MikeSeth: I still don't
understand the problem, can you give an exmaple[[BR]]12:58 < Xylakant> but
if you click "back" you expect to find yourself on the same page as
before[[BR]]12:58 < MikeSeth> I dont agree with the "always"
part[[BR]]12:58 < MikeSeth> then again I dont feel I'm qualified for a
full blown opinion. [[BR]]12:59 < Xylakant> so it is consistent that if
you go search/agavi/ -> search/agavi/2 -> back you should be on
search/agavi/ again[[BR]]12:59 < Xylakant> anything else will lead your
browsers cache to think that you are on a third page and fetch that page
again[[BR]]13:00 < Wombert> it is not consistent imo and not intuitive but
I can see the point in case of optional params[[BR]]13:00 < Xylakant> and
not only your browsers cache, but as well any proxy inbetween you and the
server and google and yahoo and ...[[BR]]13:00 < Xylakant> well, where
would you expect to be when you click "back"?[[BR]]13:01 < RossC0> how
about a remove defaults flag? - which scrubs any leading defaults from the
url?[[BR]]13:01 < Xylakant> remember, you were coming from "search/agavi/"
and not "search/agavi/1"[[BR]]13:01 < RossC0> I take it back is not the
back button but an inline url?[[BR]]13:02 < Xylakant> should not both
behave the same if they're labeled the same?[[BR]]13:02 < Wombert> good
point[[BR]]13:02 < Xylakant> you could even use <link rel="back" /> or
whatever that is called [[BR]]13:04 < Xylakant> it is <link rel="prev"
title="previous page" href="" /> (only supported properly in opera though,
what a pity)[[BR]]13:05 < RossC0> wouldn't that point to the previous
place in the browser history?[[BR]]13:06 < Xylakant> no[[BR]]13:06 <
Xylakant> it is meant as sort of a meta navigation[[BR]]13:06 < RossC0> ah
ok - you need a generated href :)[[BR]]13:06 < Xylakant> opera will show a
browser menu[[BR]]13:07 < Xylakant> pretty nifty feature if you ask me,
but noone uses it[[BR]]13:07 < Xylakant> there are relations for contents,
index, search, help etc[[BR]]13:07 < RossC0> ok - so if there was a
configurable option to add / remove leading defaults would that keep it
generic and allow both camps to have stable urls?[[BR]]13:08 < Xylakant> i
can live with a config option. [[BR]]13:08 < Xylakant> i don't see why
you'd want to add the defaults to the url though[[BR]]13:08 < RossC0> also
means that its a matter of post processing at the end of the gen()
function[[BR]]13:08 < Xylakant> keep em short...[[BR]]13:09 < RossC0>
neither do I - I like them short - but you can choose if you *need* the
overhead of cleaning the url?[[BR]]13:09 < Xylakant> do you think that
this overhead matters?[[BR]]13:10 < Wombert> hehe[[BR]]13:10 < Wombert>
btw[[BR]]13:10 < Xylakant> maybe, but is it more or less than parsing the
config option and the required code to make this configurable?[[BR]]13:10
< RossC0> no - but its the overhead of managing the ever complex routing
class :)[[BR]]13:10 < Wombert> the short urls have the overhead[[BR]]13:10
< Wombert> not the long ones ;)[[BR]]13:11 < Xylakant> yes i know - but
making this configurable adds even more code to an already complex
system[[BR]]13:11 < Wombert> because for gen('search', array('page' => 1))
we have to compare page to the default for page etc[[BR]]13:11 < Xylakant>
yes[[BR]]13:11 < Wombert> no, Xylakant, no overhead there[[BR]]13:11 <
Xylakant> i can live with "make the longest url" in all cases[[BR]]13:12 <
Wombert> it's an if($options['make_shortest']) { // clean defaults
}[[BR]]13:12 < Xylakant> Wombert: shure. another option is always
overhead. it may be small but it is there. [[BR]]13:12 < Xylakant> and it
sums up[[BR]]13:12 < Wombert> #1 agavi rule: consistency and reason over
performance[[BR]]13:12 < Wombert> it pays off in the long term[[BR]]13:12
< Wombert> okay that's #2 rule[[BR]]13:12 < Wombert> #1 rule is: no form
helpers :p[[BR]]13:12 < v-dogg> haha[[BR]]13:13 < Xylakant> ok, decide
this how you want this. I'd prefer the shortest possible url in all cases.
[[BR]]13:14 < RossC0> so clean leading defaults? automagically or make
configurable[[BR]]13:14 < Xylakant> i vote for "no
configuration"[[BR]]13:14 < Wombert> configurable, and I would say...
default... on... or... off... dunno[[BR]]13:14 < Wombert> nah, Xylakant,
the configuration doesn't add overhead[[BR]]13:14 < Wombert> if it's
controversial, then we need an option forit[[BR]]13:14 < RossC0> +1 for
shortest url[[BR]]13:15 < Xylakant> you have to explain that in the docs
as well. that's overhead too ;)[[BR]]13:15 < Xylakant> whatever, make it
an option. [[BR]]13:15 < Wombert> well we could make it on by default and
then explain why it trims values that equal the default and then exolain
how to update it[[BR]]13:15 < Wombert> that's what "WTF" pages are for
;)[[BR]]13:15 < Wombert> RossC0: would you happen to have a good option
name for that[[BR]]13:15 < RossC0> do you mean explaining in the logs
doesnt count as documentation ??[[BR]]13:16 < Wombert> :D[[BR]]13:16 <
Xylakant> Rossc0: would users read svn logs?[[BR]]13:16 < Wombert> we need
to build ze chuckwalla soon. I could link to this discussion in the ticket
or so[[BR]]13:16 < Xylakant> back to the roots of the
framework?[[BR]]13:16 < Wombert> he means IRC logs :>[[BR]]13:16 <
Xylakant> ah[[BR]]13:16 < Xylakant> don't think so either. [[BR]]13:16 <
Xylakant> perhaps nowadays yes, but later?[[BR]]13:17 < Wombert> I also
think he was kidding[[BR]]13:17 < Wombert> :D[[BR]]13:17 < Xylakant> one
thing that i'm missing though is that this does not work with non-nested
routes. [[BR]]13:17 < Wombert> ?[[BR]]13:17 < Wombert> course it
does[[BR]]13:17 < RossC0> ok configs names: shortUrl, tinyUrl,
simpleUrl[[BR]]13:17 < Xylakant> the example you have in your last
paragraph[[BR]]13:17 < RossC0> I like tinyUrl = true[[BR]]13:18 < Wombert>
ah yes but that's difficult to do, Xylakant, and not really something I
would find intuitive[[BR]]13:18 < Xylakant> hmm. [[BR]]13:18 < Wombert>
beause then the same gen() all produces different results[[BR]]13:18 <
Xylakant> rails does it[[BR]]13:18 < Wombert> depending on with which
incoming URL it is called[[BR]]13:18 < Wombert> not everything rails does
it reasonable :p[[BR]]13:18 < Xylakant> no[[BR]]13:18 < Xylakant> you're
right on that. but quite much is[[BR]]13:19 < Wombert> for instance, that
2006/ example in the book is nonsense[[BR]]13:19 < RossC0> yeah but how
can you equate url terms with different routes: blog terms may have no
relevance to pattern route terms[[BR]]13:19 < Wombert> incoming:
2006/08/24, then gen call with year => 2007 produces 2007/ but then gen
call with year => 2006 produces 2006/08/24[[BR]]13:19 < Wombert> that's
bollocks and we won't have it that way[[BR]]13:19 < Xylakant>
why?[[BR]]13:20 < Xylakant> it just checks that the gen-call matched the
incoming parameter[[BR]]13:20 < Xylakant> but that is probably a matter of
taste[[BR]]13:20 < RossC0> wait I like: $ro->gen('blog.archive',
array('month' => 11)); > /blog/woodstock/2006/11/[[BR]]13:21 < Wombert> it
would do that yeah[[BR]]13:21 < Wombert> if you're at a woodstock page
right now[[BR]]13:21 < Wombert> woodstock blog page[[BR]]13:21 < RossC0> I
just argue that URLs from different routes *shouldn't* have any bearing on
generating urls on other routes[[BR]]13:21 < Wombert> but it wouldn't do
that if you're viewing woodstock's profile[[BR]]13:21 < Wombert> which I
think makes sense[[BR]]13:21 < Xylakant> well, i guess the last point is
moot as the rails controller is pretty much what is the name of the route
for agavi[[BR]]13:22 < Wombert> pretty much, but not quite. we cannot
carry the entire concept over as is[[BR]]13:22 < Xylakant> so rails
wouldn't generate profile/woodstock from blog/woodstock[[BR]]13:22 <
Wombert> agavi you mean[[BR]]13:22 < Xylakant> as the leftmost parameter
is the controller and it just changed[[BR]]13:22 < Xylakant> no,
rails[[BR]]13:23 < Xylakant> agavi would not either[[BR]]13:23 < Wombert>
well then everything's perfect, right? :)[[BR]]13:23 < RossC0> but thats
good :)[[BR]]13:23 < Xylakant> you could force rails to to that by
specifying overwrite_params = {:controller => 'profile'}[[BR]]13:24 <
Xylakant> that's the missing options, but adding that would go too far i
guess[[BR]]13:24 < Wombert> in agavi, you could do $ro->gen('profile',
$rd->getParameters());[[BR]]13:24 < Wombert> well okay not quite
:p[[BR]]13:25 < Wombert> we have a related concept with
gen(null)[[BR]]13:25 < Wombert> but that works differently[[BR]]13:25 <
Wombert> it generates all current urls, you cannot change which[[BR]]13:25
< Xylakant> gen(null) just generates the current url or did i get
something wrong[[BR]]13:26 < Wombert> yes it does but you can override
params in there of course[[BR]]13:26 < Wombert> typically gen(null,
array('language' => 'en')) to link to the same page, but in
english[[BR]]13:26 < Xylakant> yes, but still it would not generate
profile/woodstock ;)[[BR]]13:26 < Wombert> yep exactly[[BR]]13:27 <
RossC0> so we need another config? to override params?[[BR]]13:27 <
Xylakant> ok, to sum it up before i leave for lunch: I'm fine with the
proposed behaviour, I would like to see default params omitted in all
cases possible (and any option controlling that to defaul on). I don't
need overriding params for the gen call atm.[[BR]]13:29 < Wombert>
k[[BR]]13:29 < Wombert> if anyone knows a decent syntax for the override
params stuff we could do it[[BR]]13:29 < Wombert> but I'm guessing it
would have to be a config option[[BR]]13:29 < Wombert> -config[[BR]]13:29
< Wombert> third argument blah
To sum it up, the described behavior is okay, but we agreed that by
default, optional parameters in the pattern should also be skipped if the
given value equals the default. In the above example, the first page would
always be {{{/search/snoopy/}}}. An option would control that behavior, a
name for it could be "skip_optional_defaults" or so.
--
Ticket URL: <http://trac.agavi.org/ticket/444#comment:4>
Agavi <http://www.agavi.org/>
An MVC Framework for PHP5
_______________________________________________
Agavi Tickets Mailing List
[email protected]
http://lists.agavi.org/mailman/listinfo/tickets
