[development] The new menu system

[adrian rossouw]

On 27 Sep 2006, at 4:17 AM, Larry Garfield wrote:

>
> How well would this support more complex access rules?  Currently  
> the end
> result is a boolean and that's all that's saved.  That allows for  
> complex
> rules like:

The issue with a boolean like that however is that it's result is  
different for every single
user. This new menu system entirely removes the may_cache element,  
and is almost guaranteed
to be several orders of magnitude faster and less memory intensive.  
(disclaimer: 64.5% of statistics are made up on the spot).

>
> user_access('break things') || $uid=1 || $uid == $nid->uid
You can still wrap this in a function and call it. This is sadly the  
only
way this can be done, due to php's unfortunate lack of support for  
closures.

> (or whatever).  How would we do similar compound access rules with  
> this
> system?  It looks like it would only support a single function  
> call, which is
> not always appropriate.

I have a mechanism to allow multiple function calls, but it is still  
only for a limited amount of flexibility. It is built on the callback  
specification of forms api, and is formalised using a
function as a constructor. :

function cb($function) {
   $args = func_get_args();
   $callback = array_shift($args);
   $data['_properties_'] = array('type' => 'callback'));
   $data[microtime()] => array('callback' => $callback, 'arguments'  
=> $args);
   return $data;
}

Which now allows you to do :
'access' => cb('function', 'arg') + cb('function', 'arg') + cb 
('function','arg')

In the data api, any property can be a callback instead of a value,  
in fact it's
preferred as callbacks can be cached, but values can't be.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060927/033b2545/attachment.htm