[kforge-dev] plugin system overview

[John Bywater]

Rufus -

Could you send me the source for this diagram?

I wanted to adjust it to:

(a) clarify that the vertical dimension of concern is the n-tier 
architecture: roughly: presentation, command, domain, persistence

(b) clarify that the horizontal dimension of concern is roughly: left to 
right: KForge "core" packages, adjacent to this is the KForge core 
system extension mechanism ("the plugin system") package, and then 
adjacent to the plugin system are the concrete extensions.

So, in short, it makes more sense for the "Zz" entities to be to the 
right of the plugin entities. The label "DOMAIN OBJECTS" should be to 
the left of the diagram, and in its place it would be better to have 
"KFORGE CORE".

I probably wouldn't indicate persistence on a diagram of the plugin 
system. I would probably either create separate diagrams to indicate how 
domain objects are persisted.

I do think there is value in creating some nice UML diagrams for this, 
not least to encourage more serious developers to the project. Perhaps 
I'll give ArgoUML another spin. I think the pain of its destroying my 
diagrams a few years ago has worn off. Mostly. But perhaps the best 
thing is to stay with these ASCII diagrams. I think they are adequate 
for communication purposes. However, pucker UML would have a certain 
flashness.

Could you send me the source? Or perhaps put it in the repository? I bet 
you already have. ;-)

If so, could you let me know where? And what I use to edit it with?

All the best,

John.



Rufus Pollock wrote:

>              DOMAIN OBJECTS                      |      PLUGIN SYSTEM
>                                                  |
>              +------------+                      |
>     +----- |>|DomainObject|<|----------+         |
>     |        +------------+            |         |
>     |         A    A                   |         |
>     |     _.--'    |                   |         |
>     |     |  +-----------+   +----------------+  |  +------------------+
>     |     |  |  Service  |   |     Plugin     |  |  |      Plugin      |
>     |     |  |-----------|   |  (dom.Plugin)  |  |  |  plugin.Plugin   |
> +-------+ |  |name:    xx|   |----------------|  |  |------------------|
> |Project|--<>|project: yy|   |    name: zz    |<----|getDomainObject():|
> +-------+ |  |plugin:  zz|<>-|  getSystem():  |  |  |    dom.Plugin    |
>           |  +-----------+   |plugin.zz.Plugin|-+|  +------------------+
>           |                  +----------------+ ||              A
>           |                                     ||              |
>           |                                     ||              |
>           |                                     ||   +-----------------+
>           |                                     +--->|     Plugin      |
> +---------+         +-----------------+          |   |plugin.zz.Plugin |
> |ZzProject|*       1|ZzProjectRegister|          |   |-----------------|
> |---------|---------|-----------------|------------<>|    register:    |
> |         |         |                 |          |   |ZzProjectRegister|
> +---------+         +-----------------+          |   +-----------------+
>                                                  |
>                                                  |
>                                                  |
> -------------------------------------------------|
>                         |                        |
>                         |                        |
>      PERSISTENCE        |                        |
>         LAYER           |                        |
>      (kforge.db)        |
>                         |
>                         V  Database/Flat File/...
>                     ,-------.
>                    (         )
>                    |`-------'|
>                    |         |
>                     `-------'
>
> Notes
> =====
>
> 1. For brevity many of the class names above have kforge missing at 
> the front. For example dom.plugin should be kforge.dom.plugin.
>
> 2. The above shows a complex setup where a plugin needs to persist 
> data of its own. This is the situation, for example, for the trac 
> plugin which needs to remember which subversion repository it is 
> using. In simpler plugins (for example svn) this is not needed and in 
> that case the lower two items on the left of the figure (ZzProject and 
> ZzProjectRegister) will not exist.
>
> 3. For a higher level overview of the kforge system see:
>   http://scm.kforge.net/svn/kforge/trunk/docs/kforge_system_overview.txt
>
> 4. How to create a plugin:
>   1. Create Plugin class for your plugin:
>     1. a file <pluginname>.py (and corresponding test case) in 
> kforge/plugin directory. Easiest way is to copy and paste example.py
>     2. define class Plugin in your new plugin file inheriting from 
> kforge.plugin.Plugin. Override whatever event handlers you need to
>     3. Run tests
>   2. Now create plugin instance in kforge system by running:
>     bin/kforge-admin create plugin <plugin-name>
>
> _______________________________________________
> kforge-dev mailing list
> kforge-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/kforge-dev
>
>
>