Hi, thanks for reviewing. I'll wait until next weekend for other ideas and discussion.
The list so far: > 1. Auto-calling plugin actions for build-in tasks/actions, it means we > should add (in index.php) code for automatic calling of actions e.g. > 'mail-compose-before', 'mail-compose-after', 'mail-sendmail-before', > etc. and probably also 'mail-before', 'mail-after', etc. yes - sure. btw. I like the style "mail-compose-before" (or "user-login-after" as in my example) It's pretty clearer than my definition. I'll patch the existing code where I need it right now. Maybe we could team up to implement it everywhere, or could implement it module-by-module. We should have a list where actions should be called. I do not have the time to do this alone. > 2. Possibility to use own tasks/actions (I mean > /?_task=settings&_action=myaction or /?_task=mytask) such as a calendar-plugin ;-) lovely. Would be great - but somewhat out of scope I think. Shouldn't we better concentrate on the core plugin-arch and extend it later? But we have to talk about how to implement this later. > 3. Javascript part - for javascript functions/actions (in similar > fasion) including point above. again. Out of scope for my purpose. How can we extend it later to support this? > 4. Possibility to add UI part from plugin without skins modification. > It's "must have", but I think, we can live without that for now. same. We do not have any of these options right now so let's do the core. > 5. Actions priority - if we have few plugins for the same action which > should be executed first? > 6. Config option(s) for enabling/disabling plugin parts. Let's say we > have a plugin with few features, but we need only one. Ok, we can have > separate configuration for each plugin, but maybe something global? > Let's say using regexp. It may be used for temporary disabling whole > plugins without removing files from plugins/ dir. E.g. > $rcmail_config['disabled_plugins'] = 'plugin2 plugin3::mail-compose.* plugin3::settings.*'; Yes, agree. I thought about it but someone on the list denied the use of configuration. But I think this is a must-have. $rcmail_config['disabled_plugins'] = 'plugin2 plugin3::mail-compose.* plugin3::settings.*'; could be a problem because a plugin could possibly rely on some actions - which could be turned off (2nd and 3rd example). What about: $rcmail_config['enabled_plugins'] = array( 'plugin1', 'plugin2' ); If a plugin has parts which could be turned off and on it should have it's own configuration. This is IMHO the plugin part. > > Just to make sure. The plugin system we're talking about here doesnt just > > allow actions, but also small hooks everywhere throughout the code/templates? > > Yes for me. I think templates engine should call plugin actions > before/after each template object (objects, but also e.g. buttons and > every template tag with specified name) and return content from those > actions. Hi, A.L.E.C., thanks for joining us in design phase ;-) Everywhere in the code - yes. This should be a milestone in future. Everywhere in the template - I don't know much about your templating. How/where do we have to implement it? Just an idea: Does it make sence to split things up? This 'fackend-plugin' project for server side actions A new "frontend-plugin' project for client side things like JS, Html, Ajax-Client, ... Both should share the ./plugins directory so that a plugin can work with both. As I do not have any good insight of RC-Templating this could be a bad idea anyway. Dont know. Waiting for futher comments ;-) Thank you. -- Florian Lagg - Florian Lagg - IT-Komplettlösungen Juch 7, 6631 Lermoos tel +43 (699) 10 20 10 24 www.lagg.at - [EMAIL PROTECTED] - Xing: http://www.xing.com/go/invite/7372113.3da562 - _______________________________________________ List info: http://lists.roundcube.net/dev/
