Not fully sure if this is a bug in the paginator or in my own router,
but when I use a pattern to catch usernames entered directly after the
first slash, I get the full pattern rendered in the pagination links
for paging on the user page (but not on other pages not routed with a
regexp pattern) instead of the username plus the pagination parameters
that you would expect. The pattern looks like this:

Router::connect('(?!admin/*|foo|bar|users/*)(.*)',
array('controller'=>'users', 'action'=>'view'));

And the links looks like this, i.e. the routing patterns with the
username inserted:

/(?!admin/JohnDoe/page:2|foo|bar|users/JohnDoe/page:2)(.JohnDoe/page:
2)

The rest of the generated links (i.e. non pagination links) on the
page are as they should, i.e. /JohnDoe/key:val//key2:val2/

Tried to hunt this down in the paginator helper but nothing strange
happens until Router::url($url) is called at the very end of paginator-
>url() , then the weird url is returned.

So, it looks like the Router::url doesn't evaluate the patterns as a
regexp in this case, but does it for direct calls to the url() helper
since other links are ok.


Another paginator thing that might be a bug, or a misuse of the
parameters sent. If you want the last page number in a pagination row
be displayed in the "last" link instead of the word "last" as an
indicator of the total sum of pages, and sets the last parameter like
this in your view:

$paginator->numbers(array('first'=>"1", 'last'=>$paginator-
>counter('%pages%') [...]

Then the last link is never rendered. It turns out that as long as it
can convert the last parameter to an integer, it is ignored (to cast
it as string doesn't help). If you add a letter at the first position
in that "last" parameter, it is rendered correctly together with the
number of pages, like x123.


Finally, wouldn't it be more semantically correct to have the
pagination markup rendered as a list instead of spans? Require of
course that you can write CSS for such a list but it has become a
widespread usage to format other kind of menus as lists nowadays. It
would also be nice to add classes for "first" and "last" so you can
match them with CSS selectors if you e.g. want to add some whitespace
after/before them instead of the ellipsis text string (...) that you
can have inserted.

If this is seen as a good idea, but breaks current implementations of
pagination too much, maybe a preferred tag type can be sent as a
parameter to the paginator. The first/last classnames could be added
to the code without breaking anything implemented with the paginator.

As it is now, I patch that paginator helper on each update I do from
Cake svn to get a correct list rendered.

/marten

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake 
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to