Initial Thoughts on a ColdFusion MX Content Management Project
- Separation of Presentation and Content
- The Basics of Content Management
- The Rules Engine
- The Database Layer
- The User Interface (UI)
- Putting It All Together
- The Proposal
This chapter is from the book
This chapter is from the book
This chapter is from the book
The folks at XR Solutions make a point of evaluating clients and applications individually, resisting the urge to try to solve every problem with the same solutions. As J.P. Levine, the CEO, too often reminds his team, "If all you have is a hammer, every screw looks like a nail."
J.P. assigns the EduHealth content-management project to Mark Foster, a senior development manager who is just wrapping a project for a local government agency. Team members are assigned to projects by the development manager on a project-by-project basis. XRS finds that by mixing the team makeup, individuals are exposed to a greater variety of skills and talents, and can thus be more creative in problem solving.
Mark emails J.P.
EduHealth team
Date: July 3 To: J.P. From: Mark Foster Subject: EduHealth team JP, Wanted to get this to you before you took off for the 4th. Here are my team preferences: Teri Martin Vijay Singh Sam Carlson Al Sharpe (I am assuming he'll be with us the whole summer, right?) I'll meet with them when we get back after the break. Mark
The next day, while most of his coworkers are enjoying beer and barbecues, Mark reads up on the notes and requirements obtained by Maria Chavez in sales. He scribbles and doodles all over the printouts, and prepares for the first team meeting.
With J.P.'s approval (and verification that Al is staying until the start of the next semester) the team meets the next day.
MEETING NOTES
Present: Mark Foster, team lead Sam Carlson, developer Teri Martin, developer Vijay Singh, database administrator Al Sharpe, internMark reviews Maria's notes and then launches a buy-versus-build discussion. All are in agreement that any bought solution would be overkill, since this is a simple app and doesn't need all the features and overhead of a commercial content-management systems. Plus, any commercial system would place additional burden on users, and it would be too hard to create a simple interface that provided only the needed functionality.
Sam hands out copies of the kind of content (articles) that's typical of what EduHealth creates. Most of the content consists of text, and there's no standard structure for the most part. Teri says that based on her experience, the folks at EduHealth probably have no idea what they really want—and won't until they see a finished product and figure out what they don't like. Mark agrees, and says that's why whatever we create needs to be flexible and structured properly.
Al asks for an example, and Mark draws something like this on the whiteboard (see Figure I-2.1):
The screen scribbles show different ways to present the same information. If the screens are designed properly, using data in different screens is just a matter of presentation, and underlying data is not affected. Mark has an email message he wrote for a previous project on separating presentation from content, and he will circulate it.
Vijay says that database design is most of the work. (He always says that.)
Sam mentions that he wants a rules engine. It's not part of the specs, but it will allow for additional features later on, when they are needed. Those features could include the following:
- Show content on certain days
- Show different content by time of day
- Hide or show specific articles based on source of request Mark thinks a rules engine may be unnecessary; Sam will investigate what would be involved.
Action Items:
- Mark to send out copy of e-mail
- Sam to look into rules thing
- Vijay to research database schemas used in other projects
Meeting adjourned.
)
I-2.1With the unanimous decision to build a custom application, Mark meets with Maria and J.P. to bring them up-to-date. Maria says she'll talk to David (Dave) Keyes at EduHealth and asks if she can schedule a meeting for next week to present a formal proposal to the EduHealth people. Mark agrees but asks Maria to articulate that at this point the team will concentrate on functionality and not on a pretty interface. Maria nods.
Separation of Presentation and Content
Mark sends out an excerpt from e-mail he saved in his Really Good Stuff Worth Keeping folder. The gist of it is this:
The biggest problem facing most developers (both static-page designers and application developers) in the Web space is that they routinely mix presentation and content. Consider the following:
Web pages contain content and HTML formatting in one page. This makes reusing that content with different formatting very difficult, essentially requiring all formatting to be manually removed and then reapplied.
Application pages—written in ASP, Perl, PHP, Macromedia ColdFusion, and so on—usually contain database calls, conditional processing, output formatting, form validation, and more. So a change in database design, for example, necessitates all sorts of code changes.
Whoever creates a Web-based application design needs to know SQL and database layout. Similarly, whoever works on basic business logic needs to know about data presentation. And so on. This is not scalable at all, and this kind of cross dependency does not allow development teams to grow and work on more complex projects—developers should be able to concentrate on what they do best, not spend time brushing up on stuff they don't need to know.
Structured development requires breaking applications into tiers or levels. At a minimum, the content and presentation tiers must be separate: Content must never be tied to presentation, and presentation must never be tied to content.
NOTE
The content tier isalso referred to as the data tier.
For example, if the content in a database was going to be displayed in an HTML Web page, a Macromedia Flash movie, or a wireless application protocol (WAP) device, and rendered in PDF format, the content should always be the same. Only the presentation should differ.
Similarly, the presentation code that generates HTML output should be able to do so for all sorts of data; it needs to be reusable too.
Developers refer to this issue as separating presentation from content. There are lots of different technologies and buzzwords used to accomplish this, but all seek to do the same thing.
Al instant messages Mark:
Al: Sounds like an added level of complexity.
Mark: Not really. If done properly, it's actually less work and less code.
Al: Where can I see examples of this?
Mark: Look at the CFC files in the project we just finished. Try user.cfc and catalog.cfc; both are good examples of encapsulating data and supporting code into black boxes so that presentation code can concentrate on presentation and not have to know how users and products are stored in databases.
Al: Thanks, will grab those right now.
Mark: Enjoy. Oh, and FYI, CFCs are a great (and simple) way to make all this work. You might want to play with those.
Al: Will do.
Al opens the user.cfc file and scans the code. He has never used Cold-Fusion or CFML before but the syntax is easily read and the code well commented—he has no problem getting the core concepts. He makes some notes for future reference:
All database calls live inside an object.
The object exposes methods like "Get" or "List" or "Add."
Methods take arguments.
Methods return data.
All processing lives inside the method.
Methods can be called by presentation code without having to know about how things work internally.
Al looks at some of the presentation code and notices that the Get user method is used all over the place in all sorts of user interface (UI) code, and none of the code knows that the data is being pulled from a LDAP directory. Suddenly it all clicks. He fires off another instant message:
Al: I. get it! I'm a believer!
Mark: Glad to hear it There's hope for you yet. :-)