[development] The new menu system

[Dries Buytaert]

On 26 Sep 2006, at 13:58, Karoly Negyesi wrote:

> My focus was finding the active callback. I simply followed  
> JonBob's directions: "We could simplify menu declaration by  
> allowing some sort of wildcards in menu paths. For example, if a  
> module could declare the path "node/%d/edit", then we could  
> dispense with the logic that defines the function only if we are in  
> a node path. The code would certainly be cleaner in this case."
>
> I am using the percent sign as a wildcard. There is no %d or %s  
> just %. So you define node/%/edit. Let's say someone navigates to  
> node/12/edit/foo. Now, how do we find out that node/%/edit needs to  
> be run? We generate all possible callbacks and check which one exists:

Any particular reason not to use %d and %s?  I'd favor the use of %d  
and %s (instead of %) for two reasons:

   1. Security.  It allows us to cast URL parameters to their proper  
type.  This helps to prevent XSS/SQL injection attacks.

   2. Consistency.  People familiar with the database API can easily  
guess what they do.

> The binary numbers are generated naturally: where you see a %,  
> that's a 0, where you see a specific part, that's a 1. This will  
> nicely indicate the the order in which they need to be checked  
> (this is my idea and I am very proud of it -- nothing else in here  
> is my idea).

Mmm.  So, say we have 250 menu callbacks in the system, and we're  
trying to match 'node/12/edit/foo'.  There exist 15 permutations of  
'node/12/edit/foo' so in the worst case scenario we'd have to do 250  
* 15 = 3750 string comparisons to find the proper handler?  That  
sounds excessive ... and is bound to be really slow.  Maybe I'm  
mistaken?

> Our life gets a bit complicated here, because we do not need to  
> grab one menu item but three: one that defines the title, one that  
> defines the (page) callback and one that defines access. Instead of  
> running three queries against a huge table, I planned to retrieve  
> all possible matches, and pick my three items. As a bonus, I will  
> get the breadcrumb trail. Someone at the second menu meeting  
> (Steven? Adrian?) pointed out that I could move this to the builder  
> phase, and that's done. So we are back to retrieving one item which  
> has title, callback and access inherited as needed.

This part I don't understand ...

--
Dries Buytaert  ::  http://www.buytaert.net/