[Rainbowportal-devel] RE: 1.6

[William F. <WF...@im...>]

Hi,
=20
I will send you the word doc I'm working on that explains the layers.
Basically when we are done it will provide you with something like this:
=20
Active.Portal.* (* =3D all properties about the active portal.  if you
assign to it it automatically persists changes to the database)
Active.Page.* (same idea...)
Active.Module
Active.Module.Items
=20
I am working on the Module base classes right now.  I got some of the
Portal object done and the Page ones are going to need a lot of help.
You see, each layer (you'll see how they are setup in the word doc) has
its own set of these Page, Portal, Module and Item objects.  From the
Rainbow.UI.Web layer the Page load will query the database for current
portal alias and that sets up the Active objects.  Once they receive the
portal and strip out the Page properties from the querystring & post
vars the Active class will have a lazy loaded way to access information
about any object in the framework.  The data layers handle persistence
to the database/xml files automatically.
=20
I am also adding enterprise library config block to the solution so that
we can have a nice unified way to manage the config files (not to
mention we can have someone build a nice designer class for them so we
can use the enterprise library config tool (GUI).  So aside from the
objects I listed above you can do this too:
=20
Active.Portal.Page.Module.Items[index].ToString(); //gets at the item
value in there, though it may change a little since I am still working
on the Module and Item classes.
=20
Also you can do this...
Portal(Id).Page(Id).Module(Id).Items[index].ToString(); to pull it for a
different portal/page/module/etc than the current active instance.
=20
Once all this is in place it will rock because we will have very easy
access to all the properties/config/variables on all objects.  All
objects are serializable to xml as well and after we get it all working
I may write a data provider for xml file storage for the
portal/page/module layout & admin properties.  Module & Item content is
probably best left to a database but it could be xml'ified too...
=20
Other benefits include easy backup of portal data down to the module
item level (simple task to write a backup module after the core is
done).
=20
I do have some cleanup tasks if anyone wants to jump in.  You need to
understand how the different projects/layers interact before you pitch
in though because much of the work to be done involves splitting and
cleaning up things into the different layers.
=20
Anyone interested in helping out email me and I will see what we can
pass you to do.  If you aren't comfortable with the current 1.5 core and
base classes maybe mail manu and see where he can fill you in at...


________________________________

From: Jonathan Minond [mailto:jon...@jo...]=20
Sent: Wednesday, March 23, 2005 11:16 PM
To: William L. Forney
Subject: 1.6



Hi Bill,

=20

I have tried to find myself understanding 1.6 better, but I am sorry to
say I am a little lost on it. I don't understand the unified data layer
so much, I mean I know what  DAL is, I've created and used them both on
my own and with RAD tool like LLBGEN, but I am a little newer in these
areas. Maybe you could give me some links to online articles, or help as
so that I can begin to get a better understanding of what you are doing.
I feel it is important for me to know where you are going on this,
because of all the work I and others are dedicating now to modules
Improving/Enhacning/Adding new ones. Some of it involves working on the
core as well and some hits DB. I want to try to manage all this work as
smoothly as possible with what you are doing.

=20

- Jonathan