Plugins
Moderators: Amaradana, TurboPT, TL Developers
Plugins
I think that our project became more and more complex. This brings that user customization is more difficult. I feel that we need to specify a way which allow to better maintain an user customization. It helps update code to newer version and make customization more easy.
Estimated effort: about two days. No dependencies with other development.
Please, discuss the next proposition:
Specification:
TL allows add own features, that are automaticaly loaded by core system. Plugins are stored in directory /plugins. Configuration file is stored directly in this directory and own code and templates are stored in subdirectory.
There are two types of plugins: module and report. Module is loaded as link to main page. Report is loaded to report menu.
Configuration parameters:
- link_url
- lib_directory
- tpl_directory (optional)
- type = [modul, report]
Optional (for impl. phase 2)
- compatible =
- uncompatible =
- update_http = url
- update_check = url
Estimated effort: about two days. No dependencies with other development.
Please, discuss the next proposition:
Specification:
TL allows add own features, that are automaticaly loaded by core system. Plugins are stored in directory /plugins. Configuration file is stored directly in this directory and own code and templates are stored in subdirectory.
There are two types of plugins: module and report. Module is loaded as link to main page. Report is loaded to report menu.
Configuration parameters:
- link_url
- lib_directory
- tpl_directory (optional)
- type = [modul, report]
Optional (for impl. phase 2)
- compatible =
- uncompatible =
- update_http = url
- update_check = url
Last edited by havlatm on Mon Jan 21, 2008 4:07 pm, edited 1 time in total.
good idea but please postpone to 1.8
1.7 is already full and will keep us busy for some time. Please consider this for 1.8 release.
Kevin Levy
-
- TestLink user
- Posts: 7
- Joined: Thu Nov 17, 2005 1:42 pm
- Location: Hosur, India
- Contact:
I am new to TestLink and currently evaluating it.
However, I find that a phenomenon that configuration data are actually embedded in source code although they are in separated set of php files.
I would suggest to consider put them into database tables or xml files. They could be load into the system during start up.
Regards,
Francis
However, I find that a phenomenon that configuration data are actually embedded in source code although they are in separated set of php files.
I would suggest to consider put them into database tables or xml files. They could be load into the system during start up.
Regards,
Francis
php variables are still used together with XML or database tables. However, it does not require to hard code system or configuration data to be hard coded into php file (programs). However, this requires the system to load these system or configuration data during system start up. But, I think this is a more clean and neat architecture for a system.
Either way should be able to achieve the objective of separating data from system/business logic.
In my 2 cents opinion, XML carries only data unless system logics is implemented in the form of data. Otherwise, XML files contain mainly data only. However, both have pros and cons.
DB solution requires a DB but requires simpler data retrieval logics. XML solution requires text file support but requires more complicated data retrieval logics.
Apart from the 2 solution, there are many other possible options such as csv files, fixed/variable length flat files, etc.
So, this is a question for the architect to decide.
In my 2 cents opinion, XML carries only data unless system logics is implemented in the form of data. Otherwise, XML files contain mainly data only. However, both have pros and cons.
DB solution requires a DB but requires simpler data retrieval logics. XML solution requires text file support but requires more complicated data retrieval logics.
Apart from the 2 solution, there are many other possible options such as csv files, fixed/variable length flat files, etc.
So, this is a question for the architect to decide.

This would be good, since not everyone has access directly to the webserver itself. Also someone could easily screw up the config when playing directly with the config php file.I consider to use use generic configuration modul, that allows to configure parameter via GUI
Of course if ever you decide to add this, and probably you are already aware of this, security is needed to that GUI, infact I would suggest a completly seperate link from Testlink.
Thanks and good work guys...
Martin