Re: [Mantisbt-dev] Plugins

[Martijn D. <mde...@op...>]

Hi,

I was thinking along the same lines for the documentation - i.e. have the 
Mantis documentation come, via a plugin, from the database, like in the 
PostNuke content module.

This might then also be applicable for project documentation uploads, 
providing that would be in text / HTML format.

Martijn


Quoting Alex Bennee <Ale...@ma...>:

* 
* 
* This is a copy of the original mail and reply between myself and Ken. I
* include it for comment and ideas from any one else on the developer list.
* Other than our own internal requirements one possible plugin would be one
* to integrate to CVS. Ideally modules wouldn't want to play too much with
* the existing mantis structures so a possible CVS solution would add an
* extra two tables:
* 
* 1. CVS Repositries. Totally independant from Mantis
* 2. CVS changes. Indexed by bug id, cvs id and the details of changes.
* 
* I hope to have a play with a few ideas once Ken's released 17.1. Does
* anyone have any general comments to make on a plugin system?
* 
* Alex.
* 
* ---
* 
* Alex,
* 
* I've been interested in a plugin system but I have no experience with
* one.  I was examining Squirrelmail's implementation but then forgotten
* about it.  Maybe we could start a discussion on the dev list of a few
* useful examples and where the plugin API calls should be.
* 
* Thanks,
* -Ken
* 
* >Hi,
* >
* >After our success with using Mantis on our last project I'm thinking of
* >moving the data currently held on my VBA hacked up MS Project thing to
* >mantis. I'm probably going to do it a cleaner way this time (i.e. have one
* >additional table, indexed by bug_id with marconi specific data) and try
* and
* >put all the marconi specific code to extract that data in a separate
* >module. This should hopefully mean that I can send patches that clearly
* >separate changes to the core of Mantis (which you'll want :-) and changes
* >that we use at Marconi (which you can have if you want, they'll probably
* be
* >of little use however). However it does lead to an interesting question:
* >
* >Have you considered a plugin architecture?
* >
* >This sort of approach is used by content systems such as postnuke to make
* >adding functionality simpler. It basically involves defining where your
* >plugins are stored and an API for how they are used. As a quick example
* >type thing:
* >
* >1. Have plugins create a sub-dir under plugins that is the plugin name
* >(e.g. ~/plugins/marconi). The plugin code can then scan the plugins
* >directory for a list of plugins that are available. This will probably
* want
* >to be an admin thing as it would be expensive to do every time you loaded
* a
* >page.
* >
* >2. Plugins can register what pages they can add to/enhance. An easy way
* >would be to have a register_plugin.php in the plugin subdir (e.g.
* >~/plugins/marconi/register_plugin.php). This would use some API calls to
* >let mantis now what pages the plugin_link could be added.
* >
* >So say for my example plugin to interface with my corporate IR tracking
* >database EMDS it would go something like:
* >
* >      a) Go to plugin admin menu, active EMDS plugin
* >      b) This calls register plugin which makes calls to say this plugin
* >adds to the View Bug page with ~/plugins/marconi/emds_bug.php
* >
* >in use:
* >      c) Go to View Bug page. Mantis displays  the bug info and a plugin
* >link [EMDS]
* >      d) User clicks on the [EMDS] link and the page is reloaded but
* calling
* >emds_bug.php instead of the normal page contents
* >
* >Its only a rough idea but I was wondering if you had given it any thought?
* >
* >Alex.
* >p.s. Do you want me to post to the dev-list instead?
* >
* >
* >
* >------------
* >This e-mail and any attachments are confidential.  If you are not the
* >intended recipient, please notify us immediately by reply e-mail and then
* >delete this message from your system. Do not copy this e-mail or any
* >attachments, use the contents for any purpose, or disclose the contents to
* >any other person: to do so could be a breach of confidence.
* 
* 
* 
* 
* 
* 
* ------------
* This e-mail and any attachments are confidential.  If you are not the
* intended recipient, please notify us immediately by reply e-mail and then
* delete this message from your system. Do not copy this e-mail or any
* attachments, use the contents for any purpose, or disclose the contents to
* any other person: to do so could be a breach of confidence.
* 
* _______________________________________________
* Mantisbt-dev mailing list
* Man...@li...
* https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
* 
* -- 
Carpe Jugulum