On Mon, Feb 6, 2012 at 15:53, A.L.E.C alec@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.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80