Topics

1

Development / Develop new plugin with db - best practice?

« on: December 07, 2009, 06:25:08 am »

Hi all,

I want to develop a new plugin with DB-Storage, in detail the plugin should store quotes and display one of them in a random way as a 'quote-of-the-day' in the dashboard (I mean the overview-page).

I think I need to:

• create the plugin-structure
• create the database-layout
• modify the dashboard, or?

The database-structure is simple, because its one table, but how is it created during installation? Is there an upgrade-mechanism, if I will release a plugin-upgrade in future, which I should now keep in mind?

How about modifying the dashbord? Is this the right way or do I have to implement or extend some hooks? Does anybody has a working mini-example *WITH* DB_Access?

Thanks a lot and best regards,

Thomas

2

Architecture / Suggestions to plugin-system

« on: November 13, 2009, 10:59:31 am »

Hi all,

if I have checked the plugin-system in the right way, every developer has to create a zip containing his files in that way, that the folders in the archive match the folders-structure of opengoo. I find this not very usable, because

• one developer can overwrite changes from another one
• every update of opengoo makes plugins unavailable

I have found a very well designed plugin system with makes it easy to develop and maintain plugins at dotProject (http://www.dotproject.net/), but that framework seems to be dead.
The way is as follows:

• There is a plugin-folder in the application
• Every developer creates a zip, which will be extracted into this folder and creates a subfolder for the plugin
• All stuff needed by the plugin is *inside* the subfolders-structure
• Opengoo-Administration-Panel reads all subfolders of plugin-folder and knows about every installed plugin
• Every plugin can be installed, removed, activated and deactivated and the state is remembered in the db by opengoo itself
• This works, because in every plugin is a setup.php with corresponding methods. In install for example the create-table statements will be executed and in remove-method the drop tables. The update-method should have a switch inside to handle the plugin-versions and fires alter-table-statements
• The name of the plugin is also defined in setup.php and some other attributes.
• This ensures, that the whole control and maintence of the plugin is at the developer
• The admin can with this way control all plugins, order them (display-order), activate and deactivate them
• The admin can configure them, if the methods are implemented
• The plugin can make contributions to dashboard and the admin/user can control it
• The plugin is not affected on updates (except api-changes) and other plugins

I currently find this plugin-system here a little be complicated and difficult to extend.

What are your opinions?

Thomas

3

Ideas / eMail again

« on: October 28, 2009, 11:04:28 am »

I would find it useful, if the administrator could switch between the current email-perspective and an eMail-perspective, which simply acts like all other webmail-clients, without storing eMails in the internal DB. Pure simple IMAP. :-)

Thomas

4

Ideas / Hirachical Notes/Tasks

« on: October 28, 2009, 11:02:04 am »

I suggest to add a tree-view to the notes/tasks view to give the user the ability to organize these objects in a tree-view (or by categories)

Thomas

5

How To's / How to share an event?

« on: October 28, 2009, 10:59:20 am »

Hi all,

I have two users with a private workspace for each and I want to share certain calendar-events (not generally all) - how can I do this?

Thanks a lot and best regards,

Thomas