[RCD] Roundcube Framework

Thomas Bruederli thomas at roundcube.net
Tue Feb 7 22:03:27 CET 2012

On Mon, Feb 6, 2012 at 15:53, A.L.E.C <alec at alec.pl> wrote:
> On 27.01.2012 12:34, A.L.E.C wrote:
>> TODO:
>> - create rcube_framework class as a base for rcmail, which will contain
>> only backend-related functionality. The idea is that in use-case where
>> UI is not needed we'll be able to just do:
>> class rcmail extends rcube_framework {}
>> - make plugins api optional, create rcmail::exec_hook() as
>> plugins->exec_hook() wrapper,

I don't have a clear picture how the plugin API can fit into this
split of classes. It's clear that some framework classes need to
trigger plugin hooks directly. Therefore we cannot just keep the
plugin API in the app part. On the other hand I actually don't like
the idea of rcmail (which to me represents "the app") being derived
from a rcube_framework class.

What about making rcube_plugin_api a framework class with a singleton
getter and for convenience reasons add some static methods such as
rcube_plugin_api::exec_hook(). And the actual loading of the plugins
is then initiated by the app (e.g. rcmail::startup()) and no longer
integrated part of rcube_plugin_api::init(). That way the app (rcmail)
can load the plugins according to the local config and only those
matching the current task and the framework classes can still trigger
plugin hooks without requiring direct context of rcmail. Furthermore a
user of the framework can also create/use plugins and load them into
the rcube_plugin_api singleton in his very own app and according to
his very own configuration and criterias.

>> - don't use translation (gettext()) inside backend classes, e.g. should
>> rcube_addressbook return translated error messages? I think so.

rcube_addressbook doesn't necessarily need to return translated
messages, we already have some abstraction with the constants ERROR_*
in that class. However, I don't think that rcube_addressbook (and
derived classes) should become part of the framework. Format and
wrapper classes such as rcube_ldap_generic (being a generic ldap
wrapper without specific address book functions) as well as
rcube_vcard are good candidates for the framework and should be
decoupled as much as possible. The entire address book classes are
part of the application and probably not very useful to anybody else.

List info: http://lists.roundcube.net/dev/

More information about the Dev mailing list