php App log processor

PHP log processor that parses local files for certain strings and if found, sends an e-mail with the a customizable title containing the name of the file in wich the string is found and customizable body including the string found. it will have an web interface for configuration. the script will be run via cron. ## Deliverables we have more projects based on the same library and architecture and working at Vmin can be the beggining of a strong collaboration. The archive contains the library, the preliminary code generated for this application, database structure, html interface example and requirements The code from the folder Vmin is generated code, having the purpose to make the development easier. You have to develop the application so that the interface look like the atached html files and behave as described in requirements. Please download the arhive and take a look at the generated code. You have to modify this code and eventually add new files so that the application behave as required The archive has the following content: doclibdev - the documentation for our library, it's a small and fast library lib - the library itself, including the sourcecode Vmin - the generated code for this application, including database structure html_schema - this is how we want the interface to look like At this point, all files from vmin excepting [login to view URL] are machine generated. when writing you must follow the following rules : <ol start="1"> * All the lines have to be limited to 80 characters long. * Only one statement is allowed per line. * Do not leave unnecessary blank lines. * Do not use tab character. Convert tabs to spaces (most of editorsprovide this option). * Align the new line with the beginning of the expression at the same level on the previous line. i.e. Do block related statements together. * Indent 2 spaces for each block and all continuation lines have to be indented. * Understand that at any moment, user can read only 25 or so lines of code. So, organize that code around that fact. That means: * Have functions that are smaller than 25 lines. Best way to create new functions is to abstract some part of the problem (domain, echnical, or linguistic) and provide a function for that. It always should be possible to get such an abstraction going. * If the function is large, break down into blocks, where each block is doing some unique activity. Use one line comment describe that activity. * Use appropriate formatting scheme to cut down on excessive lines. For examples, ornate commenting scheme is not good. Placing empty lines that does not indicate some semantic separation to the reader is not good. Also, use K&R scheme of indenting to maximize the information to lines ratio. * For complex logic functions, include the algorithm before the function body and after the comment section. * Understand that code is meant to be read and understood. That means, it should be readable, say, over the phone. That means: * Use meaningful names. Long names are not necessarily the most meaningful. It is ok to use i and j for indexing. If there is an abbreviation, such as num, no etc. use one unique abbreviation through out the project. * Use verbs in naming procedures, because it indicates action. Use names for functions that return values. * Never, ever use two names that differ only in capitalization, and punctuation. * Comments should not repeat the code. Comments are meant provide higher-level road map. That means: * Comments should explain the domain portion, not the code. * Comments should tell the reader why and what you are doing it, rather than how. * In case the code is tricky, explain the how, and tell them explicitly why it is tricky. * Use commenting style that is easy to maintain. the application must be skinnable, must permit translation to multiple languages whith a language file( you must create the english file) and allow selecting the language from settings. THE INTERFACE MUST BE COMPLETLY SEPARATED FROM THE BACKEND. the code must be well documented. any changes to the database must be aproved by us! html_schema is best wiewable at 1024x768. you must make the application scalable to any resolution. other requirements: - you must use object oriented programming -each class must have it's own file to facilitate the automated definition loading sistem that we use. -keep the language system close to what we use, make labels. -you must keep the files in the predefined folders render, execute, display, in the root or create other folders if necesary, - do not use require(), require_once() or include() in other places than those used by the generated code -u must avoid using nested levels higher than 3 - must avoid using algorithms that consume excessive resources - you must take care of security issues(sql injection, etc.) The application must work on the following platform: PHP 5.2 MySQL 5.0 apache 2.2.9 you can use any version of Apache 2, usually there are no compatibility problems. for MySQL, you can use any version of Mysql5, but use the documentation for mysql5.0 [login to view URL] You can use any version of PHP 5, but do not use elements for newer versions of php. The platform on wich we work is not fixed and will be upgraded as the tehnologies reach maturity. for installing the application follow this steps: - copy the dir's vmin and lib in the htdocs folder of your webserver. - edit the file vmin/[login to view URL] for windows platform and [login to view URL] for linux and set the parameters: SET MYSQL=write here the path to your mysql SET DB_USERNAME=username for the database SET DB_PASSWORD=the pasword for the database -edit the file vmin/[login to view URL]: X::$sql = new XSQL( "write_here_sql_username", "write_here_password", "vmin", "localhost" ); execute the script [login to view URL] or [login to view URL] and if there are no errors, you can acces the application at the link : http://yourhost/vmin/[login to view URL] in the alert log page must be a setting for how long to keep the logs.