Attached is a file that i created which is sort of a Design Document for www.iglu.co.il.
Read and flame away. -- http://abiri-e.com/ "God is a programmer".
Not-exactly-but-kind-of Design document for www.iglu.co.il ---------------------------------------------------------- This document is not any kind of a professional system analasys, and it does not adher to any standards of system analyzation. It's simply ment to detail what i understand and plan so that i can be flamed and plan differently. The main issue here is the fact that there is one thing that i (and PHP for that matter) cannot compete with in zope. And that's it's Flexebility and the ease at which it enables the generation of web pages in what i understand is more or less a point and click web interface. I wanted to leave some of that ability, but it will not stand up to what i think zope is. On the other hand, PHP's advantages are it's ease of use and understanding, and that's what i am hoping to deliver. www.iglu.co.il -------------- >From what i understand this is what www.iglu.co.il holds at the moment. Content ------- - Articles - Comments on articles - Faq - Events - Links - Mirrors Important Features ------------------ - Posting articles by any anonymous user, pending for admin approval. - Posting comments on any article by any anonymous user, without any admin approval. - Creating and modifying any page/content on the site with a relativly easy to use web interface, by admin users. - Search engine Problems / Wanted features -------------------------- - Decent hebrew support - Admin control over mirroring - Automaticly changing content, with admin control over what and how - Multiple admin accounts - Email notification of articles waiting for approval ------------------------------------------------------------------------------ Basic cocepts ------------- Do digest the problem of the dynamic content i have devided the web pages on the site to three categories: - Static pages - Action scripts - Admin section Static pages ------------ Not neccesarily what the name implies. This means that this pages can hold PHP lines in them, but in general their content doesn't change so often. It is not neccesary that they query the database for each page hit for example, or some other external site. But their content can change automaticly (cron jobs) or manualy (admin(s)). These pages are the ones that will need to be very flexibly controlled by the admins through a web interface. Action scripts -------------- These pages are each the "brain" for specific tasks. For examle the PHP script that will accept input from the article posting form. It has to check permissions, update the database and notify the admin(s). This PHP script is not supposed to have any output whatsoever, and (obviously) will be less controlled if at all by the admin web interface. Admin section ------------- A privileged section of the site that is used to control the rest of the site. This pages are at best almost completly unmodified by the admin web interface. They have to be strict in security. Approach -------- My idea is to create some basic mechanism of dynamic generation of the Static Pages by the Action Scripts and the Admin Section. This by itself is not very complicated, except that we want to leave as much control as possible to the Admin Section over the rest of the pages. To that i mean to divide the Static pages into "Elements". An elemnt is some basic part of the page like "Links bar", "Links sidebar", "Form", "Header", "Footer" and so on. Those elements will be created by PHP functions reading .ini files. A Static Web page will be in fact a collection of some of those elements tied together, each with it's own configuration. So two different sidebars on the site might come from two different .ini files, but will be generated by the same PHP function. After generation those PHP functions will not be run by the Static Pages. The Action Scripts will each have some very specific task. They will read their configuration from .ini files like the rest, but will be much less "controlled" by that information. The Admin Section will in fact be a mechanism for editing those .ini files without seeing them, and then clicking on a "Generate" button. The idea is to require as minimum as possible knowledge of HTML as possible by the user of the Admin Section. For example, the events log on the sidebar will be some small PHP code that simply injects some other file into the HTML code. Another Action Script will be responsible for re-generating this file, after any submission to the events table. And the Admin Section will make it possible to control the layout of this file and where in the Static Page it will appear. About Mirroring and automaticly changing content I am not sure yet. Mirroring is obviously done better with third-party programs such as wget. But since we want to enable easy admin control over them, then perhaps they will be controlled by Action Scripts that in turn will be controlled by the Admin Section. Content based on part of external sites is less complicated and will probably be extracted by Action Scripts, but it is somewhat more complicated to control such Action Scripts from the Admin Section, without poking through the code. With this said, articles, comments, events, links and the faq are nothing more then Static Pages dynamicly updated by Action Scripts in response to events such as user input, or admin intervention. Currently i plan to implement the first two parts, i.e Action Scripts and Static Pages, for everything we have at www.iglu.co.il at the moment, and not write even one line of code if possible of the Admin Section. Everything, for now, will be controlled through the .ini files. When and if i'll finish that i will move on to implement the Admin Section, and if i'll do the first part correctly, then the Admin Section will in fact be nothing more then an interface to modify those .ini files without seeing them, and will require minimum or no change to the Static Pages generation engine, and the Action Scripts. Later on it will be possible to easily add more feartures, "expose" more of Action Scripts behaviour to the .ini files and so on.
---------------------------------------------------------------------------- To unsubscribe, send a message to [EMAIL PROTECTED] Archives available at http://www.mail-archive.com/[email protected]/
