[development] Path mapping system

Karoly Negyesi karoly at negyesi.net
Wed Dec 28 06:12:58 UTC 2005


I talked with Ber about path mappings and here are my ideas:

*) We remove arg() calls from most of core and use parameters to callbacks.
*) Instead of linking to node/$nid , we have a give_me_a_path('node',  
$nid) function. On admin UI you can choose which handler deals with 'node'  
type paths. This handler gets $type ('node', 'comment' whatever) and $id  
as a parameter and creates a path. This is the crux of the matter: instead  
of dumb string aliasing what path module does currently we create an  
'intelligent' subsystem.
*) I first thought that we need to add regular expressions to menu to  
match incoming paths against but I am not sure. The current system, I  
think is able. See below for an example.

For example, a mapping for the type 'user' could describe itself as 'puts  
usernames into the path'. After choosing this handler when url gets  
('user', $uid) , it would hand over these as parameters to the  
username_path function which would grab name field from user table and  
return with the path "username/$name". This is one SQL query against user  
table which is approximately the same amount of work that path does  
currently -- but it queries an indexed table with a numeric index. The  
function url() would call only one mapping function per invocation as it  
is now, with the only change that this function comes from a variable.

A menu callback would handle the path 'username', with an argument of  
$name. This callback is as simple as loading $uid and calling user_page  
with it. So I think this subsystem could scale nicely.

Of course, this is a LOT and LOT of work because we need to change EVERY  
l/url in core to be an 'intelligent' call. But the results!


Karoly Negyesi

More information about the development mailing list