Chapter 3 [ 63 ] Structuring content within our framework We could go ahead now and implement a data structure and functionality to display products and categories within our framework; however, if we did so at this stage, we would lose out on a lot of potential exibility. Most content displayed on any website or contained within any web application has some common data. If we nd this common data, and create an abstract content type, then we will have a more exible framework. This is because we could easily integrate additional functionality to each of these content types without the need for duplicating the functionality or the code. Such additional functionality could include: Various versions of content Access permissions Commenting on content, pages, or products Rating pages or products, or other content Pages Pages are an essential type of content. Even if we were creating a website, which was just to be an online store, we would still need some standard pages, for contact details, delivery information, terms and conditions, and privacy policies among other things. So, what data might we wish to store for pages? Data Description ID A reference for the framework to refer to the pages Name The name of the page S.E.F. Name A search engine friendly name for the page to be used in URLs Heading A page heading, generally something we would store within an <h1> tag Title A title of the page (displayed within the <title> tags of the page) Content The content for the page Keywords Metadata for the page—keywords Description Metadata for the page—description Content Pages are the most fundamental content type we would need, and most of the elds required are shared throughout most of the data we would store. Product categories could operate using the same data as a page; however, products and other advanced content types would need more data, and we would extend the data stored for these content types. • • • • This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010 953 Quincy Drive, , Brick, , 08724 Products and Categories [ 64 ] Data Description ID A reference for the framework to refer to the content Name The name of the content entity S.E.F Name A search engine friendly name for the content, for use within URLs Content The content itself, for example page, product details, and category description Type The type of content this content entry is (for example page, product, category, and so on) Order The order of the content within a group, for example pages in a menu Parent The parent element for this entity, useful to indicate subproducts and subpages Meta keywords Metadata (keywords) for this content entity Meta description Metadata (description) for this content entity Date created The date the content entity was created Creator The user who created the content Active If the content is active (publicly visible) or not Secure If the content requires the user to log in to see it (doesn't take into account ne-grained permissions) Versioning To effectively manage versions of content, we need to keep the ID and some other aspects consistent, while still maintaining different versions of our content. We can do this by keeping a reference to content and the version of the content separate, and maintaining a record of previous versions, to allow us to roll back to a previous version should we need to. So, the content we discussed earlier would actually be a version of content, to reference the active version of content we would need to also store: Data Description ID A reference number for the framework to refer to active content Current revision The active version of the content This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010 953 Quincy Drive, , Brick, , 08724 Chapter 3 [ 65 ] Building products, categories, and content functionality into our framework Now that we know the data we need to store, we now need to think about exactly how we will store this data, and how we will manage and access it from within our framework. Database The rst stage is to design the relevant database tables. Then we can develop our framework to query the database and render the relevant data. We know roughly the data we need to store for each of our content types which we have discussed; let us now translate that into a database structure. First, let's review what tables we will need in our database: Table Description Content To store references to the active version of content as well as some information on content that doesn't change with each version (for example, initial author) or things that can change without affecting the version (active/secure toggles) Versions To store the actual content data, one record for each version of content Content types Record the types of content in the framework, relating to content entities to refer to the type of content they are (for example, page, product, category) Products An extension of the versions table for product-specic data; when combined with the appropriate version's record, this makes up the product data Revision history Maintains a history of revisions and their content entities, allowing us to roll back to a previous version, should we need to Content All of the content within our framework will stem from a standard format; however, as we may also wish to take advantage of versions of content, this is where we must start: a table where the records relate to the active version of content for particular content elements. So, if for instance we have three pages in our database, and two products, these would have a record in the content table. There would also be a record in our revisions table for each revision of that content. The ID of the content entry in the database will never change, and this entry maintains a relation to the active record in the revisions table. This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010 953 Quincy Drive, , Brick, , 08724 Products and Categories [ 66 ] This table requires the following elds: Field Type Description ID Integer (Primary Key, Auto Increment) A reference for the framework to refer to the content entity by Current_revision Integer A reference to the current version of this content entity Active Boolean Indicates if the content is active or inactive, and thus if it should be shown to users Secure Boolean Indicates if the content is secure or insecure, and thus if the user must be logged in before they can see the content Parent Int A reference to the parent content item, if appropriate Order Int A reference to the order of the content (where appropriate, primarily used for pages, to automatically build menus and site maps based on structure) Author Int A reference to the user who created the rst version of this content entity Type Int A reference to the type of content this entity is, for example page, product, and so on Path Varchar Search engine friendly reference for the page, product, or other type of content, for example pages may be accessed by ourwebsite.com/ the/content/path, whereas products may be accessed by ourwebsite.com/products/ view/the/product/path Created Timestamp When the content entity was created The SQL for this table is as follows: CREATE TABLE `content` ( `ID` int(11) NOT NULL auto_increment, `current_revision` int(11) NOT NULL, `active` tinyint(1) NOT NULL, `secure` tinyint(1) NOT NULL, `parent` int(11) NOT NULL, `order` int(11) NOT NULL, `author` int(11) NOT NULL, `type` int(11) NOT NULL, `path` varchar(255) NOT NULL, PRIMARY KEY (`ID`), This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010 953 Quincy Drive, , Brick, , 08724 Chapter 3 [ 67 ] KEY `current_revision` (`current_revision`,`active`,`type`), KEY `type` (`type`), KEY `author` (`author`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Content Elements Table' AUTO_INCREMENT=1 ; The table should have the following references to foreign keys: ALTER TABLE `content` ADD CONSTRAINT `content_ibfk_10` FOREIGN KEY (`type`) REFERENCES `content_types` (`ID`) ON UPDATE CASCADE, ADD CONSTRAINT `content_ibfk_8` FOREIGN KEY (`current_revision`) REFERENCES `content_versions` (`ID`) ON UPDATE CASCADE, ADD CONSTRAINT `content_ibfk_9` FOREIGN KEY (`author`) REFERENCES `users` (`ID`) ON UPDATE CASCADE; Content types Because we are going to store all content centrally within a few set tables, we also need a way to reference the types of the content, for example if the content is a page, a product, a category, or something else. Field Type Description ID Integer (Primary Key, Auto Increment) An ID to be referred to by other tables Reference Varchar A machine-friendly reference string for the type, since we can't assume all products have a type of ID X, but we can assume they all have a type with a reference which is "product" Name Varchar A user-friendly string to represent the name of the content type The SQL for this table is as follows: CREATE TABLE `content_types` ( `ID` int(11) NOT NULL auto_increment, `reference` varchar(15) NOT NULL, `name` varchar(25) NOT NULL, PRIMARY KEY (`ID`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010 953 Quincy Drive, , Brick, , 08724 . int(11) NOT NULL, `path` varchar( 255 ) NOT NULL, PRIMARY KEY (`ID`), This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010 953 Quincy Drive, , Brick, ,. and is licensed for the sole use by jackie tracey on 23rd February 2010 953 Quincy Drive, , Brick, , 08724 Chapter 3 [ 65 ] Building products, categories, and content functionality into our framework Now. TABLE `content_types` ( `ID` int(11) NOT NULL auto_increment, `reference` varchar( 15) NOT NULL, `name` varchar( 25) NOT NULL, PRIMARY KEY (`ID`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1