Hi Chris, I think you are right, standardization is the first step in making code more compatible. The problem I see is that all the open source projects would need to adopt these standards to be usable in conjunction with other projects simultaneously. In other words, they need to create an API to control the site. These API functions could be called from your web site's controller to incorporate the data like portal widgets. Of course the data could make up the entire content for your web page also if you wanted.
For those of you who don't know what a Model-View-Controller approach to coding, here is a brief overview of each component: 1) The Model component is the abstraction of your persistent data. Usually data is stored in a database, but the Controller doesn't care since it is only calling exposed functions in the Models that you have created ( like $user_model->get_user_name(); ). 2) The Controller component is the where the work is done. All data processing is performed here, security checking, etc. All data is then prepared for the View and passed off to the View layer. 3) The View component controls how the data is presented to the user. In theory you could have different View modules that could output the same data as a normal HTML page, a PDF, or just text. Separation of content (HTML) and presentation (CSS), is key to project integration and most projects are moving in that direction if they are not already there. Microformats will help standardize the HTML, but more would be needed like a microformat for navigation, breadcrumbs, etc. A common set of functions (API) would make integration much easier. As James had mentioned you could write your own, but as new releases of the projects are rolled out you would need to update all your hooks into the project. A sample API could be: Boolean $project->login(username, password); Boolean $project->register(username, fields); Boolean $project->authorized(username); String $project->get_title(uri); Array $project->get_stylesheets(uri); Array $project->get_scripts(uri); Xml $project->get_content(uri); The XML that is returned by the get_content function could be XHTML (starting after <body> and ending before </body>) as long as it followed a standard format. Since I wanted to use the functionality of open source packages (like WordPress, ZenCart, etc.) now, I took a different approach. I installed these packages in my web site, but created a function that emulated a browser on the server. By acting as a browser, I could retrieve the HTML from the project and pull out the pieces I needed, like the stylesheets, scripts, and content. My first version also rewrote the links so that links would always go through the controller. You can see an example of a web site I created that used this technique here: http://www.dreamalittlegarden.net . That web site is using ZenCart, ZenPhoto, and WebCalendar. The URLs are hideous and I have a new version that doesn't require URL rewriting by using the apache mod_rewrite module. There is so much good open source software out there. I wanted to be able to have as close to a plug-and-play way of adding these projects to a web site without a lot of work. My approach is not ideal as I mentioned before, but it works well and gives the web site a consistent look and feel. Well there is my 2 cents on the subject. Regards, Kepler Gelotte -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Taylor Sent: Friday, July 13, 2007 5:19 AM To: [email protected] Subject: RE: [WSG CMS] Selecting CMS Really interesting thoughts, Kepler. Perhaps what we need is a standard CMS framework that separates the site from the content in a cross-application manner. In other words so people can move the content and structure for their site to another CMS (from Wordpress to Joomla, Mambo to Drupal etc) with little bother depending on the functionality they need. Quite how that would work I have little idea, though. Do some CMS's provide an "import" facility? Chris ************************************************************** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] **************************************************************
