Some comments added inline below….
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of manu
Subject: [Rainbowportal-devel] Current version - a way to close it!
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.
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?
I should receive an updated setup code to create db.
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?
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.