dojo dijit Tri-State Checkbox Widget

The link above is a demonstration of a dojo dijit Tri-State Checkbox Widget. It includes a nice button interface to test the properties, methods, and events of the widget, some documentation, and a link so you can download the widget and the test code.

It has been integrated into a complex application and is working well.

Interesting notes on this widget:

  • Spent time exploring how to indicate an indeterminate state for a checkbox. The de facto standard is a small box within the box, so that is what is implemented.
  • Widget is actually a text input that can contain the values on, off, or indeterminate.
  • Used a blank.gif to create the space in the focus node.
  • Value can be set by using a boolean (true=on, false=off), number (0=off, 1=on, 2=indeterminate), or string (off,on,indeterminate)
  • Checked maps to on, unchecked is considered off
  • Value is sent to the server regardless of input state. This is different than a traditional checkbox, where the value is only sent if the checkbox is checked.
  • Tried to avoid duplicating effort, used inheritance as much as possible.
  • Realized that even a ’simple’ widget involves significant complexity, and thorough testing is important prior to integration into pages.
  • Discovered that building a widget for dojo 1 does not build a widget for 0.9 - had to build a second copy for 0.9 to integrate into an older application.
  • Appreciated the dojo / dijit architecture, it made adding the widget a nice, efficient process.

PHP Session Development Strategies

  • Use Firebug to get the session id off the page requests.
  • Find the directory session files are stored in. On busy, shared servers, this is often /tmp. Check /etc/php.ini or possibly /etc/httpd/conf.d/php.conf.
  • To simulate a session timeout on the server side, delete the session file.
  • To simulate a cookie timeout on the client side, delete all private data (FF) or cookies (IE).
  • To simulate a lost connection - disconnect or disable the network connection.
  • Use more to view the contents of a session file.
  • Use session files to reduce the amount of logic required for execution. You can assume the session file must be read for authentication, therefore, adding a few more bytes in to reduce execution time should yield a performance gain. Be careful to only store data which is valuable for enough operations that the storage increase is warranted.
  • ACL can be stored in session files. It may be faster than using a database.
  • Never store passwords in session data.
  • Language in use is good for storage in session files.
  • Session files must not be accessible through the web. Should only be accessible for appropriate users.

Generated profile.js for dojo Builds

To generate a profile.js file for dojo builds, you can use the following command string:

grep dojo.require * | sed “s/dojo\.require\ *(\ *\([\’\"][^\)]*\)).*/\1/” | awk ‘{l=length($0);if (FNR!=1) printf “\n,%s",$0; else printf “%s",$0;}’ > middle

Sample output:

"dojo.parser"
,"dijit.layout.ContentPane"
,"dijit.layout.TabContainer"
,"dijit.form.Button"
,"dijit.ColorPalette"

If this ouput is prefixed with (name the file top):

dependencies ={
    layers:  [
        {
        name: "mydojo.js",
        dependencies: [

and postfixed with (name the file bottom):

        ]
        }
    ],
    prefixes: [
        [ "dijit", "../dijit" ],
        [ "dojox", "../dojox" ]
    ]
};

It will yield a properly formatted profile.js file.

Use cat to assemble it, like so:

cat top middle bottom

Note that dojo.parser and other core elements don’t have to be specified, but it is simpler to leave them in.

Craching

Crache - Poorly configured server caching which prevents distribution of updated files such as CSS, images, and javascript. Crached pages display poorly until the browser cache is cleared.

*** This can be a very subtle problem, as developers often clear the browser cache by force of habit. They would not notice the problem. Site visitors that return to your site after updates may be presented with pages that do not display or function properly.

Key resources

(Apache)

http://httpd.apache.org/docs/2.2/caching.html
http://httpd.apache.org/docs/2.2/mod/mod_expires.html
http://httpd.apache.org/docs/2.2/mod/core.html#fileetag
http://httpd.apache.org/docs/2.2/mod/mod_cache.html

(Mozilla Firebug and YSlow)

https://addons.mozilla.org/en-US/firefox/addon/1843
https://addons.mozilla.org/en-US/firefox/addon/5369

Web Development Firms - Strategies for Today's Economic Environ

Internet services (building web sites and applications) used to be a black box type of service, the client requested a solution, a web company developed one, and then client relied on the service provider for all related work.

Times have changed.

  • Web sites are now perceived as vital communications connections. Clients want the content to be current, and fresh, to engage site visitors. This requires frequent updages and many clients want to manage their content themselves. This improves the response time and reduces the cost. It also requires a mechanism to allow them to maintain the content - usually a blog or content management system. Impact: web companies must be able to integrate designs with applications instead of building standalone pages and sites.
  • Everyone knows more about the web than before. They know many powerful software packages are available at no cost. They know a good team can make changes quickly. Impact: Expectations are higher, and response time is expected to be lower.
  • Web technology has exploded in every direction. Sites must be faster, more attractive, and more sophisiticated than before. Impact: Web professionals must continue learning and pushing the envelope at every opportunity. Web companies must hire the very best people they can afford.
  • Malicious netizens are a constant threat. Impact: Web companies must comply with all the appropriate rules and regulations to protect site visitors, and their servers. Everything, from server configuration, web application firewalls, HTTPS/SSL/SSH/SFTP access must be carefully considered. Application security issues must be identified and addressed quickly.
  • Most companies already have a web site. Impact: There may be a significant investment in content and code. Protecting the investment, while reengineering the system in a cost effective manner may be difficult.
  • Many clients are facing difficult financial choices. The impact of a web site can be difficult to estimate in terms of revenue. Impact: A key opportunity for web companies is providing measurable benefits for clients. Although it may be difficult to illustrate revenue impacts, clear reduction in service costs should be offered. This requires that the web company be able to deliver services in a very streamlined manner.
  • Clients need to know what makes a web company a good fit for their project. Most are more concerned with what they want done, than work a company did for others. Impact: Displaying a portfolio of work done is less valuable than providing an interactive guide to assist a client in understanding the types of services (and possibly the costs) they need.