Home arrow PHP arrow Page 2 - Cracking The Vault (part 1)

Just Another Day At The Office - PHP

Electronic documents are all well and good - but when you work onthem collaboratively, they can end up being more difficult to handle thanordinary pieces of paper. Multiple versions, competing standards, accesspermissions and revision history tracking are just some of the issues thatarise in a paperless office. This article discusses building and deployinga document management system across your network - and also teachesbeginnners a little bit about designing Web-based applications with PHP andmySQL in the process.

  1. Cracking The Vault (part 1)
  2. Just Another Day At The Office
  3. An Evil Plan Is Born
  4. Setting The Ground Rules
  5. Design Time
  6. Start Me Up
  7. Entry Points
  8. Seeding The System
  9. Red And Green Clouds
  10. Digging Deeper
  11. Basic Maintenance
  12. The D Word
By: Vikram Vaswani, (c) Melonfire
Rating: starstarstarstarstar / 2
May 14, 2001

print this article


Before we get into the nitty-gritty of PHP scripting, it is important to understand the problems we faced, so that the functional requirements of the solution become clear.

The primary problem we faced with electronic documents was one of version control. Here are three scenarios which illustrate the problem:

1. The company has just been contracted for a software development project, and John is identified as the team lead. He is responsible for publishing a schedule describing milestones and resource allocation. Before committing delivery dates to the customer, John must communicate with various department heads and obtain their agreement to deliver work product on specific dates.

Typically, John would create a schedule, outlining the tasks as he sees them (leaving dates and resource names empty). He would then send this schedule to different department heads, asking each to fill in the missing data in the areas that concern them. For example, Tim (Design Manager) would need to assign a resource to the interface design aspects of the project and state how long the task would take, while Roberta (Publications) would need to assign a writer to the task of putting together a manual once the code is released.

The problem here is that if John emails the document to each person, he has to integrate the different versions he receives back into a single picture, and again send the final draft out for approval to all design heads. Alternatively, he could place it on the network - but how is he to know when the various departments have finished adding to it, and the changes made to the document by each?

2. A corollary of the problem above - once the schedule is decided, John stores the document in a project folder on the network, accessible to all. However, as per Murphy's Law, the project is plagued with delays, necessitating frequent updates of the schedule...and consequently, different versions of the same schedule. Team members often find themselves working off an outdated version of the schedule ("Oh, didn't you know, we need the widget tomorrow - look, it says so right here, in this new schedule!").

John also needs to assign permissions to the schedule (and other group documents) carefully, to ensure that only authorized people are viewing or making changes to it (this is particularly important for billing and invoice information). If John is technically qualified, he can easily use built-in Netware, Linux or Windows NT capabilities to assign document permissions...but what if he is (horror of horrors!) a manager?!

3. The third scenario is one unique to our particular area of business. As a content development company, we have a small but talented team of freelancers developing content for us. These guys (and gals) email material to us from home, sometimes dropping in to the office to perform edits or corrections. Now, if they email material to Harish, and drop in the next day expecting to edit it, they're going to be deeply wounded by the fact that Harish decided to go to the beach today, and no one else can get through the BIOS password on his workstation.

A similar problems arises on collaborative writing projects; if two or more writers are working on different aspects of the same piece, an editor has to sit down at the end and make sure that each writer's changes and additions are integrated into a final, workable article. And here's another twist: what happens if a new writer is brought in to work on the piece (these guys like to call themselves "consultants"), and the work is spread piecemeal among the other three members of the team? Obviously, there needs to be a way for new team members to quickly obtain the most current version of a document, so as to get up to speed quicker...

You may have faced similar situations at your own workplace - if so, you'll be glad you decided to read this article. If you've never, ever, encountered one of these situations or variants thereof - is your company hiring?

This article copyright Melonfire 2001. All rights reserved.

>>> More PHP Articles          >>> More By Vikram Vaswani, (c) Melonfire

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Hackers Compromise PHP Sites to Launch Attac...
- Red Hat, Zend Form OpenShift PaaS Alliance
- PHP IDE News
- BCD, Zend Extend PHP Partnership
- PHP FAQ Highlight
- PHP Creator Didn't Set Out to Create a Langu...
- PHP Trends Revealed in Zend Study
- PHP: Best Methods for Running Scheduled Jobs
- PHP Array Functions: array_change_key_case
- PHP array_combine Function
- PHP array_chunk Function
- PHP Closures as View Helpers: Lazy-Loading F...
- Using PHP Closures as View Helpers
- PHP File and Operating System Program Execut...
- PHP: Effects of Wrapping Code in Class Const...

Developer Shed Affiliates


Dev Shed Tutorial Topics: