earth tech

In constructing a web application with more than 2 PHP source modules, I found that it is useful to have a quick and easy way of finding a syntax error that may exist in one (or more) of a list of included modules.

Getting a List of PHP Includes

There is a function in PHP for this, which we will get back to in a moment. For right now I wanted to address some things we can do at a Bash prompt to troubleshoot why a script may not be sending any output to the browser on STDOUT.

That's a very common situation when you're working on a large application with many modules. It becomes important in those situations to be meticulous about syntax checking each change in any code before making additional changes.

I've been using the 'Lint' mechanism provided by PHP to syntax check PHP source code. It works like this: 

  $php -l <fileName>

Now, some of you might already be seeing the implications of this. Hows about: 

$for fn in \
      `grep require frmPlayerInformation_body.09.inc\
      | perl -ne '/\"([a-zA-Z0-9.]+)\"\;/ && print "$1\n";'` ;;
 do 
      echo $fn ;;
      php -l $fn ;;
      echo "########" ;;
 done

The implications for scripting this operation from the command line are clear.

get_included_files()

PHP provides a function to get a list of module dependencies for a running script. It's called

get_included_files()

… and here's the URL for the docs: http://us2.php.net/manual/en/function.get-included-files.php

Problems with this Approach

There is at least one serious deficiency inherent in using the require, require_once, include, and include_once directives as the sole indicators of module dependency;  that is that, simply, the modules which are required or "included" due to HTML element attribute values.

Examples include the ACTION attrubute value(s) of HTML FORM element(s), the SRC attribute values for SCRIPT elements. and so on. IFRAME and LINK elements are also among those that can cause a module dependency within the HTML, CSS, or Javascript layer(s) generated by PHP code of a site.

Labels: 0x0000, bash, code, css, html, javascript, linux, perl, php, script, source, webappdev

posted by pd wilson   #   22:13

The World Wide Web Consortium (W3C) defines the HTML Document Object Module (DOM) as a standard. The DOM is used as a standardized way to programmatically access the content of HTML [and XML – we're only concerned with the HTML, here] documents.

Languages commonly used to access and modify the content of a DOM document instance [an instance of a DOM-conformant document] are Java and Javascript.

In this case, we are interested in accessing and modifying the content (data and meta-data) of an HTML document using Javascript to manipulate HTML elements using DOM-defined methods.

Reference Material

• Document Object Model (Core) Level 1 – REC-DOM-Level-1-19981001 from W3C
• HTML DOM Tutorial &ndash from w3schools.com
• HTML DOM Reference – provided by w3schools.com

Labels: html, javascript, w3c, web, webappdev, xml

posted by pd wilson   #   17:43

How cool is that?

Wanting to make some notes here about some things that I'm just now realizing are possible with the combined technologies mentioned in the title line. This is to remind myself to

1. look up whether or not some of these ideas have been implemented, like: I know for sure there are Javascript solutions out there for things like Color Selection Dialogs, calendar widgets for date/time entry, and so on. Not so sure about things like GUI interfaces to controlling CSS attribute properties. And didn't I see a Javascript (back in the day) that would set stylesheet properties in real time, on a page already loaded into the browser?
2. Write some code to implement things like positioning a control box on a form at design time - this is basically the VB concept: realtime control of the CSS properties [attributes?] of e.g. an HTML element (or a logical grouping of HTML elements - a "control") by up/down counter/spinners or drag/drop operations - Should be fairly simple to code up, so much so that I'm having trouble believing such doesn't already exist for the HTML/PHP/CSS universe.

These ideas deserve a more detailed study - just put them here to be sure they're written down and accessible.

The link at W3C that set all this thought process in motion – at least, this phase of it – is the one given above with the title:  http://www.w3.org/TR/CSS21/visuren.html#comparison

Labels: css, html, javascript, php, webappdev

posted by pd wilson   #   09:49

Overview

After installing MySQL, Apache2, and phpMyAdmin on an OpenSuSE 11.0 LAN server, phpMyAdmin (pma) shows two warnings on its main page.

The first regards the MySQL root user not having a password set, and telling us to configure MySQL. This problem was resolved peacefully and without incident by the simple expedient of opening the mysql.user table for edit (using phpMyAdmin — we are root, after all — and according to the warning…) and adding a password to the root account for access from both localhost and sturgeon [sturgeon being the host name].

The second is regarding something about potential problems with something called "Suhosin".

Suhosin

Suhosin, as it turns out, is a [software] "system" for "hardening" PHP installations against buffer overflows and other nasties both known and unknown — generally speaking, it sounds like something that we want to have installed on our [about to be] publicly accessible server.

The phpMyAdmin FAQ # 1.38 is quoted here:

1.38 Can I use phpMyAdmin on a server on which Suhosin is enabled?

Yes but the default configuration values of Suhosin are known to cause problems with some operations, for example editing a table with many columns and no primary key. Tuning information is available at http://www.hardened-php.net/hphp/troubleshooting.html, although the parameter names have changed (suhosin instead of hphp). See also the SuhosinDisableWarning directive.

Note that the information regarding the parameter names used in the parameter names &mdash I.E. Use [read] suhosin instead of hphp in the Hardened-PHP Project – PHP Security – Troubleshooting page [ http://www.hardened-php.net/hphp/troubleshooting.html] is not shown on the other pages referenced when one follows the link(s).

That means that the following passage from

The settings you need to adjust are:

• hphp.request.max_array_index_length
• hphp.request.max_totalname_length
• hphp.post.max_array_index_length
• hphp.post.max_totalname_length

… it then goes on to say: 

Additionally you might want to change the following settings because phpMyAdmin is an administrative backend and might needs many POST variables and the user might trigger SQL errors

• Increase hphp.request.max_vars, hphp.post.max_vars
• Disable hphp.sql.bailout_on_error
• Remove logging of failed SQL queries (⇒ S_SQL) from the log hphp.log.syslog, hphp.log.sapi, hphp.log.script

Labels: php, pma, suhosin, webappdev

posted by pd wilson   #   19:57