Re: [Rainbowportal-devel] thinking about let modules talk to each other
Brought to you by:
danijel_kecman,
manudea
From: Mark M. <mar...@ho...> - 2003-09-11 00:45:09
|
Yiming, Many people, including myself, would like to see a standard mechanism for exchanging information between modules. Your idea of discussions attached to products/pictures/etc is a great technique to help build a community. Similarly, a rating engine could be built and attached to various items in other modules. If you search the mail list archive on this topic I think you will learn some of ideas and issues that have been raised in the past. (oops, I just went to sourcForge to give you the URL of the mailist list search page and it has dissapeared. SourceForge says the mail list is not being archived, anyone know what happenned here? http://sourceforge.net/mail/?group_id=66837) Anyway, hopefully we can recover this previous discussion. Since we are now such good friends with DNN, and want to share modules between platforms, does DNN have a mechanism defined for passing info between modules? Mark >From: "yiming" <xuy...@se...> >Reply-To: <ym...@ms...> >To: <rai...@li...> >Subject: [Rainbowportal-devel] thinking about let modules talk to each >other >Date: Tue, 9 Sep 2003 23:07:44 +0800 > >First, let's doing this by rainbow that we have now: >* I want to build a picture album, and let my friends add >comments on it >* I want to build a product list, and let customers ask about >them or buy them. > >They're basically same, just a "master/detail" app of database.. If we >can do it in rainbow. > >What do we do now? >1. we can add a page, and put a "pictures" module, and a >"discussion" module on it. >2. when Our friends/customers click and zoom a picture/product, . >it's an aspx, so they have to click "back" now. >3. they can add a comment or place an order, but since the >discussion module or "order" module is not linked with >the pictures module, they have to describe which picture/product they're >talking about on their own. > >What if we can do this? >1. add a pictures module ( or products module). >2. when user click the photo, the "pictureView" module is an ascx >, was placed in the coming page. >3. this coming page has 2 major modules: "PictureView" and >"discussions". >4. when we design this "pictureView" page with discussions, we >must let each module can have a "primary key", >and other modules in the same page can retrieve it by some way ( like >webservices can retrive interface by WSDL). >5. so, while we're changing the photos, the photovie module >transfer it's key to discussion because discussion asked for it. >6. now while we switching from photos, we can see the comments to >"this current picture" only( or orders to this product only). > >This mechanism can do many things, for example: we can put a search >criteria module and a chart module. While users input >conditions and click Send. The chart module will query database by >conditions of search module. > >Maybe you'll say, this is not a CMS(what rainbowportal is) should do. >But manu talked about some rad tools, and manu says >that he don't want to talk about "module(by purpose)", I assume that he >has same thought as me. > >1. we need to let modules talk to each other, and gain relations >between them, and give those relation behaviors. >2. I'm trying to draw a picture of classes like this, some of my >thoughts are not quiet clear yet, but I'm trying my best to tell it: > > I hope that this structure can do this: >* BaseData: define basic things only, connection, query >maker, fieldtypes, indexes and relationtypes. >* BaseBLL: give those properties which defined in BaseData >some behaviors (pickup, master/detail..), >* BaseUI: support different UI interfaces, like: simple HTML, >DHTML, Flash, PDA, WAP.., anything. >we should give a way to tell how should this module looked like, and >define default control of each kind of fields >(text, textarea, dropdown, checkbox, date, grid or form, tree...) >* there're many BaseUI classes for different >environment(html, dhtml, flash..), it's adaptable. for example, >if we're going to support ><http://www.infragistics.com/products/netadvantage_portal.asp> >Infragistics UltraWebControls, we can write another set of BaseUI >Classes to render our controls. >* <TableName>Data: inherited from BaseData, it has real >table, index and fields. >* <TableName>BLL: inherited from "TableNameData" and >"BaseBLL", >* <Tablename>UI: this is real rainbow module, which is >inherited from BaseUI and "TableNameBLL", it could be like this: >* ProductModule: inherit from BaseModule and ProductBLL >* ProductActiveModule: inherit from BaseDHTML and ProductBLL >* ProductFlashModule: inherit from BaseFlash and ProductBLL >Why do we need those Base Classes? Let me saying it simpler, "for >adaptive", we can talk more if you people are >interested. (again, we must do it after talking, sooner or later) >3. This structure is very complicated, so we need a RAD Tool, I >had surveyed some of them during last week. Including Kickstarter which >manu had mentioned about. >4. If we have a rad tool, we will not have to develop modules >anymore(well, it's not quiet true), why do I said so? >Cos' it will be a platform, if we defined data structures and give them >behaviors by default, >most functions that we need has been generated already. >We're not talking about "how many modules does rainbow has?" , >we're talking about "how do I make my own modules with rainbow?" >5. I don't know if this goal is too far away from the original >purpose of rainbow or not? And if it's what manu was thinking about? >6. I had talked too much these days, but I want to talk about my >survey about some rad tools, no more new subjects, I promise. >7. if you're interested, I hope you can visit these websites. >* Quickadmin >* Convea >* Kickstarter >* Infragistics. >* Macromedia > >Ps. I think I had sent previous mail twice carelessly, I apology for >that > _________________________________________________________________ Need more e-mail storage? Get 10MB with Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es |