Some issues I've encountered and the approach I've been working toward in this arena....
First off, In my site modeling, there's "natural order" and the "cross-referencing". Natural order is what you'd expect when people start talking about object/page trees and so forth -- it's the expected path of navigation. Cross-references are shortcuts that express alternative relationships between tree nodes. Conceptually this is great, but I'm having a bear of a time coming up with an efficient way to do this. Currently the core of my database schema looks like this: Nodes - ID - Date_Created - Date_Modified - Status - Type Node_Relationships - ThisID int(2) - ThatID int(2) - RelationshipType which should let me represent both the Natural Order relationships and the Cross Reference relationships. Objects are further defined by tables that are particular to that object. In terms of OO-speak, the Nodes table represents the generic superclass, and node-type specific tables are subclasses. I have also been exploring the use of RDF in my architecture, not so much for data storage so much as for data specification. Namely, I've been working on a system that lets me define resources (objects), how they relate to other objects, and how they're represented in the database. The code uses a parse & cache scheme so that the RDF only has to be parsed once, and can then build sql queries for resource requests,updates and deletions. I have a working example at www.towngreens.com (uses TT too ), and while it works, I'm unhappy with some of the limitations of my first implementation, so I've gone back to the drawing board. Unfortunately this work has been moved down the priority ladder as billable work has come in the door. I'd gladly use it for client work but getting it done is time/cost prohibitive at the moment. -Stephen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jonas Liljegren Sent: Thursday, October 18, 2001 08:30 AM To: Andy Wardley Cc: Brian Hann; Perrin Harkins; [EMAIL PROTECTED] Subject: Re: [Templates] Template::Docset (was: Web-site creation and management system) Andy Wardley <[EMAIL PROTECTED]> writes: > There's something I've been working on that might be of interest in > this discussion of CMS. Your document system model is similar to what I am thinking about now. Design ------ I want to look at a website as an object tree. Some objects will have a collection of subobjects that you can switch between. And some objects will be linked. I wan't to represent the whole website. How do I represent the nodes (objects / parts) in a way that works with navigation? How to do navigation depends on some things: - Navigation object and viewport in same frame - Navigation object and viewport in diffrent frames - Navigation object reflects viewed page - Navigation object doesn't reflect viewed page My idea is that the object tree should be the same regardless of if you use tables or frames for the site layout. But the generated pages will differ. The page generation engine must know where to create framesets and there to include objects in table cells. The other thing I'm thinking about is that pages should not have a direct coupling to a container. Pages should have metadata and those metadata should be used for viewing selections of pages. It's the inverse of placing pages in docsets. Example of object tree: Web site (title=company_name) Main background (bgimage=logo) Center part (width=640, height=440, align=center, valign=center) Menu (height=40, valign=bottom) Main Infoblocks (align=right, width=200) Viewport The "Center part" should apear in the middle of the browser. Either using tables or frames (frameset with 5 frames). "Menu" could be frame or table. The same for "Infoblocks". Case 1. Let's say that all but 'Main' are frames. "Infoblocks" and "Viewport" are two columns in a table. A selected page from the Menu should change the Viewport content, but not the Infoblocks. The Menu should change to a page indicating the selected page. The page generator could do this by either generating a frameset for each page (including the same Viewport) along with the menu page. Another method would be using javascript for changing both pages. Or using a menu that doesn't have to be reloaded. Case 2. If only the Center part is a frame and everything in the Center part is done with tables, the page generator would not have to create more framesets. And the target for the menu items will differ. Content ------- In most cases, the site creator will place a page in a section and have a menu pointing to that section. And a submenu will show up either in the meny object or as a separate menu coming up with the section. But I would prefer to just asign metadata to the documents. Saying "the Parent of Document1 is Section1" and "the Parent of Section1 is Top". And the menu would just list all childs of Top. That would be just the same as a normal tree (excpet it's backwards). But the important thing here is that you could have more things than just Parent. Browse by publication year, author, status or something else. Diffrent parts of the website, or even diffrent pages, could have diffrent desing. Let's say that that Infoblock section (containing news, search form, extra links, etc) should appear on most pages but not in the archive or contact page. The object target for the menu would be Main rather than Viewport. (But the object would be placed in Viewport.) The Infoblock object should have a property saying "I'm a foobar". The Document should have some other property "I'm a foobaz". The design tree would look like: Web site (title=company_name) Main background (bgimage=logo) Center part (width=640, height=440, align=center, valign=center) Menu (height=40, valign=bottom) Main (collection) Main1 Infoblocks (align=right, width=200) Viewport Main2 Viewport And some rule saying that the template for foobaz is Main2. Something like that. Oups. Looks like I'm thinking RDF again. :-) How do we solve navigation in a site looking like this? Most web-site desings has some combinations of the parts described here. The menu, top framing, footer, infoboxs, more menues, et al, can be placed top, bottom, left, right or inline. Using frames or tables or maby popup boxes. But the object heiarchy should be the same regardless of the technique and placing of those objects. More or less. Help me now. :-) -- / Jonas - http://jonas.liljegren.org/myself/en/index.html _______________________________________________ templates mailing list [EMAIL PROTECTED] http://www.template-toolkit.org/mailman/listinfo/templates
