We use Framework already in two external programs. I put files under lib/Roundcube there and modified autoloader
$filename = preg_replace(
array(
'/Mail_(.+)/',
'/Net_(.+)/',
'/Auth_(.+)/',
'/^html_.+/',
'/^rcube(.*)/',
'/^utf8$/',
),
array(
'Mail/\\1',
'Net/\\1',
'Auth/\\1',
'Roundcube/html',
'Roundcube/rcube\\1',
'utf8.class',
),
$classname
);
So, now we're able to create a separate package with Roundcube Framework (with location in e.g. /usr/share/php/Roundcube) and not duplicate the code for every dependent project. What do you think about doing the same in Roundcube? If so, what should we do with clisetup.php, iniset.php, rcube_bc.inc and rcmail.php. Move them to program/lib/ (or program/) and get rid of program/include/ directory?
A.L.E.C wrote:
We use Framework already in two external programs. I put files under lib/Roundcube there and modified autoloader
[...]
So, now we're able to create a separate package with Roundcube Framework (with location in e.g. /usr/share/php/Roundcube) and not duplicate the code for every dependent project. What do you think about doing the same in Roundcube? If so, what should we do with clisetup.php, iniset.php, rcube_bc.inc and rcmail.php. Move them to program/lib/ (or program/) and get rid of program/include/ directory?
What about moving framework classes/files to program/framework and keep the Roundcubemail app related classes and files in program/include?
I think both, the framework and the include directory, should have an iniset.php (you can rename it to bootstrap.php if you want) which does the necessary setup to use either the framework or the Roundcube application. program/include/iniset.php would most likely include program/framework/iniset.php to effectively load the framework to be used within the application.
clisetup.php is part of the application but maybe the included functions could be moved to framework/rcube_cli.class
rcube_bc.inc should remain in program/include and help keeping up backwards compatibility for the numerous plugins for Roundcube. Whoever wants to use the framework only should not use deprecated function calls.
~Thomas
On 11/19/2012 02:30 PM, Thomas Bruederli wrote:
What about moving framework classes/files to program/framework and keep the Roundcubemail app related classes and files in program/include?
I prefer lib/Roundcube because this allow as to re-use rcube_autoload(). It's better to have /usr/share/php/Roundcube than /usr/share/php/framework.
I think both, the framework and the include directory, should have an iniset.php (you can rename it to bootstrap.php if you want) which does the necessary setup to use either the framework or the Roundcube application. program/include/iniset.php would most likely include program/framework/iniset.php to effectively load the framework to be used within the application.
Not a bad idea, but we still have 4 files in program/include, that's why I thought about getting rid of this directory.
clisetup.php is part of the application but maybe the included functions could be moved to framework/rcube_cli.class
These are only two functions, so we can just move them to rcube_utils.
A.L.E.C wrote:
On 11/19/2012 02:30 PM, Thomas Bruederli wrote:
What about moving framework classes/files to program/framework and keep the Roundcubemail app related classes and files in program/include?
I prefer lib/Roundcube because this allow as to re-use rcube_autoload(). It's better to have /usr/share/php/Roundcube than /usr/share/php/framework.
I was not talking about the final install location on a target system but about our git repository.
Installing files to /usr/share/php/roundcube-framework and /usr/share/php/roundcubemail would be good suggestion but that's up to packagers or sysadmins.
For our complete webmail package, we should pack everything into the program directory in order to keep the update procedure as it currently is.
I think both, the framework and the include directory, should have an iniset.php (you can rename it to bootstrap.php if you want) which does the necessary setup to use either the framework or the Roundcube application. program/include/iniset.php would most likely include program/framework/iniset.php to effectively load the framework to be used within the application.
Not a bad idea, but we still have 4 files in program/include, that's why I thought about getting rid of this directory.
Only 4? I assumed that some classes like rcube_output*, rcube_session and rcube_user remain "application-only" and would not become part of the framework.
But even if we end up with the 4 non-class include files, I think the directory "include" is the appropriate location for them.
~Thomas
On 11/19/2012 04:42 PM, Thomas Bruederli wrote:
Installing files to /usr/share/php/roundcube-framework and /usr/share/php/roundcubemail would be good suggestion but that's up to packagers or sysadmins.
If you put them in /usr/share/php/anything you need to add this directory to include path or modify autoloader. lib/Roundcube allow as to skip this requirement if we modify autoloader as I proposed.
-
A.L.E.C -
Thomas Bruederli