Community wiki

Community wiki

Proposal New Hooks for eGW

Hooks are used in eGW to integrate modular parts / applications in eGW. In the current implementation hooks are included php-files, which add to the html-output of an app, by echoing more html.

It is on one side an efficant system to keep the apps and the whole eGW framework module, on the other side it has one important design flau: all variables and functions called have to be in the globals scope.

There are some more minor issues, like:
  • each hook has to be in a single file, which usually does nothing else as to create an instance of the UI-class and call one of it's functions
  • there is no standard way to negociate what type of content the hook can return and the app prefers, eg.
    • a traditional hook is only able to echo html, an xslt or eTemplate app could of cause switch the php4 output-buffering on to capture that output, and to integrate it in an existing template.

How can the hooks be more efficient, but at the same time compatible with the existing code ?

  • the new type of hook should be a methode, a public function from a class, eg.
  • new hook have to be defined by apps, via
$setup_info[$app][hooks] = array(
   'search' => '',   // new hook
   'preferences'  // old file-type hook
  • it should has minimum one standard param to spezify the type of content, eg.
    • 'html' plain html, like the old templates, but return by the method, not echoed
    • 'xslt' array with xml-data and xslt-template to format it
    • 'etemplate' array with data and etemplate to format it
    • 'array' array of data, no direkt output content (caller and function need to know / use the right type)
    • ... (maybe other types we dont think about today)
  • they should return an array with the type of content disired by the calling code or the only one the hook can deliver
class uiapp
   // other stuff of the ui-class

   function search($type,$pattern)
      $found = $this->bo->search($pattern);
         case 'array':
            $result['array'] = $found;
         case 'xslt':
            $result['xslt'] = array(
               'data' => $found,
               'tpl'  => 'search_result',
               'app'  => 'app'
         case 'html':
            foreach($found as $data)
               $result['html'] .= '<p>'.$data['name'].'</p>';
      return $result;
  • the hook class gets the method-name instead the file-name from the db-table phpgw_hooks, where setup puts it while registering the app (same as today for the old type of hooks)
  • the hook class can capture html from old hooks and can return it to apps calling the new hook-funktions and also request 'html' and echo it for apps calling the old hooks function for a new hook
  • the param for the "new" hook function should be include the old parameters plus the type parameter and additional params to be passed to the methode

If you have comments, please add them here (with name) or mail them to RalfBecker

comment by Angles

I agree with the idea that the hooks are limiting, for the reasons you mention and also for this reason: the phpgwapi is a VERY flexible thing, any function in any object from any app can be invoked by any one.

They are exposed via the phpgwapi either by
  • creating an instance and calling the desired function
  • or more simply by using the "menuaction" URI which does that for you.

It seems the current hook system is left over from before the 3 tier change made said flexibility possible. I can see in your example code you are using that flexibility in your proposed hooks, while still "keeping it simple" for the hook user, i.e. the new hook still provides some of the complicated stuff to get the job done in a simple way.
END comment by ((Angles))

reply by RalfBecker

  • Most important reason why we still need hooks, is that an app calling a hook does not know (or need to know) which other apps are interested in that hook. You can call each public methode simply by calling ExecMethode('<app>.<class>.<function>',$args), but you have to know, or check before, if the app is installed and which apps are interested in the hook.
  • The content type negociation, might not be necessary for all hooks.

Back to eGroupWare / DeveloperDocs
You are here