web notes - a blog

Virtually every site or web application should consider the following:

• Multilingual capable - even if the content is not immediately available in other languages. Retrofitting translation into a site is extremely costly.
• Common components - any code that will execute in more than one place should be shared through includes or other mechanisms.
• Hierarchical templates - this provides a more consistent interface and more efficient code. Templates must be general enough to support this.
• Appropriate user assistance - help, at both the field and page level
• List of browsers supported - you can’t support every browser. Identify those you will.
• Graceful error handling - don’t just issue a print or echo and die
• Security - close the windows and doors into your application. Ensure error handling prevents disclosure of code and database elements
• Configuration - database access constants should be sourced from a single point, as should all other configuration directives. This ensures all elements of the application, including backend/offline scripts. Otherwise, the constants can’t be changed without risking the integrity of the system.
• Server configuration - prevent access to areas the site visitor should not see at the server level.
• Multi-mode deployment - only put the code required on the server. Set up the distribution/installation process accordingly.
• Use mod_security.
• Let the web server be the only reader of script files. This makes it more difficult for hackers to get to the web code.
• Use robots.txt and meta tags to keep things out of search engines unless necessary.
• Change off port 22 for SSH, or close it entirely from public access
• Enforce these practices across the entire team, and audit for them during development

AJAX can be implemented in many different ways.

Options:

• Place all the interface logic on the client side, and have the server act only as backend functionality. For a complex application, this method may be prohibitively difficult. The overhead of placing all the logic on the client side, and managing its delivery and execution is probably not worth the performance gains.
• Segmenting the pages and populating them with HTML and related logic from the server. This would be using something similar to dojo content panes, which are HTML content. Similar to iframes.
• Half JAX. Run the pages as HTML templates, augmented with AJAX navigation/population. Thus, the HTML remains static for the page, but the AJAX is used to fill the fields and provide advance features. With an efficient template engine and a sophisticated architecture, this is an excellent approach.
• Use straight HTML pages, with a template engine. There is no law that AJAX must be used. :)

Delivering the HTML, with AJAX for form population and rich interface features is a nice compromise. The pages remain fairly fast, the rich features are available, and the complexity is limited. This is best implemented with a good architecture of reusable/common components.

http://chyngachanga.ru/content/wuge/owofi/
http://mslayouts.ws/icons/administrator/components/com_menus/etotag/adusoq/
http://sans-packing.ru/img/jipeqap/ehudute/
http://www.antwerpsupporter.be/mvdm_polls/includeold/olom/yeq/
http://www.blankner.ocps.net/media/yeloc/taqohu/
http://www.elettrodataservice.it/foto_articoli/pivafof/sena/
http://www.eloge-du-bien-commun.be/blog/bundled-libs/Net/ocoqen/yurowej/
http://www.filter-international.com/webservice/aro/pefosi/
http://www.foicr.org/work/mulito/esa/
http://www.interkonet.com/galeria/modules/albumselect/ucu/iwuy/
http://www.meijers.com/images/products/ubemebe/oqe/
http://www.psikolojikyardim.org/etkinlik/include/eto/rix/jas/
http://www.qubestunes.com/treytest/1/adoyuru/zagu/
http://www.service-exposants.com/store/iyi/ifiduw/
http://www.thoseguysfilms.com/forums/templates/subSilver/images/timuji/oju/
http://www.unduetretoccaate.it/codice/fog/azato/
http://www.urlaub-reisen-privat.de/gymnasium/pictures/ahamoha/zotu/

from 211.218.149.2 (probably spoofed)

Ladies and gentlemen, check your servers … :)

Many web development projects are done outside conventional version control environments. The overhead of version control simply can’t be justified for a small application or the customization of a site. However, it the development is performed by a team, particularly a distributed team, common etiquette should be observed.

• Don’t change other people’s code. Either request they change it to your specifications, or ask if it is okay for you to make the change. If you receive such a request, reply promptly and act promptly, otherwise, you should assume the requestor will make the change.
• Keep your own backup. This is a good practice anyway. This includes the database.
• Use a site architecture that makes it easy to separate design and logic, and communicate it to the team. For example - all CSS/HTML/templates are the domain of the design team, all PHP/applications/installations are engineering.
• Identify an authority to resolve any conflicts, and clearly document any likely exceptions to the file architecture above.

To compress the content delivered to a dojo ContentPane, you can compress the content and cache it with the Zlib functions of PHP, then open it with the filesystem functions and deliver it with the Content-Type header set to “text/html” (or other appropriate setting), and Content-Encoding set to “gzip“.

The compress and cache should be performed if the file is likely to be reused. If reuse is unlikely, or the file is relatively small, use gzencode or gzdeflate.

This should work with other libraries as well.