(Of course, the menu can be much more sophisticated, but it’s good to start slowly. In the next section you look at the sneaky (but not difficult) way the menu HTML is coded.) I kept the code very simple, but of course you can (and should) improve it how- ever you wish. Add background graphics, borders, or improved text. Put the menu across the right or top. It’s important that I used percentage measurements in this element, because I don’t know the user’s screen resolution. By indicating position and width in per- centages, I have a style that works well regardless of the browser size. The item class is the other important CSS element in this code sample. It’s another specialized span dedicated to placing the Web page’s main content. The item class works well with the menuPanel class. It is placed a little to the right of the menu panel and takes up most of the remaining screen space. Once again, the actual style is quite simplistic and you probably want to spruce it up. Inspecting the Menu System The real key to the simpleCMS is the way it’s used. Each page that the user sees is a combination of three different HTML pages: a banner, menu, and content page. The simpleCMS.php program puts these three elements together according to a TRICK 283 C h a p t e r 8 X M L a n d C o n t e n t M a n a g e m e n t S y s t e m s IN THE REAL WORLD What about browsers that don’t support CSS? Some would argue that a table- based approach to layout (as PHP-Nuke and many other CMS tools use) would work across more browsers than this CSS-centric approach. While it’s true some older browsers support tables but not CSS, tables have their own prob- lems as page layout tools. Tables were never really designed for that purpose, so to get a layout exactly like you want, you often have to build a Byzantine complex of tables nested within tables, with all sorts of odd colspan tricks and invisible borders. The positionable CSS elements were invented partially to provide a simpler, more uniform solution to page layout headaches. The browsers that don’t sup- port CSS still display everything encoded in a CSS-augmented page. The CSS won’t take effect, but all the other HTML code will work and the user can use the page. specific style sheet. For this example, presume that the CSS style and banner remain the same for every system-displayed page. (This is usually the behavior you want.) You never directly link to any of the pages in your system. Instead, you link to the simpleCMS.php program and pass the content file (and menu file, if you wish) you want displayed. Recall that simpleCMS requires two parameters. Most PHP pro- grams get their parameters from HTML forms, but you may remember from chap- ter 2, “Using Variables and Input,” that parameters can be sent through the URL via the GET protocol. You can make any page display as an element of your CMS by calling it as a parameter. To clarify, take a look at the menu.html code: <h3>Main Menu</h3> <ul> <li><a href = “simpleCMS.php?content=default.html”> main</a> </li> <li><a href = “simpleCMS.php?content=classes.html”> classes</a> </li> <li><a href = “simpleCMS.php?content=links.html”> links</a> </li> <li><a href = “simpleCMS.php?content= software.html”> software</a> </li> <li><a href = “simpleCMS.php?content=wallyindex.html”> media</a> </li> </ul> Notice the trick? The first link refers to a page called default.html. Rather than directly linking to default.html, I linked to simpleCMS and passed the value default.html as the content parameter. When simpleCMS runs, it places the default banner ( top.html) and the default menu (menu.html), but places the con- tents of default.html in the new page’s item area. I didn’t send a menu parame- ter, but I could have, and it would have placed some other page in the menu area. In short, you can place any page in the menu area by assigning its URL to the menu parameter; you can assign any page to the item area by assigning its value to the content parameter. Any page you want displayed using the CMS must be 284 P H P 5 /M y S Q L P r o g r a m m i n g f o r t h e A b s o l u t e B e g i n n e r called through a link to the CMS program, which pastes together all the other pages. You can place any HTML into any of the segments, but your menu usually goes in the menu area and is usually written only with links running back through the CMS. You can create a reasonably sophisticated multilevel CMS with only this very basic program by experimenting with different menus, CSS styles, and banners. You might wonder why I didn’t show you the source code for the CMS top and con- tent areas. There’s nothing at all unusual about these pages, so I didn’t think it was necessary. Generally, you write the top to be banner-like (very simple, designed to cover the entire width of the page, but just a short height). The pages you want to display in a CMS don’t need header areas, titles, or page-level CSS definitions, because many are ignored in this multipage document. The CMS dictates these meanings for the entire composite page. Improving the CMS with XML Although the simpleCMS presented earlier is extremely powerful, it is limited to only two parameters. It would be great if you could control even more informa- tion on every pass through the CMS. It also would be nice to determine the page title, CSS style, top area, menu page, and body on every pass through the system. However, the GET method approach used in simpleCMS quickly becomes cumber- some when you’re sending more than one or two parameters. The GET method allows limited amounts of data to be passed. The URLS get tedious when you have that much information to send. Most CMSs use an alter- native method of storing the information about intended page values. A lot of CMSs (like PHP-Nuke) use the full power of relational databases. This is a wonder- ful way to go, but it can be somewhat involved for a basic demonstration. There is a more-powerful alternative than basic parameter passing, although it’s not quite as intimidating as a relational data structure. Introducing XML eXtensible Markup Language, or XML, has become a major topic of conversation in the software industry in the last few years. It isn’t just a language, but a flex- ible and sensible alternative for manipulating data. It’s really a language for describing languages. XML feels a lot like HTML (because they’re related) but it’s quite a bit more flexi- ble. In a nutshell, XML allows you to use HTML-style syntax to describe anything. TRICK 285 C h a p t e r 8 X M L a n d C o n t e n t M a n a g e m e n t S y s t e m s For example, if you want to talk about pets, you could use the following code: <?xml version=”1.0” encoding=”utf-8” ?> <pets> <cat> <name>Lucy</name> <color>tabby</color> <breed>shorthair</breed> </cat> <dog name = “Muchacha” color = “brown” breed = “mutt” /> </pets> As you look at this fragment of (entirely fictional) XML code, you see an unmis- takable resemblance to HTML. XML uses many conventions that are familiar to HTML developers, including nested and closing tags and attributes. The most sig- nificant difference is the tags themselves. HTML tags are specifically about Web page markup, but XML tags can describe anything . As long as you have (or can write) a program to interpret the XML code, you can use HTML-like code to describe the information. Working with XML XML has a number of data-management tool advantages. XML files can be stored and manipulated as string data and ordinary text files. This makes it easy to duplicate data and move it around the Internet. XML data is somewhat self- documenting. You can look at XML data in a text editor and have a good idea what it means. This would be impossible if the data were stored in a database table or proprietary format. Most languages have features that allow you to eas- ily extract data from an XML document even if you don’t know exactly how the document is formatted. Understanding XML Rules XML is very similar to HTML, but it is not quite as forgiving on syntax. Remember these rules when creating an XML document: • XML is case sensitive. Most tags use lowercase or camelCase (just like PHP). <pet> and <PET> are two different tags. 286 P H P 5 /M y S Q L P r o g r a m m i n g f o r t h e A b s o l u t e B e g i n n e r • All attributes must be encased in quotation marks. In HTML, quotation marks are always optional. In XML, almost all attribute values should be quoted. For example, <dog name = muchacha> is not legal in XML. The appropriate expression is <dog name = “muchacha”>. • All tags require an ending tag. HTML is pretty forgiving about whether you include ending tags. XML is much more strict. Every tag must have an ending tag or indicate with a trailing slash that it doesn’t have an end. In the earlier example, <cat> has an ending </cat> tag. I defined dog to encase all its data in attributes rather than subtags, so it doesn’t have an explicit ending tag. Notice how the dog tag ends with a slash (/>) to indi- cate it has no end tag. Examining main.xml The second CMS system in this chapter uses XML files to store page information. To see why this could be useful, take a look at the XML file that describes my main page in the new XML-based content management system (XCMS): <?xml version=”1.0” encoding=”utf-8”?> <cpage> <title>Andy’s main Page</title> <css>menuLeft.css</css> <top>top.html</top> <menu>menuX.html</menu> <content>http://www.cs.iupui.edu/~aharris/default</content> </cpage> The entire document is stored in a <cpage></cpage> element. cpage represents a CMS page. Inside the page are five parameters. Each page has a title as well as URLs to a CSS style, top page, menu page, and content page. The XML succinctly describes all the data necessary to build a page in my CMS. I build such an XML page for every page I want displayed in my system. It is actually pretty easy because most of the pages are the same except for the content. It would be even easier in a real-world application, because I would probably build an editor to create the XML pages automatically. That way the user would never have to know he was building XML. Sounds like another great end-of-chapter project! TRICK 287 C h a p t e r 8 X M L a n d C o n t e n t M a n a g e m e n t S y s t e m s . “simpleCMS .php? content=default.html”> main</a> </li> <li><a href = “simpleCMS .php? content=classes.html”> classes</a> </li> <li><a href = “simpleCMS .php? content=links.html”> links</a> </li> <li><a. you link to the simpleCMS .php program and pass the content file (and menu file, if you wish) you want displayed. Recall that simpleCMS requires two parameters. Most PHP pro- grams get their parameters. “simpleCMS .php? content=links.html”> links</a> </li> <li><a href = “simpleCMS .php? content= software.html”> software</a> </li> <li><a href = “simpleCMS .php? content=wallyindex.html”> media</a> </li> </ul> Notice