On Mon, Feb 6, 2012 at 15:53, A.L.E.C <[email protected]> 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, >> - don't use translation (gettext()) inside backend classes, e.g. should >> rcube_addressbook return translated error messages? I think so. >> - should rcube_message go to the backend group? if so, it cannot depend >> on rcube_ui nor localization, > > any comments on the above points?
I general, yes. The rcube_message class is our interpretation of a mime message and should be pretty general. I don't see where rcube_ui comes into the game here and we hopefully can find a way to replace the rcube_label() calls with some placeholders which can then be localized by the app itself. > > Some more ideas: > - create rcube_input utility class for get_input_value() related > functionality, If this is the only function, we should rather move it to a utils class. > - create abstract rcube_output class (with some output-related utilities > e.g. json_serialize()) +1 > - rename rcube_json_output to rcube_output_json, it should extend > rcube_output > - rename rcube_html_page to rcube_output_html, it should extend rcube_output The less renaming the better... > - rename rcube_template to rcube_output_html_template Since rcube_template is the only class extending rcube_html_page, we could actually merge them together and just name 'rcube_output_html' or 'rcube_html_output'. ~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/8f4f07cd
