After getting some private feedback, I wanted to stress one point I made below:
The uninstall script should NOT UNDER ANY CIRCUMSTANCES delete the module table and related data without bugging the heck out of the administrator.  Table deletion and (SP deletion) should be optional.
Here's a likely scenario:
1) Sue downloads Rainbow
2) Sue loves Rainbow, except the Announcements module UI needs a little tweaking.
3) Sue copies all of the source to "My_Announcements", puts it into a hidden test tab, and starts to modify the code - she does this so users can continue to use the original Announcements functionality
4) Sue is finally happy with her new "My Announcements", which uses the same table data as Announcements so she moves it to a visible tab, and then maybe being the smart person she is, changes the ModuleID parameters in the Announcements table to push all existing postings from Announcements to MyAnnouncements
5) Sue says, - gee I don't need Announcements any more, let me just UNINSTALL announcements, oops
6) Sue is now really pissed off, because all of her user data is lost...
Although my name is not Sue (thanks mom and dad), the workflow in steps 1-4 is exactly the workflow I have followed for the past 6 months to modify the code on a live IBSpy site.  No, its is not an industrial strength workflow with dev and test servers, ...  but it is what I, and probably many others, do on a short budget.
There are other scenarios where 'smart, unpredictable Rainbow end users' will build new modules that summarize or collate data entered via some simple modules written by yet other people - i.e. Module A creates table A, Module B creates table B, Module C adds a lot of value by using data in Tables A and B.  If deleting Module A removes table A, Module C is mysteriously broken :(
My philosophy - Its better to leave lots of unused data in the database rather than risk deleting something important.  Disk is cheap, intellectual content is not.
 -----Original Message-----
From: Mark McFarlane []
Sent: Monday, April 28, 2003 12:59 PM
To: ''
Cc: 'Mark McFarlane'
Subject: TODO: For modules creators

I'll do items 2a-2d for the Discussion module.  Will be completed by May 5.
- Are there instructions/guidelines somewhere for creating:
1) the install/uninstall scripts
2) the XML install file
- Do core modules really need these scripts or are they just installed by default?
- What should an uninstall script do?
        Delete the stored procedures? 
        Delete the code files?
        Delete the module registration and all module instance data?
        Delete the pertinent tables and all their data? - this could be difficult because 2 modules could potentially access the same table. 
        Delete all data in a table associated with the module? - what about when someone extends the architecture so modules can share the same row data?
- How are the install and uninstall scripts evoked?
The module help is a great idea!  For end user help I suggest a ? icon in the module header.  It would be easy to add this to one of the base classes but modules need a way to disable it if they don't provide a help page - It really annoys me when I click on a help link only to get the message "Help not available for this topic".
-----Original Message-----
From: [] On Behalf Of manudea
Sent: Monday, April 28, 2003 10:55 AM
Subject: [Rainbowportal-devel] TODO: For modules creators

Hi folks,

I noticed we need some improvement on modules. Any volunteer?


  1. Provide a standard way for get help on a module from an user perspective
    1. Admin help (for portal administrator)
    2. User help (for final user)
    3. Custom help (a blank page that can be filled by admin for explain how use that module in that context)
  2. Provide old modules (those that are already on the core from long time) of:
    1. Install / uninstall scripts
    2. Install xml description
    3. Help
    4. Readme or jpg samples (as you like, not required)



All this task are no dependent each other so can be done from different persons.


Please reply to this mail saying what you want to do before actually start so other know that someone is working on it.

For start do not choose more than one task and provide an estimated completion date.

Thanks for you collaboration.




Emmanuele De Andreis
Technical Manager
Internet Solutions Provider


Main portal -
Sourceforge / CVS -
Support Forums -