In this particular case, I have several users that write news and magazine articles in Microsoft Word that are usually published in print. The users need to get the stories written in Word on the web, but they also need to able to edit the content easily in case an error is found in an already published document. The content itself needs to be published on multiple web pages across several servers and in a variety of formats–RDF/XML and XHTML.
There are a variety of tools that may be utilized to satisfy my users needs. A discussion on what tools are best is akin to a discussion on preferred regional flavors of chocolate bars. The tools I list here are not "the best," they are simply the tools I prefer to use:
For the sake of starting somewhere, I have two roles: admin and writer. The admin will have access to publish to the database and check files out of the database, while the writer will have Contribute writer permissions to a "static" directory along with the ability to publish to the directory. The example application will not go into defining these roles.
After some careful considerations and applying the "keep it simple stupid" (KISS) principle, I came up with a workflow that addresses what the PHP application should facilitate: pulling information out of the database and converting it to XHTML; reading "checked out" files in the directory; publishing files to the database; and generating an XML feed.
Figure 1. The overall workflow
Note the Contribute area on the diagram. In there, the workflow is pretty much browse, edit, and publish. Take a look at Figure 2:
Figure 2. The Contribute workflow
To help the content provider, I provide them with Dreamweaver templates to assist with making sure all content elements are there while also giving the PHP application some tags to use as markers. This comes in handy for taking the information out of the database as well.
The important part of all this is the user experience. Ideally I would like to have authentication be seamless, the database commands be built into Contribute, and full pint delivered to my desk hourly. What I have is the Contribute web browser to act as an application window─the user can navigate to the home page and log in.
Figure 3. Contribute as the application window
After they log in, the writer is directed to the static directory where the PHP application picks up all XHTML files in the directory and lists them in a table.
Figure 4. The PHP application displaying the XHTML files in Contribute
The table shows if the file is checked out in Contribute (by looking for and reading the .LCK file) as well as who has the file checked out of the database. They can, of course, view the file checked out in Contribute but the file locking in the Contribute universe stops them from clicking the Edit Page button. If it isn't checked out, it is business as usual─browse, edit, publish.
If they want to create a new article, they do so by using a Dreamweaver template as a starting point, filling in the blank editable reagions with copy/paste from their text editor. They can also format the text, and drop in some images for some spice.
Figure 5. Creating an new article in Contribute based on an Dreamweaver template
Ah, but what about images? When Contribute adds images to a HTML document, it drops the file into the directory you choose (/images/) by default. It also creates a relative link to the image. This doesn't work too well when you want the content to appear somewhere other than the /static/ directory—even if you can copy the /images/ directory after you publish.
To get around this problem I have the PHP change the URL to the image to a specific place on the production server that I store images and make sure the image is copied there.
After all that, the admin comes along and wants to publish the story. To do that, they go to the publishing area, select the articles to publish, and publish.
Figure 6. The admin publishing interface
Of course it isn't all that simple to achieve the functionality that is required by the users in my office. There are other functions required to make things work—always little bugs based on template behaviors, user expectations, and authentication.
If I removed the PHP/HTTPS authentication on the sandbox, replaced it with an HTACCESS based authentication, and had the PHP functions on the site that was actually showing the articles, then I remove the need for a lot of what I built. I just need to protect the check-out script and sandbox from bots and malicious PHP hackers. Contribute will place your images in the right directory, Templates will ensure the proper CSS is called, and the data will be local.
The ability to publish to a static XML feed and the database simultaneously is probably the best feature so far. HTML is great but XML feeds are expected when publishing news content these days. XML also opens up some syndication possibilities with our own sites that don't involved database queries, which is important for our relatively high traffic home page.
Contribute is a very useful tool for bridging the CMS/forms for content that you often see. The SOAP commands open up some real possibilities as well. We currently are planning on moving all our online publications into this workflow to allow a common place to manage news and information articles. Contribute is a real hit with our content creators and Macromedia's commitment to CPS really makes us comfortable will utilizing this technology more in the future.
In the next section, I will review a simple application based on the concepts I have described.