This will be pinned until mid April. This is a place to discuss the architectural differences between the GCN and other similar systems. It is also a place to explore how to make the GCN better and incorporate best practices from other apps.
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
To Answer KFarmer's Question: >> Could you elaborate on the framework Omniportal uses? (eg, where the source data for the DAL is, module structure, page rendering, etc?)Soruce Data:
CVS Data SourceDAL:
CVS DAL Folder It works by setting up a mapping in the
Web.Config file which is then stored depending on the type of database that is also selected in the Web.Config file. Then through the use of the ProviderFactory you can create data object and use them how ever you want just like a normal ADO.Net object.
DataSet ds; using (ProviderFactory f = new ProviderFactory()) { IDbDataAdapter adapter = f.CreateDataAdapter("select * from MyTable where x = @x"); // input adapter.SelectCommand.Parameters.Add(f.CreateParameter("@x", DbType.String, "xyz")); // retreive data
ds = new DataSet(); adapter.Fill(ds); } // work with dataset here By using this it allows me to effortly switch between databases with out any problem. The ProviderFactory will also convert @variables to a "?" to support Access databases.
Page Rendering Page rendering works the same way as it does in GCN. (DesktopPage.cs)
Module Structure A good example of how Modules work can be found at
OmniPortal Module Layout. Source code for many of the modules I wrote can be found at
CVS Module Source. With the current way my structure functions you can use virtual page names for anything. Such as if you want to point to an article instead of doing the normal Article.aspx?id=1234 you can handle the following 1234.aspx with out an problem
at all. In addition to that many of the things that were not originally supported in CSK are supported in my implimentation like QueryStrings. This is made possible because I am not changing how the HTTP protocol handles an address I am just useing it to my
advantage. If you would like to see this in action you can try the following URL's
http://beta.omniportal.net/Default.aspx/About/Default.aspx and
http://beta.omniportal.net/Default.aspx/About/Default.aspx?trace=true and
http://beta.omniportal.net/Default.aspx/About/?trace=true If you have any other questions just let me know. I think these are all features that GCN can benifit from.
Yeah I was able to get it. I definitly think we can do the module transition over to my portal. You all can download a copy of my software at http://sf.net/projects/omniportal . If you have any questions please let me know.
Thanks One thing that has been frequently requested is support for non-SQLServer/MSDE databases. In the GCN workspace, you ought to be able to find some notes I wrote up on a new DAL for GCN, which allows for db-specific queries, as well as versioning and update
of stored procedures for those databases that support them. It also prevents hardcoded SQL from infiltrating the source code, making it easier for people to add support for their database-of-choice without having to have access to a compiler. It may be something
to add to Omniportal as part of this effort. I just haven't had time :P
KFarmer, I haven't run into any problems, because everything I am doing is done with basic SQL that everybody supports. When I get anything more advanced that has to be done I have worked with the object and got back a DataTable and then cached it for next
time that it has to be used. You may want to check out the custom CacheManager that I created it makes caching very easy to use and it can be adjusted for timeouts and sliding or strict expirations in the Web.Config file. So say in the Web.Config file the
value is set to 30. And strict is on. That means the site will go and get new values and update the site every 30 mins unless refresed by some other process. Also since my dataset is cached, there are almost no calls to the database from the core, until refreshes
are called. This has been a great method because the core database is small and really doesn't contain all that much data so caching is very easy and doesn't use alot of memory. The real data pretty much comes from the modules and then the Module Developer
has to figure out how they want to handle things. Also with the method of caching the dataset I am able to also support a XML DAL, granted the modules wouldn't work unless their developer designed them this way or they are calling another database. but the
XML DAL is my next small project, I realize it isn't a great solution, but it is one of those features that you can say hey look at what we can do.
KFarmer, I was wondering if it was possible to start talking about intigration of the two projects. This is the way that I envision how we could merge the two projects. I would really like to keep OmniPortal (the Core) seperate from the display interface. So
maybe we can form two projects one called OmniPortal, which would just be the core, and then one which would be GCN or the upper level display that had the plug-ins for Authentication, Modules, Portlets, and Themes. This method has many advantages, because
it allows the two projects to be developed seperatly from each other so that one part doesn't force the focus of the other part. Because I have noticed that alot of projects will change the central core of a project to fix some minor display issue that could
have been fixed with out messing with the core and thus messing with the entire project. Also I want this to happen because I would eventually like OmniPortal working on Mono and I don't want the focus deviated by GCN, which could be the Windows display environement
for the OmniPortal core. I think this is a good plan of action because currently many of the things that you have complimented OmniPortal on are a part of the inner core and really don't effect the display. Many of the things I like about GCN are the modules,
themes, portlets and the large community using it, which are all part of the display layer. Please give me your thoughts on this. Nick
This is actually in parallel to what we've been thinking as well - bring a true seperation between the CSK Engine and the CSK Presentation layers. Sounds like we are all thinking in the same direction. Now, to start getting details on these thoughts! ;-)
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
That sounds great, if there are a few people that you can recommend I can add them to my project and we can start working on both parts. Then when GCN is ready to do the split we can move half of it over.
What details did you have in mind. I have a development forum setup if you guys want to start using that to hammer out the details. It is at
omniportal.sourceforge.net.
I have created a forum just for this discussion so we don't have to hammer anything out in one thread because there are probably going to be many issues. The forum is at
Merger of GCN and OmniPortal. Please let me know what you think of the few recommendations that I made, currently they are at a high level but as we get things going we can start working down
to the lower level of the code.
StarPilot, Tell me what I can do in the mean time? Until we can start talking about the merger of the two projects -- is this something that you guys still want to do? In my last post to the topic that was looking for ideas for GCN 1.2. I stated that we start
thinking about how we want to focus GCN in the future. In addition I would like to keep OmniPortal (the core part) as more of a framework that is focused on what the developer needs. Then you can focus GCN more on what the consumer needs (i.e. great user interface,
plenty of modules, etc.). Does this sound like a valid way to go? I saw that Tim expressed his concerns about the need for support for anything outside of the SQL2000/Windows environment. I totally understand where he is comming from, but if we want to get
GCN out there in the wild we need to support a market that isn't currently being tapped by any portals and that is the Access/Windows environment. There are plenty of people on Brinkster that would love Access support because they just want a personal site
for their own use. I have talked to many of these people. Some of them are artists that want to post drawings but don't have the funds to shell out for a host that supports SQL2000. I have a few questions that I hope some people can reply to: - If you could
have GCN work on any environment (Database/OS), what would it be? - Do you like the idea of splitting GCN into a core and display layer? Will this add anything to the product? - Do you think that GCN should be focused on the consumer (easy setup, good GUI,
etc.) while OmniPortal should focus on the developer (flexible framework, easy module creation, etc.) -- if the two projects were to merge? Thanks in advance to everybody that answers those questions. Nick
Another wish... Separation of Modules In particular, it would be nice to see each module as its own assembly, with a unique ID. This would go a long way to plug-and-play capability. Someone could write a module loader based on any one of several examples
floating around MS and CodeProject. Separation of Skins Could the skin handler be rewritten such that skins are no longer embedded with the rest of the web project? They strike me as out of place, and it's interfering to have other people's (optional)
skins part of a (required) project that I need to compile. I also think it'd align itself better with Whidbey's Theme architecture, but that's just me. To that end, I'd add a new project for each module and skin. Granted, that's still just me..
KFarmer, I feel like a tool everytime I repeat this phrase but, in OmniPortal those are already supported.
Modules OmniPortal searches all DLL's in the /bin directory for the ModuleAttribute. And that tells OmniPortal where the modules are, and then the modules are referenced by a GUID that is on the ModuleAttribute. So this GUID is the same across all systems.
Much like that of a COM object. Skins In OmniPortal skins are handled by inheriting already created controls. But they don't have to do this if they don't want to use the already designed functionality. So all of the ASCX files/themes/modules/portlets
are designed purposly to be seperated from their code. This doesn't have to be done you can create a normal theme and compile it your self and drop it into place. I have started getting e-mails from people that want to use the system, but find it cumbersom
because of the dull interface that is included. Most of these people are interested in the Access DB support. I am going to post an e-mail after this post. To show other people and Tim that there is a need for cross-DB support. Nick
Hi Nick, Thanks for your reply, and helpful outlook generally speaking! I have installed Omniportal on 2 machines, one with Web Matrix's own .NET web server, and another one with IIS 5 /.NET 1.1. (latest MDAC/JET to be safe). I am having some difficulty with
the learning curve associated with all your class abstractions, and the pretty slim documentation, however I understand that you have undertaken a monster project, so this is not a criticism... besides, I am not an expert yet with .NET, so my opinion here
is pretty humble. I have done extensive research, like I told you, on portal systems written in ASP.NET and compatible with MSACCESS (since a lot of hosting ISPs out there, including mine, Korax.net, do not provide SQL server support), and yours is practically
the only realistic alternative. However, like I mentioned, I am not sure if I can undertake this integration by myself, considering I have to produce a real website/community at the same time. Here are a few comments/questions that have emerged so far in my
playing around with Omniportal: - I am running across a lot of update errors in the admin section, all of them being of the "query is not updatable" type (yet, some operations do in fact get saved to the database)... any ideas why? - you use mostly URL transforming
techniques to display site sections, both in the default.aspx files and various module.config files. will this mode be compatible with a server where I don't have access to the IIS config console, and custom HTTPhandlers ? I seem to think that the answer is
yes, since the handling is done exclusively via the default.aspx, and them processed by your own omniportal.custom classes... - Will section such as forums, newsletter/email lists, etc be easy to implement without possessing your knowlegde of all the omniportal
classes? I hope my questions aren't too silly and won't waste too much of your time :) Thank you, Nick. Thierry
kudos on the module separation, but the skins in csk/gcn are also as you described. the problem is actually one of project organization, I think, not architecture. I sent you email a couple days ago pointing to the dal design that I'd been thinking of off-and-on.
Did you receive it?
Member
30 Points
241 Posts
ASPInsiders
Architecture [GCN 1.2] - A discussion
Jan 20, 2004 09:34 PM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 20, 2004 10:03 PM|nberardi|LINK
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 21, 2004 08:48 AM|nberardi|LINK
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 21, 2004 09:26 AM|nberardi|LINK
DataSet ds; using (ProviderFactory f = new ProviderFactory()) { IDbDataAdapter adapter = f.CreateDataAdapter("select * from MyTable where x = @x"); // input adapter.SelectCommand.Parameters.Add(f.CreateParameter("@x", DbType.String, "xyz")); // retreive data ds = new DataSet(); adapter.Fill(ds); } // work with dataset hereBy using this it allows me to effortly switch between databases with out any problem. The ProviderFactory will also convert @variables to a "?" to support Access databases. Page Rendering Page rendering works the same way as it does in GCN. (DesktopPage.cs) Module Structure A good example of how Modules work can be found at OmniPortal Module Layout. Source code for many of the modules I wrote can be found at CVS Module Source. With the current way my structure functions you can use virtual page names for anything. Such as if you want to point to an article instead of doing the normal Article.aspx?id=1234 you can handle the following 1234.aspx with out an problem at all. In addition to that many of the things that were not originally supported in CSK are supported in my implimentation like QueryStrings. This is made possible because I am not changing how the HTTP protocol handles an address I am just useing it to my advantage. If you would like to see this in action you can try the following URL's http://beta.omniportal.net/Default.aspx/About/Default.aspx and http://beta.omniportal.net/Default.aspx/About/Default.aspx?trace=true and http://beta.omniportal.net/Default.aspx/About/?trace=true If you have any other questions just let me know. I think these are all features that GCN can benifit from.Member
30 Points
241 Posts
ASPInsiders
Re: Architecture [GCN 1.2] - A discussion
Jan 21, 2004 12:44 PM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 22, 2004 08:28 AM|nberardi|LINK
None
0 Points
87 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 22, 2004 03:53 PM|kfarmer|LINK
http://www.thuban.org
kfarmer@thuban.org
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 22, 2004 04:37 PM|nberardi|LINK
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 26, 2004 10:49 AM|nberardi|LINK
Member
30 Points
241 Posts
ASPInsiders
Re: Architecture [GCN 1.2] - A discussion
Jan 26, 2004 04:17 PM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 26, 2004 04:34 PM|nberardi|LINK
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 26, 2004 04:36 PM|nberardi|LINK
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 27, 2004 09:59 AM|nberardi|LINK
Member
30 Points
241 Posts
ASPInsiders
Re: Architecture [GCN 1.2] - A discussion
Jan 27, 2004 10:37 AM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 28, 2004 04:02 PM|nberardi|LINK
None
0 Points
87 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 28, 2004 04:28 PM|kfarmer|LINK
http://www.thuban.org
kfarmer@thuban.org
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 29, 2004 07:21 AM|nberardi|LINK
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 29, 2004 07:22 AM|nberardi|LINK
None
0 Points
87 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 29, 2004 03:58 PM|kfarmer|LINK
http://www.thuban.org
kfarmer@thuban.org
Participant
792 Points
2233 Posts
Re: Architecture [GCN 1.2] - A discussion
Jan 29, 2004 04:44 PM|nberardi|LINK