[development] Path mapping system
Karoly Negyesi
karoly at negyesi.net
Wed Dec 28 06:12:58 UTC 2005
Hi!
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!
Regards
Karoly Negyesi
More information about the development
mailing list