Category: "JavaScript"

PHP and javascript timestamper

Nov 2nd

Posted by elvis in PHP

This is an extension of an earlier script to demonstrate the difference in execution time of preg_replace and trim.

The objective of this demonstration is to show a quick time check method to determine the following:

  • Time required for PHP to process all statements
  • Time required for javascript to process all statements

This code is valuable for complex pages, specifically RIA pages, to assist engineers in finding ways to make the page display more quickly.


/* First line of the PHP script */
$fStartPHP=microtime(true);

/* Beginning of the HTML */
echo '<html>';

/* This captures the time the first javascript statement was executed */
echo '<script>var d=new Date();var jsStart=d.getTime();var jsEnd;</script>';

/* This captures the time the page has finished loading.  If other code is executed prior to the page being considered fully rendered and functional, the EndLoad function should be called after the last statement */ 
echo '<script>function EndLoad(){var d=new Date();jsEnd=d.getTime();jsElapsed=jsEnd-jsStart;document.getElementById(\'jsStartDisplay\').innerHTML=jsStart;document.getElementById(\'jsEndDisplay\').innerHTML=jsEnd;document.getElementById(\'jsElapsedDisplay\').innerHTML=jsElapsed;}</script>';

/* Body tag */
echo '<body onload="EndLoad()">';

/* At the end of the PHP script */
dd
$fEndPHP=microtime(true);
$fPHPElapsed=$fEndPHP-$fStartPHP;
echo 'PHPStartTime: ';printf("%f",$fStartPHP);echo '<br />'."\n";
echo 'PHPEndTime: ';printf("%f",$fEndPHP);echo '<br />'."\n";
echo 'PHPElapsed: ';printf("%f",$fPHPElapsed*1000000);echo ' microseconds <br />'."\n";
echo '<hr />';
echo 'HTML/JSStartTime: <span id="jsStartDisplay"></span><br />'."\n";
echo 'HTML/JSEndTime: <span id="jsEndDisplay"></span><br />'."\n";
echo 'HTML/JSElapsedTime: <span id="jsElapsedDisplay"></span>&nbsp;microseconds<br />'."\n";
echo '</body>';
echo '</html>';

dojo - Smarty - PHP - Synchronizing client- and server-side validation

Oct 18th

Posted by elvis in PHP

The following architecture with Smarty and dojo allows you to the client and server synchronized for validation for RIA/PHP applications.

Each input has 4 characteristics defined in a (PHP) .ini file - 

V_input_name = regExp (usually includes length)
L_input_name = max length
R_input_name = true or false (required or not)
T_input_name = type of input data in database, used to support documentation



Each input also has 3 characteristics defined in a Smarty .conf file, and there is a .conf file for every language (.ini be under languages)

E_input_name = error message
I_input_name = invalid message
P_input_name = prompt message

Smarty constructs the input tags like so:

<input type="text" dojoType="dijit.form.ValidationTextBox"
    name="input_name" id="input_name"
    regExp="{#V_input_name#}"   
    errorMessage="{#E_input_name#}"
    promptMessage="{#P_input_name#}"
    invalidMessage="{#I_input_name#}"
    length="{#L_input_name#}" />



There is a simple javascript validation that accepts an array of inputs and tests if they are valid with input_name.isValid(), displaying input_name.errorMessage if not, and cancelling the submit.

On the server side, there is a loop that tests the inputs against the same strings:

foreach ($aInput as $k => $v)
  if (isset($aIni['V_'.$k]))
  { 
    $sInput=trim($v); 
    if (isset($aIni['R_'.$k])
    if (($aIni['R_'.$k]=='true') && ($sInput=='')) /* Test for required */
      return false;
    if (!filter($aIni['V_'.$k],$v))  /* flter ensures data complies with regexp */
        return false;
   }



This allows the client-side code to help the user enter valid data, and allows the server-side code to protect the server by disallowing or discarding data that isn’t valid.

Please note that page-level validation, where the required state and content of data may vary based on other inputs must be reflected at both the client and server side.

What you can do with FireBug

Oct 18th

Posted by elvis in JavaScript

  • Debug javascript
  • Examine the DOM tree
  • Understand the CSS
  • Change the CSS in the browser to see its effect
  • See the layout of the page
  • Determine the dimensions of page elements
  • See the page components and understand the page load process
  • View the HTTP headers
  • Evaluate javascript expressions and commands interactively
  • Use debug write (console.debug) statements to issue debug data
  • Add breakpoints
  • Profile your page

If you use it, all the time, contribute. Ask your employer to support it.

RIA server filesystem architecture

Sep 1st

Posted by elvis in LAMP

The /opt directory can be used to store shared components, as follows:

  • /opt/os - All open source components

  • /opt/common - All common scripts, such as form validation for contact us forms, anti-spam code.

    • /antispam

      • /html - (html and javascript) - to assist the user
      • /php - to protect the server
    • /footer - Footer text, specifically the company name and copyright indicator. This ensures it can be changed in one place to update every page on the server.

New accounts could access these components like so:


ln -s /opt/os/dojo 
ln -s /opt/os/Smarty 
ln -s /opt/os/Zend
ln -s /opt/common/html 
ln -s /opt/common/php
ln -s /opt/common/footer

These links allow relative references to the common resources, while providing central sourcing.

RPM Compliant Web Applications

Aug 27th

Posted by elvis in Web Applications

RPM compliant web applications and toolkits must meet the following requirements:

  • Dissociation of customization and extensions from the application. This includes all configuration parameters, such as database access settings, design elements, and plug-ins from the core application files. Thus, a web application can be installed as an RPM, accessed through a symbolic link, and customized for an account with the appropriate directories at the account level. In this way, multiple accounts can use the same core code, while remaining independent. This requirement can be waived if the application will be used with dedicated servers.
  • Packaging with careful attention to Provides and Requires to ensure interdependencies are observed.
  • Conflict resolution must be established to ensure incompatible components are not installed.

Popular web applications should consider an RPM compliant file system architecture for the following reasons:

  • Disk space Most powerful applications require a significant amount of disk space. RPMs allow a single installation to serve an entire server.
  • Security and maintenance RPMs can be managed with automatic updates, ensuring security and update patches are applied promptly, automatically.
  • Local security Managed properly, using a common source to serve an application can allow a server administrator to provide the application, but prevent account holders from modifying it. This would be extremely valuable for hosting companies.
  • Ease of installation/distribution By making RPMs available, distributing them with operating systems, and publishing them in repositories, they are easier to install and use.
  • Standardization RPMs can ensure that web applications are always installed in the same place. This can be very helpful for technical support.
  • Bandwidth RPMs may reduce the bandwidth required for distributing applications, by making them available from more sources.

Risks and disadvantages of this approach include:

  • Loss of flexibility, all accounts will use the same core code. Extensions will have to be used to customize the applications.
  • Skill level of the server administrator and application engineers must be adequate to ensure graceful use of the application within a shared architecture.
  • Security, if the core code is compromised, all accounts on the server will be affected.
  • Many web applications would require significant changes to use an RPM compliant filesystem architecture.

At this time, the best candidates for distribution as RPMs are javascript libraries. These libraries offer very powerful features for web sites and applications, and are very rarely changed. They are usually executed on the client side, and the CSS can be overridden easily, eliminating concerns about customization. A single symlink from the account makes them accessible for a site.

1 2 3 ...4 ... 6 ...8 ...9 10