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 Pag
Trang 1Structuring 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 flexibility Most content displayed on any
website or contained within any web application has some common data If we find
this common data, and create an abstract content type, then we will have a more
flexible 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?
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 fields
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
•
•
•
•
Trang 2Data 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 fine-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:
ID A reference number for the framework to refer to active content
Current revision The active version of the content
Trang 3Building 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 first 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:
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-specific 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
Trang 4This table requires the following fields:
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 first
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,
Trang 5KEY `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
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 ;