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,
- 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/aba52c80