The principe of system is to permit the class overload by the user of Xoops.
Lot of developper use the custom distribution for xoops and the overload of method of class is very difficult for their.
If they modified the class, before the update, they should verify all their modification and report this on the new xoops version.
The first solution :
Format variable : static $handler_modify(name_class,path);
The main problem is the security.
The first protection is sending a message at the user (notice php) in the debugger to say that module change a core class.
Any module or script php can overload a class of the core. A disaster.
The second method :
Mapping a new class definition in the initfile.
This mapping can be do in the object without public assessor for the variable.
We can save the method only once. After the object become a read only.
In the function xoops_gethandler and xoops_getmodulehandler to do a call at this object.
The solution is less modular but more secure.
The classic Class Xoops :
They don't call by a Factory, it's a problem.
The best solution is to add factory at these classes with a private constructor.
Problem, lot of module become uncompatible.
If we maintain the compatibility with the old module with public constructor, it's unmanageable by the user.
After, it's possible to add a convertisseur with all the xoops class, it's possible to transform all the text in the module php code with the regular expression.
Currently, for the classic module xoops, it's a best solution that I see.
If someone has a better solution ... I take
Log in to post a comment.