News and Updates

A Basic Overview of What's Going On

Below are some notes from us, the developers of php2press, to you, the users. It will be fairly up to date, most of the time. Keep checking back for more info!

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:

To Define:

Internal Data Structures

Reminders:


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

An overview of the php2press project workflow.

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.