10 549669 ch07.qxd 4/4/03 9:25 AM Page 246 Chapter 8 Intranet Simple Document Publisher IN THIS CHAPTER ◆ Developing a simple intranet document publisher ◆ Installing the intranet document publisher ◆ Using the intranet document publisher PUBLISHING DOCUMENTS ON THE WEB or on the intranet is a major task due to the complexity of the documents and how organizations manage their workflow. In this chapter, we’ll develop a simple document publishing tool that is available to all users on the intranet and handles HTML documents only. Because most office word-processing applications these days can save files as HTML, this opens up the publisher to most organizations. Let’s look at the functionality requirements that this document publishing sys- tem will meet. Identifying the Functionality Requirements The document publisher will offer each user on the intranet the following: ◆ Web forms to create new documents: The Web form accepts both text and HTML data. However, the publisher itself does not support formatting. In other words, if a user wants to paste the contents of a Word document into the publisher form, she should save the Word document as an HTML file and copy the HTML contents instead of the text shown in Word’s WYSIWYG editor. If text documents are to be submitted, a simple trick is needed to maintain formatting, which is discussed in the “Adding a new document” section later in this chapter. ◆ Easy and simple category-based document organization: Each document is published in a category. There can be only a single level of categories. Each category will have a defined set of users who can view documents 247 11 549669 ch08.qxd 4/4/03 9:25 AM Page 247 and a defined set of publishers (i.e. users who can create/modify/delete documents). ◆ User-level access control for viewing and creating documents: Users can have view or publish (creation/modification/deletion) rights. Multiple users can have view or publish rights per category. ◆ Automated announcements for document availability and updates: When new documents are created, the users with view and publish rights are shown an MOTD announcement when they log in to the intranet. When an existing document is modified or removed, the appropriate users also are notified via MOTD. This notification is very useful because an important document change notice can be sent automatically to appropri- ate users who need to know about the changes. In fact, users will have to acknowledge that they know about the changes by clicking on the OK button of the MOTD document change notice message which gets dis- played on their home pages. Let’s take a quick look at the prerequisites of such a publishing system. The Prerequisites This document publishing system builds on the intranet classes discussed in the previous chapters in this part of the book. For example, it uses the MOTD class (Chapter 6) to announce new documents and updates. The applications that we develop here require the central login/logout applica- tions (Chapter 5), user-management applications (Chapter 6), and the intranet home applications (Chapter 7). In addition, administrative intranet users, who are defined in the intranet user table discussed in Chapter 6, are given full access to all aspects of the document and category management in this publishing tool. Now let’s look at the database design and implementation needed for creating this document publishing system. Designing the Database When designing the database for the document publisher we have consider the fol- lowing data requirements: ◆ There will be multiple categories. Each category will have list of users who can view documents in that category. Each category will also have list of users who can publish documents in that category. So a category has many viewers and publishers. 248 Part II: Developing Intranet Solutions 11 549669 ch08.qxd 4/4/03 9:25 AM Page 248 ◆ In each category there will be many documents. Each document will have tracking information and responses. Therefore each document has many tracking and response data. Based on these requirements, we can create the database relationship as shown in Figure 8-1. Here the LD_CATEGORY table has one to many relationships with the LD_DOCUMENTS table because each category can have many documents. Similarly, LD_CATEGORY has one to many relationships with LD_CAT_VIEWER (viewer list) and LD_CAT_PUBLISHER (publisher list) tables. Since each document in LD_DOCUMENT table has many tracking and response records, it has one to many relationships with LD_TRACK (tracking data) and LD_RESPONSE (response data) tables. Figure 8-1: Intranet document publisher database diagram. Table 8-1 describes each table in the database. TABLE 8-1 DOCUMENT PUBLISHER DATABASE TABLES Table Description LD_CATEGORY This table is the integral part of this database. It holds the category number ( CAT_ID), which is automatically generated by the database, and the category name ( CAT_NAME), description ( CAT_DESC), and order (CAT_ORDER). LD_CAT_PUBLISHER Contains the category publisher information: the category number ( CAT_ID) and the ID of the publisher who can publish document in that category ( PUBLISHER_ID). LD_CAT_VIEWER Holds the category viewer information: the category number ( CAT_ID) and the viewer ID of the user who can view documents in that category ( VIEWER_ID). Continued Chapter 8: Intranet Simple Document Publisher 249 11 549669 ch08.qxd 4/4/03 9:25 AM Page 249 TABLE 8-1 DOCUMENT PUBLISHER DATABASE TABLES (Continued) Table Description LD_DOCUMENT Holds information about the document: the doc ID (DOC_ID), which is automatically generated when a new document is added to a category; the category number ( CAT_ID) in which the document will be published; and the document heading ( HEADING), body (BODY), and publishing date (PUBLISH_DATE). LD_RESPONSE Contains response(s) to a document published in a category. Each response consists of an ID ( RESPONSE_ID), responder ( RESPONDER), subject (SUBJECT), rate of the document (RATE), comment by the responder ( COMMENT), document ID (DOC_ID), and time of response ( RESPONSE_TS). LD_TRACK Stores information about when and who viewed the document. It contains the ID ( DOC_ID) of the document that has been viewed, the ID ( UID) of the users who viewed this page, and the time when the document was visited by the user (VISIT_TS). I have provided the necessary SQL to create the document publisher database in the ch8/sql/ld_tool.sql file in the CDROM. You can create the database on your MySQL server using this file as follows: mysql -u root -p -D INTRANET < ld_tool.sql Make sure you change the user name (root) to whatever is appropriate for your system. The Intranet Document Application Classes With the intranet document publisher database designed, it’s time to look at the PHP classes needed to implement the application. Figure 8-2 shows the system dia- gram for the publisher. As shown in the system diagram, there are three new objects (Category, Doc, and Response) that are needed to implement the intranet document publisher. Let’s dis- cuss the classes that will provide these objects for your applications. 250 Part II: Developing Intranet Solutions 11 549669 ch08.qxd 4/4/03 9:25 AM Page 250 . Application Classes With the intranet document publisher database designed, it’s time to look at the PHP classes needed to implement the application. Figure 8-2 shows the system dia- gram for the publisher. As