Menu
▾
▴
[Phpwebsite-developers] phpWebSite Road Map
|
From: Brian W. B. <br...@ap...> - 2001-04-12 15:03:17
|
phpWebSite Road Map 12 April 2001 ############################################################################### # Coding Standards # ############################################################################### As the number of developers working on phpWebSite grows the need for a formalized set of coding standards becomes increasingly important. As recommended by many of the developers involved in phpWebSite, we will be adopting the PEAR PHP coding standards with a few addendums regarding HTML/XHTML markup, file headers, comment styles, etc. The PEAR Standards can be found at: http://php.net/manual/en/pear.standards.php Exceptions to the PEAR standards: Comment Style as per PHPdoc. See the following for the phpWebSite Developer docs, and well as rules for comments (thanks to Karsten Dambekalns): http://www.k-fish.de/krabutzig/phpwebsite/devdoc.html Addendum to PEAR Standards Regarding Markup (Adapted from the BinaryCloud Standards): * Use echo statements for markup where appropriate. Template files (to be introduced with the re-write of phpWebSite) should *never* contain echo or print statements as using them obscures the markup. On the other hand, jumping in and out of php within complex logic can obscure the logic. * Do not include complex logic in template files. Conditionals are the most complex logic allowed in templates. If you need to loop through an array, do it in the module, and call the template function recursively. * Declare all of your variables at the top, right under the function. Don't get globals, etc inside the code. In other words, do all of your setup at the top of the file. * It is nice if comments are wrapped to 80 chars, you'll probably get in the habit anyway - but it is not necessary. Tags cannot and should not be wrapped to 80 chars. Note that this standard applies to *all markup: html, xhtml, wml, xml, etc.* * Keep Template files light on php code. People who only know html should feel comfortable editing these files * Place an html comment at the bottom of the html with a path to the file. * Use html comments _ONLY_ when you are printing html. If the comment is about PHP code, use PHP comments. The purpose of the html comments is to allow html authors to locate code embedded in complex pages, so they can fix it easily. Diagnostic information is the only exception. ############################################################################### # Current Version # ############################################################################### phpWebSite v0.7.6 is the current stable release. Development will continue with this version but will be limited to the following: 1. Release of the calendar as a plug-in. Detailed documentation for plug-in development will be released at this time. Consider this an open call for help with this documentation. 2. Bug-Fixes as needed. Current developers should actively try to close all bugs on SF. Do not hesitate to assign yourself to a bug if you think you can close it. 3. Minor functionality fixes. 4. XHTML fixes. Again, don't be shy. CVS is waiting. 5. Security fixes. We are imposing a feature freeze on the current state of phpWebSite. Additional features, and major re-structuring will be reserved for the re-write project described below. Current development will continue until 1.0 is reached. Version 1.0 will be defined by: 1. Stable, secure, "bug-free" operation. 2. Valid XHTML for all generated client output. ############################################################################### # phpWebSite Re-Write # ############################################################################### As phpWebSite has evolved, many limitations in its current design have become apparent. As opposed to attempting to patch the existing code, we have decided to re-write phpWebSite. The re-write will allow for intelligent structuring of the application and provide an opportunity to remove inefficient legacy code from the application. In order to differentiate between the current phpWebSite and the re-write, the re-written code should be referred to as phpWebSiteII. Design Philosophy Efficiency, modularity, and ease of use are the goals of phpWebSiteII. A minimalistic core will provide basic functionality and services. Features will be provided on an as needed basis by external plug-ins. Site authoring should be easy and intuitive for the user possessing even minimal computer skills. Site administration should also be easily managed, allowing for multiple instances using a single database and code base (Geoff Staples has done some good work toward this goal). phpWebSiteII should scale to support a *large* number of virtual sites. Core Modules All core modules should have some sort of "scoping/relation-node" inter-module relationship as in mmbase and ACS Digital. Clayton Collie and Todd Owen have a good start on this discussion, and I would like see one (or both) of them take the lead role in developing this for phpWebSiteII. The following modules will define the core: Authorization Module The authorization module should handle all authorization (user and admin) and permissions for the system. MD5 encryption should become the standard. Permissions/access control will be granular as opposed to tiered. Todd Owen has put forth good ideas based on Zope. LDAP support should be an option for those who wish to use it. Plug-ins should be able to leverage both basic authorization and granular permissions. Template Module A custom templating schema will be developed. Although products such as SMARTY or PHPLib provide a great deal of functionality, we are hesitant to lean too heavily on a third party project. By developing our own templating methods, we can keep installation requirements minimal and provide tighter integration with other core services. Templates should be simple, light or void of php code, and flexible enough to allow html designers to easily create new themes using tools of their choice. Adam Morton and Matt McNaney are currently working on some "proof of concept" approaches to templating. Existing themes will not be backwards compatible, but re-creating them should be much easier. Administration Module The administration module will provide access to all administrative functions for the core and any installed plug-ins. Inter-module relationship with the authorization module will define rights for these functions. Announcements Module (formally "articles/stories") Current functionality is good. Relationship with the authorization module should provide display of a given announcement or class of announcements based on permissions. Comment Module Current functionality is OK. Some users have expressed the need for Slashdot style comments. More choices here would be welcome. Email Module The email module will go beyond the simple email functions currently in phpWebSite. Mailing lists, forum and comment monitoring via email should be available options to users. Help/User Documentation Module Will be implemented in the next release of phpWebSite. For phpWebSiteII inter-module relationships should open module to be plug-in aware. Context-sensitive help should be available throughout the site. Menu Module Menu module should handle both administrative and user side menu function. Current menu system works but lacks flexibility. Plug-In Module The plug module should handle all plug-in registration, and provide a gateway for plug-in communication with other modules. Current plug-in API needs to be enhanced, but backwards compatibility of existing plug-ins needs to be preserved. Search Module Search engine needs re-design. Should be more modular and flexible. Other Core System Specifications: Database Abstraction phpWebSiteII will support multiple databases via the PEAR DB.php that ships with PHP4.x. Session Management PHP4's native session management will be utilized in phpWebSiteII. Registered User Customization Greater flexibility for registered users is desired. Ability to choose custom news feeds, personal "quick links", etc. Please note, however, that this does not include features such as block re-ordering - while this is "cool", we remain unconvinced as to any real functionality this provides. Error Checking Sanity checks on submitted data, graceful recovery for user preference conflicts (theme removal, etc.) needs to be implemented. What is not in the core Polls, stats, web links, calendar, etc. will be re-written as plug-ins. phpWebSite -> phpWebSiteII A clear upgrade path must exist. ############################################################################### # Architecture/Modeling of phpWebSiteII # ############################################################################### This document has attempted to define phpWebSiteII using relatively broad brush strokes. Where possible we have specified key components that will achieve various ends, most notably, database abstraction and templating. A detailed architectural design is needed before implementation can begin. Those developers who have extensive experience with software engineering are asked to please step forward and avail your skills to the project. I would like to form a *small* team to model/design the re-write based on this document. Object Oriented vs. Procedural Programing Some have suggested an OOP approach to the re-write. Unfortunately, the PHP handles classes in a weird way due to variable handling of the interpreter: class my_class { var $var1, $var2, $var3; } $my_object = new my_class; $my_object->var1 = 1; $my_object->var2 = 2; $my_object->var3 = 3; $new_object = $my_object; $new_object->var1 = 3; $new_object->var2 = 2; $new_object->var3 = 1; print("My Object goes $my_object->var1, $my_object->var2, $my_object->var3 !"); print("New Object goes $new_object->var1, $new_object->var2, $new_object->var3 !"); This produces the following output: My Object goes 1, 2, 3 ! New Object goes 3, 2, 1 ! :-/ PHP has created a copy (a new instance) of my_class instead of just a new reference. To complicate matters further, this will be changed in an upcoming version of PHP, causing a loss of backward compatibility. While this does not sink an OOP approach, it certainly is something to carefully consider. Additionally, an OOP approach would most likely impose greater overhead in development. On the other hand, the current code takes a procedural approach, and coupled with a good design, a procedurally oriented re-write should be as effective, as maintainable and as extensible as an object-oriented one. ############################################################################### # Development Team Organization/Management # ############################################################################### I would like to organize the developers into small teams, each with a module (or two) on which to focus. Each of these small teams will have a lead developer that will have decision making authority for the module(s) that he or she manages. This should help the overall efficiency of the re-write, since it is simply easier to communicate with a smaller number of people than a large number. Module team leaders will report to a design/engineering team, and would be responsible for sharing information that impacts work outside of the particular module. Those working on a given team, report to the team leader. We need volunteers for the following: Design/Engineering Team This team should be composed of developers who have the most experience with software engineering. This team will provide the blueprints for the re-write to the other teams. If you would like to be the lead on this team, please indicate so. Module Teams Teams for each module discussed above need to be established. Again, if you would like to lead a team, please indicate so. Graphics/Theme Team This team will focus on theme creation and graphic design (we *really* need some custom icons, etc.). This team will be for developers with Gimp/Photoshop experience and/or XHTML/HTML design experience. A lead will be needed here as well. Communication Tools SF Developers List We will limit communication to the SF developers list. If any given team feels it needs a separate list, let Jeremy Agee know and he will set it up. IRC Someone once made the offer to setup IRC for phpWebSite. Please do so, this will provide a good secondary method for teams to plan/discuss in real time, augmenting, but not replacing the developers list. phpWebSite Name Change For now we are going to keep the name phpWebSite. It is widely recognized, and we feel that we can get phpwebsite.org without too much trouble using the new ICANN rules regarding "squatting". Jermey Agee is working on that little project. It is possible that phpWebSiteII could use a name change that would offer an opportunity to capture a good domain name. We should have some time, so if you have an idea for a brilliant name, let everyone know. Thanks again to all are developers. Kind Regards, Brian Brown phpWebSite Project Manager -- Brian W. Brown Internet Systems Architect, ESS Student Development Room 269, John Thomas Hall Appalachian State University Boone, NC 28608 vox: 828-262-7124 fax: 828-262-2585 |
