Internal Specifications Developed

Posted by Richard Pisca on Sunday 29 November 2009

It's not complete, just yet, but the base specifications for php2press have been written down and saved. We will try to keep them up to date as things progress, time permitting.

---

Class Heirarchy:

Core

Mods
|___UserMod
|___DBMod
|___InMods
|	|___ImportMods
|	|___ContentMod
|	\___LayoutMod
\___OutMods

Codeflow:

• Load Modules from disk
• Authenticate user
• Account Management:
  • Change auth info:
  • Change other info: (Optional)
  • Set account-level permissions:
    • Content access:
    • Layout access:
    • Export access:
    • Project management access:
    • User management access:
    • Access from list:
  • Add User:
  • Remove User:
• Logout:
• Project Editing:
  • Project permissions:
    • Content access list:
    • Layout access list:
    • Export access list:
    • Project management list:
  • Create project:
  • Destroy project:
  • Edit project:
    • Load project
    • Import data:
      • Place contents:
        • Place in new content item(s):
        • Place in existing content item(s):
      • Place layout:
        • Place in new layout context(s):
        • Place in existing layout context(s):
    • Manage content:
      • Create content item:
      • Modify content item:
      • Destroy content item:
    • Modify layout:
      • Create layout context:
      • Modify layout context:
      • Destroy layout context:
    • Export data:
      • Select content item(s)
      • Assign layout context(s)
      • Select output format(s)
      • Convert data to output format(s)
    • Close project:

To Define:

Internal Data Structures

• Content item format(s)
• Layout context format(s)
• Intermodule communications structures

Reminders:

• Modules should not be aware of the existence or not of other modules.
• Modules should communicate with the core and only the core.
• The core is responsible for the loading and unloading of entire modules, but modules should destroy any extraneous objects they are no longer using.
• If a module requires modification of the core to function properly, try redesigning it to work with an official core.
• If a module cannot be redesigned to function with an official core, inform the Core Team of the situation so it can be considered for future official releases.
• If you cannot limit the functionality of your module to a single module type, ask for help redesigning it.
• Modules can be designed to work extremely well with other specific modules, as long as they do so through the core, and still have reasonable support for other modules.
• In keeping with the core being the coordinator of all information, any extensions to the module classes should be private members.

---

This document is not complete, and is subject to modification without notice as the project progresses.
Stop reading the fine print, dummy.
php2press is a collaboration between Richard Pisca, Aaron Mathis, and Eugene Miller - they are the project admins.
Anyone else working on the project is doing so under the supervision of the admins.
If you haven't stopped reading yet (and you haven't, be honest), not only can you not follow a simple instruction, but you have also forfeited all rights to your soul. All your base are belong to us!

That is all.

The Future Is Bright

Posted by Aaron Mathis on Sunday 22 February 2009

Well, after a long hiatus, the project is breathing some fresh air. Richard, Eugene, and I all agree that it is time to resurrect the project from the ashes. In the past few days, we have been asking ourselves a plethora of questions regarding the future of the project. In an attempt to do things right this time, we have been working on a detailed outline of how the core module should work, and how the other modules should interact with it.

While discussing the project yesterday, Richard gave an analogy of the different parts of Php2Press. It went something like this:

If it helps, think of the modules as employees.

The core is the boss, and the DB module is the core's secretary. The boss doesn't care how the secretary stores his information as long as she can find it when he asks for it. The UserAuth module, then, would be like the boss's security guard. When someone (a user) wants to do something with the company (the application), they first have to talk to the security guard. The guard then tells the boss who's there to see him and what position they hold relative to the company's interests (which privileges they have). The CMS module would be the research team, finding and reporting all the important information (user input) back to the boss, who then has his secretary record it all and add it to the appropriate file(s). Then the boss would go to the marketing division (LMS) who would design a way to present the information most effectively. The marketing guys have no idea what they're advertising - at least, not the specifics. They submit their completed designs to the boss, who has his secretary file that information with the rest. When the boss is ready to present the results to the client (the user chooses one or more Out modules), he will ask his secretary for all the information on the project, and then take it all to the publishing division (Out modules), who will make the necessary tweaks to the design for the content to play nice with it (sometimes with user interaction), then publish everything. If the client likes the end result, that project is complete for the day and the boss moves on to another project. And at the end of the day (the user closes/leaves the application), after sending all of his employees home (unloading the modules), the boss locks the doors and turns out the lights (cleans up everything else and exits).

Now that we feel we have gone over the core in enough detail, we have started active development on the project again. Of course we would like to keep you in the loop, so check back from time to time to see what's new with the project.