Notice: A non well formed numeric value encountered in /home/www/lightninglauncher.com/docs/www/flyspray/includes/class.flyspray.php on line 96
Notice: A non well formed numeric value encountered in /home/www/lightninglauncher.com/docs/www/flyspray/includes/class.flyspray.php on line 96
Notice: A non well formed numeric value encountered in /home/www/lightninglauncher.com/docs/www/flyspray/includes/class.flyspray.php on line 96
Deprecated: Function create_function() is deprecated in /home/www/lightninglauncher.com/docs/www/flyspray/includes/class.flyspray.php on line 104
Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/www/lightninglauncher.com/docs/www/flyspray/adodb/adodb.inc.php on line 845
Deprecated: Function create_function() is deprecated in /home/www/lightninglauncher.com/docs/www/flyspray/includes/class.user.php on line 111
Notice: Undefined index: tasklist_type in /home/www/lightninglauncher.com/docs/www/flyspray/includes/class.tpl.php(128) : eval()'d code on line 85
Notice: Undefined index: tasklist_type in /home/www/lightninglauncher.com/docs/www/flyspray/includes/class.tpl.php(128) : eval()'d code on line 90
It would be great to be able to extend Lightnings visible Elements to overwrite / add methods & functionality.
This would allow e.g. to create a custom container.
Uneasy to implement, at least these issues to solve:
- there need to be a kind of registry to link an item in the configuration file and its constructor in script. Maybe a script could use a naming scheme based on a class name, the configuration file would refer to this class name in place of the builtin item types.
- need to be able to store item specific data. This might require modification of the config file.
- the existing item classes need to be aware that they can be extended, which is absolutely not the case at the moment (behavior, mostly private methods, some code to expose to subclasses)
- the code need to be extensively modified to take into account the possibility of subclasses (use of instanceof versus object.getClass()==some.class)
Friday, 04 March 2016, 10:17 GMT
- there need to be a kind of registry to link an item in the configuration file and its constructor in script. Maybe a script could use a naming scheme based on a class name, the configuration file would refer to this class name in place of the builtin item types.
- need to be able to store item specific data. This might require modification of the config file.
- the existing item classes need to be aware that they can be extended, which is absolutely not the case at the moment (behavior, mostly private methods, some code to expose to subclasses)
- the code need to be extensively modified to take into account the possibility of subclasses (use of instanceof versus object.getClass()==some.class)