Thread: [Rainbowportal-devel] RE: 1.6
Brought to you by:
danijel_kecman,
manudea
From: William F. <WF...@im...> - 2005-03-24 07:43:09
|
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 |
From: William F. <WF...@im...> - 2005-03-24 08:04:21
|
The core modules and anything that modifies or reads the core tables may need a rework later. We will most definitely have to change the admin stuff anyway. The new design has a slightly different approach to how it "deletes" things. There is no actual deletion (except in a new recycle bin module not created yet). Things just get disassociated from their pages/portals. if you delete a page it just deletes a line from a relation table that holds PortalId, PageId. And the other table that holds PageId and ModuleId... something like rb_PortalPages and rb_PageModules. This lets us easily place a single module on any page in any portal. And to "delete" it we just remove the mapping, not the actual module. the recycler will just show any module/page that doesn't have a mapping entry in those tables and allow you to then delete that actual data. This is the biggest change so far aside from the class name changes. The old PortalModuleControl class will be available as just a class derived from the new Module class and will be altered to provide hooks into the new API for the old methods. This way module creators won't have to change anything to use older modules. ________________________________ From: Jonathan Minond [mailto:jon...@jo...]=20 Sent: Wednesday, March 23, 2005 11:54 PM To: William Forney Subject: RE: 1.6 As far as current core, and config I am pretty comfortable. But like I said, my focus at least for now, is on the modules. I figure ill leave the core to you boys who know better. My goal here is to manage the development on the modules as best I can without having to think about reworking when 1.6 comes in. Hopefully the word doc will give me a better grasp of this.=20 One main area that I am looking at is the page manager ( this is very high priorty ). For example, this directly works with TabsDB today, which you said would be no longer. This to me is then a scary place to be, because we don't want to do something, that in 6 months would need a total workover to upgrade to 1.6. From what you said, I am not to worried about most the modules I touch then, because as you mentioned, they will stay in DB, there effect would come more from the use of Active.Portal, Active.Page, Active.Module but once again, here this might mean a lot of code changing later on. Now, since you seem to be mainly on core, it seems likely that anyway, at some point we will have to run thorugh all the core modules and address any changes/benefits the new data layer and core layers would bring. Ill wait for the doc then so I can look it over, and if you have any concerns/advice/ or comments about what I should consider since I am already delving into the modules, it might be a good time to lay some grond work for easy upgrading when you/we/rainbow team gets to that later. =20 - Jonathan - =20 =20 ________________________________ From: William Forney [mailto:WF...@im...]=20 Sent: Thursday, March 24, 2005 9:35 AM To: Jonathan Minond Cc: rai...@li... Subject: RE: 1.6 =20 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... =20 ________________________________ 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 |