Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/a2fe033912676eb5#
Right now In-Portal uses mostly one of 3 class types to do it's job:
- event handler - handles all actions from user side
- tag processor - displays content, that tags generate on templates
- helpers - classes that do jobs specific to both event handler and tag
processor
Right now In-Portal uses helper classes of 2 types:
- general - not a unit bound functions inside
- unit bound - unit bound functions inside that either expects
initialization with unit info (e.g. BracketsHelper) or unit is given for
each called method (e.g. kSearchHelper).
Lately I had troubles with extending kSearchHelper to a needs of a specific
unit only. Right now there are these problems:
- extending helper class to be used with one unit would cause other
units to use same extended helper class (even if they don't need that)
- helper class can only be extended once and if 2+ modules need specific
code they can't do it.
Here is an improvement I'm proposing:
1. allow default parameter values in class registration (e.g. don't
specify 'build_event' parameter all the time with 'OnBuild' value)
2. add SearchHelperClass => Array ('class' => 'kSearchHelper' ,'file' =>
'') construct to unit config (if absent will be considered as default)
3. add kBase::getSubObject($class_suffix, $params = Array ()) method,
that would internally do this: return
$this->Applcation->recallObject($this->getPrefixSpecial() . '_' .
$class_suffix, $this->Prefix . '_' . $class_suffix, $params);
4. replace code
$this->Application->recallObject('SearchHelper')->performSearch($event)
with code $this->getSubObject('SearchHelper')->performSearch()
There are several benefits from code above:
1. via $this->getSubObject there is possible to easily (very short code
piece) to create unit-bound helper class version
2. even shorter unit config class registrations
3. adding unit-specific code to common helper class won't affect other
classes who uses that helper
--
Best Regards,