PHP

Perl

Keeping what we have

Victor, 2005.03.13

Hi guys, Here's some thoughts on how we could do a 2idi dispatch model:

1. Server doc root (e.g. htdocs/) will contain index.php and the images/, css/ and javascript/ directories, and nothing else. These three directories serve files directly to client requests (e.g. <img> tags) -- everything else is called through index.php, which is the dispatcher.

2. Calls to the dispatcher are made like this:

So for instance, what is now called with http://2idi.com/grs/create_account.php would instead be http://2idi.com/grs/create_account and the rewrite rule would turn it into /index.php?r=grs&o=create_account

If no operation parameter is set the default response for that resource is called (like calling resource/index.php in the normal system), and no operation or resource gives the site's home page.

Query strings can also be sent:

Data can also be POSTed.

3. The first thing the dispatcher does is figure out whether it's being called on the command line or by the web server:

4. We now have several include files, such as commonib, that contain many functions. This makes a particular function hard to find. I think that maybe we should put each function in its own file, so that we know that some_weird_function() can always be found in lib/functions/some_weird_function.inc.

5. After examining its environment, the dispatcher should usually instantiate and initiate the db_connect class. It can then clean and initialize its input parameters (a db connection is neccessary to run mysql_real_escape_string, which is much better than addslashes).

6. The dispatcher then selects a data processor to include, based on a lookup table keyed to the resource/operation parameters. The data processor in turn includes all the functions it needs, and instantiates all the classes it needs, and processes the input data. Output can be delivered as scalar variables or single or multi-level arrays, or object parameters.

7. Once the data processor has completed, dispatcher includes an output processor, selecting the output processor from its lookup table based on $caller and resource/operation parameters.

If it is a command line output processor it may perhaps just issue a series of print commands on the output variables.

If it is a unit-test output processor (another $_ENV variable may have to be set to let the dispatcher know this), it could compare the output data to expected values and print success or failure statements to the command line.

If it is the httpd output processor, it will process the output similar to the way a combination of the current template_top.inc file and the various php file do, but the goal is to separate the processing from the html output, which is done in another step:

8. The httpd output processor includes a complete HTML file (starting with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"). The goal here is to have HTML files that can be opened in wysiwyg editors such as Dreamweaver, so that actual graphic designer type people can work on them. Dreamweaver will ignore any PHP in the file. All output should be inserted into the HTML file as single variables <?php print $variable; ?>. Successive <p>...</p>, or a series of table rows should be concatenated into a single variable by the httpd output processor.

The one problem I see with this last is getting the correct css file into the HTML header. To open the file in Dreamweaver properly, it needs a css definition, but the output processor needs to choose a css file depending on the registry context. Still pondering this.

Feedback please!

=vg

Mike, 2005.03.14

I think we did a pretty decent job of separating logic and presentation in the current html pages. Logic mostly occurs before the template include, presentation after though some simple data queries are within the presentation layer.

Rather than address Victor's proposal line by line, here is a complete and somewhat similar approach:

The Controller resides at /index without an extension. The url rewrite can add the extension to trigger php processing or we can alter the php processing rule. In any case, the extension can be dropped from the public uri.

The controller instantiates a generic Control class which includes the current set of commonib includes and the target resource.

The target resource, for example /grs/create_account, resides in ibroker/resources at the same level as ibroker/lib and ibroker/htdocs. This is to keep it out of the httpd document path. ibroker/resources is added to the php include path.

Target resource files are refactored into Model and View. Currently every file contains an html View. Most pages do some data "modeling." Each Model and each View are instances/extensions of the generic Model and View classes. Generally the Model is the code that comes before

in the page code and the View is everything afterwards.

The Control instance calls the Model constructor and then the appropriate (html, xml, wap, ...) View constructor which does a series of echo/print statements.

I don't think we should move what is currently in templates into strings in each View. Instead, each View should include the appropriate template.

I don't think we should put every function in its own file. This would create its own kinds of complexity and confusion. I-broker installations that don't have fancy include caching will not appreciate the file churn. Instead, we could create classes to contain related functions. Each class can go in it's own include file or into a file of related classes. For example

would become

This will make it easy to find functions and keep the number of includes to the same size as we have now.

The Model object should always return one or more of a set of standard types so that generic View objects can always represent them with minimal customization.

Issues:

Options

Mike

DevelopmentFrameworks (last edited 2008-07-04 06:04:45 by localhost)