Some comments added inline below….

 

-----Original Message-----
From: rainbowportal-devel-admin@lists.sourceforge.net [mailto:rainbowportal-devel-admin@lists.sourceforge.net] On Behalf Of manu
Sent:
28 March 2003 18:06
To: rainbowportal-devel@lists.sourceforge.net
Subject: [Rainbowportal-devel] Current version - a way to close it!

 

Hi guys,

I’m really happy about new ideas for version 2, new data layer and so on.

For now I want to definitely close v1 so I just can relax and start thinking next version with ease.

 

These are my key points to resolve before closing v1, I need your feedback.

 

I have subdivided it in main areas to ease reading.

 

Localization

The localization is almost done for all core modules

We need a way to easily translate keys placed in db (can be an external app or a rb module) Ideas?

In an ideal world, this should be a module(s) – maintenance of culture/language options and data is definitely an Admin/Admin All activity. Manu – we had a long chat about this area (I still have the transcript – do you want it?) – are you looking for ideas beyond what we discussed then?

 

Setup

I should receive an updated setup code to create db.

 

Dll subdivision

Before closing v1 I want to split up the code base in 2 main areas:

Engine and web (like aspnet forums) – The engine is subdivide in mode dll (see attached schema).

I have already worked in this direction moving classes and namespaces.

See if it makes sense.

The only part that doesn’t “make sense” to me is the positioning of globalized Rainbow controls in a different DLL to “non”globalized controls – surely the long term aim should be to eliminate the use of “non”globalized altogether: therefore the globalized controls should be Rainbow.UI.WebControls and the “non”globalized controls should be treated as “exceptional”, e.g. Rainbow.UI.WebControls.NonGlobalized

 

Also, why not anticipate further subdivisions where we know they will exist? Like placing Security and Globalization into their own assemblies?

 

EditPages.

I was wondering if we should move to a common way for edit pages.

This can be:

1)       Transform current edit pages in modules

2)       Make a Desktopdefult like (DesktopEditPage.aspx?) thag get module id, item id and loads the control, this will imrove consistency

3)       Property too

4)       Add item

5)       View Item

I’m not certain that I understand the options you are presenting here, but my vote would certainly be for “everything as modules”

 

 

If you have any ideas about features to add or  bugs we need to fix before v1 is released let me know.

 

 

------------------------------------
Emmanuele De Andreis
Technical Manager
DUEMETRI
Internet Solutions Provider

RAINBOW PORTAL
Main portal -
http://www.rainbowportal.net
Sourceforge
CVS - http://sourceforge.net/projects/rainbowportal/
Support Forums -
http://www.rainbowportal.net/ASPNetForums