eshwar's Web World: 2006-09-10

PHP AJAX Frameworks

Visit this link for more information

Tags: php, ajax, frameworks, php ajax frameworks

Can't find what you're looking for? Try Google Search!

Javascript Remoting Frameworks

Visit this link for more information

Tags: javascript, remoting frameworks, javascript frameworks, frameworks, ajax, toolbox

Can't find what you're looking for? Try Google Search!

Show Progress Indicator Sample Example

This demo introduces a progress display to the Basic Sum Demo. It's a simple animated GIF that shows up while waiting for the sum to return.

To the initial HTML, an Img tag has been added to include the animation, initially hidden by the corresponding script.

  <img id="progress" src="progress.gif" />

  window.onload = function() {
    $("progress").style.visibility = "hidden";
    ...
  }

Now all we have to do is show the animation upon submitting and hide it when the result is in.

 function submitSum() {
   $("progress").style.visibility = "visible";
   ...
 }

 function onSumResponse(text, headers, callingContext) {
   $("progress").style.visibility = "hidden";
   ...
 }

Tags: progress indicator example, simple example, html, animation

Can't find what you're looking for? Try Google Search!

Calculate propotion of task that's complete in AJAX Progress Indicator

For longer delays, you need to help the user understand how much has been achieved so far, typically using a progress meter that shows percent complete. Sometimes, a long delay can come from a single XMLHttpRequest Call, because although the network transfer may be quick, the back-end processing might not be. For example, the call might trigger a major database operation.

You probably won't get any useful information about its progress by monitoring the responseText component. The responseText tends not to populate in a linear fashion, for two reasons. Firstly, there are usually back-end calculations involved, during which no output can occur. Thus, output tends to happen in bursts, or all at the end. Secondly, the output is often compressed using the standard HTTP content encoding facility, and the compression algorithm will force data to be outputted in bursts. The XMLHttpRequest's readyState also won't tell you very much. For reasons described in Call Tracking, you can only rely on states 0 and 4, and maybe 1.

So if you can't monitor the progress of an XMLHttpRequest Call, how can you help the user understand how much progress has been made? One thing you can do is Guesstimate: predict the total time, and start running a timer to monitor how long since the call began. The prediction of total duration need not be hard-coded every time; you could have the application track download times and reflect them in the estimates next time round. It's possible the actual time will exceed your estimate, and you wouldn't want to show a progress of 120% while the download's still in progress. You also don't want to suddenly drop the progress percentage by increasing the time estimate. So you need to treat the 100% figure as asymptotic - always approaching it, but never getting there. The details are beyond the scope of this pattern, but what you need is a formula which transforms time so far into a value that starts at 0 and approaches 100. An additional constraint is that it must fit with your estimate, so you might perhaps ensure your estimate is reached at the 80% point, allowing room for the progress meter to grow past it if the transfer takes longer. One last thing: no matter what the figure ends up at, be sure to drive it up to 100% at the end, to maintain the illusion that this is a real progress meter.

Another way to deal with long XMLHttpRequest Calls is to explicitly introduce a second monitoring channel. While the primary request takes place, a sequence of monitoring requests are issued to ask the server for a progress estimates. For example, the server might be looping through 1000 records, running a transformation on each of those and saving it to the database. The loop variable can be exposed so that a monitoring service can convert it into a percentage remaining figure.

Not all Progress Indicators concern a single XMLHttpRequest Call. Indeed, those requiring a progress meter are longer processes, likely incorporating several XMLHttpRequest Calls. There, you do have much better scope for real-time progress monitoring - each time a call returns, further progress has occurred. In a simple model, you can show progress is 50% complete when 2 of 4 calls have returned.

Visit this link for more information

Tags: ajax, progress indicator, ajax applications, xmlhttprequest, http request

Can't find what you're looking for? Try Google Search!

AJAX Progress Indicator for server responses

Ajaxian applications often make XMLHttpRequest Calls to query and update the server.
Unlike standard page reloading, the browser doesn't make it obvious that an XMLHttpRequest Call is occurring. There usually won't be any information in the status area and the "throbber" (that is, the icon that normally shows loading activity, such as the "e" at the top-right of IE) will not throb.
There's a geographical component to server call delays. To provide good feedback, you should provide an idea of which page elements are affected.
Users like to feel in control, and that control is taken away when the user's waiting for a response. It's not just the delay that should be minimised, but the perceived delay.

Indicate the progress of server calls. You can't always reduce delay, but you can adopt Progress Indicator to ease the pain. A Progress Indicator helps maintain the user's attention, improves the user's understanding of how the system works, and also communicates that the system is still alive even if a response hasn't yet occurred.

The progress indicator is typically introduced to the DOM once an XMLHttpRequest Call begins and removed when the call has returned. The easiest way to detect the call has returned is in the XMLHttpRequest callback function. An indicator need not relate to a single call - it can show progress for a sequence of related calls.

Sometimes, it's a Popup element instead of a new element directly on the page. An increasingly popular idiom is a small opaque Popup on the corner of the page showing just a word or two.

For shorter delays, typical progress indicators include:

A small message like "Updating document".
An animated icon.

For longer delays, the following can be used:

A meter showing how much progress has been made.
An estimate of time remaining.
A sequence of messages indicating what's happening at present.
Content that's engaging but not directly related to the progress, such as Tip of the Day or a canned graphical depiction of system activity.

Of course, you can combine these approaches. Generally speaking, some form of unobtrusive animation is worthwhile in any Progress Indicator, because it at least tells the user something's happening, even if progress is temporarily stuck. In addition, longer delays should usually be completed with a visual effect such as One-Second Spotlight, since the user's focus has probably moved elsewhere by that stage.

Note that one form of indicator to avoid is changing the cursor. Many traditional GUIs switch over to a "rotating hourglass" or related icon during delays. That's probably inappropriate for Ajax, because it's something the actual browser software will does it too, e.g. while loading a new page, so it's likely to create confusion.

Visit this link for more information

Tags: ajax, progress indicator, ajax applications

Can't find what you're looking for? Try Google Search!

Javascript Multipurpose Frameworks

Visit this link for more information

Tags: javascript, frameworks, javascript frameworks

Can't find what you're looking for? Try Google Search!

On Demand Javascript Lazy loading

Download Javascript as and when required, instead of downloading it all on page load. This is a "lazy loading" approach applied to Javascript, and has several benefits:

Initial page load is faster.
Overall bandwidth usage is less, since only Javascript that's required is used.
Deployment is easier as the code takes care of pulling in Javascript, with the coder only ensuring enough is there to kick the process off.
You can produce snippets of Javascript on the fly - effectively sending back a kind of "behaviour message" advising the browser on its next action. This is a variant of the core pattern described at the end of this section.
You can bypass the standard "same-domain" policy that normally necessitates a Cross-Domain Proxy. Provided a server exposes a segment of valid Javascript, it can be extracted by the browser.

Conventionally, best practice has been to include Javascript unobtrusively - by including it in one or more script tags.

  <html>
    <head>
      <script type="text/javascript" src="search.js"></script>
      <script type="text/javascript" src="validation.js"></script>
      <script type="text/javascript" src="visuals"></script>
    </head>
    ...
  </html>

On-Demand Javascript builds on this approach to suggest just a minimal initialisation module in the initial HTML:

  <html>
    <head>
      <script type="text/javascript" src="init.js"></script>
    </head>
    ...
  </html>

The initialisation module declares whatever behaviour is required to start up the page and perhaps enough to cover typical usage. In addition, it must perform a bootstrapping function, pulling down new Javascript on demand.

visit this link for more information

Tags: javascript, lazy loading, on demand javascript, page load, browser, best practice

Can't find what you're looking for? Try Google Search!

.NET AJAX Frameworks

Visit this link for more information

Tags: .net, ajax, .net ajax, .net ajax frameworks, frameworks, ajax.net, asp.net, fastpage

Can't find what you're looking for? Try Google Search!

Disadvantages or Downsides of AJAX

Ajax is a trade-off. Any developer considering its adoption should be aware of the downsides, such as:

Limited Capabilities: Some Ajax applications are certainly doing things people never dreamed were possible on the web, but there are still substantial restrictions of the web platform. For example: multimedia capabilities, local data storage, real-time graphics, interaction with hardware such as printers and webcams. Support for some of these are improving in recent browsers, some can be achieved by delegating to Flash, but many are simply not possible, and if required, would rule out Ajax.
Performance Concerns: Constant interaction between browser and server can make an application feel unresponsive. There are, however, quite a few well-known patterns for performance optimisation such as browser-side caching. These usually suffice, even for fast-paced applications like stock trading, but Ajax still might not work for really time-critical applications such as machine control.
Internet Access Required: The user can't access an Ajax application in the absence of a network connection.
Second Programming Language: Serious Ajax applications require some knowledge of Javascript. Many developers are discovering that Javascript is actually a more capable language than at first assumed, but there is nevertheless an imposition to use a language different to that on the server-side.
Easily Abused: As with any powerful technology, Ajax concepts can be abused by careless programmers. The patterns on this site are intended to guide developers towards more usable solutions, but the fact remains that Ajax isn't always used in a manner that supports usability.

Visit this link for more information

Tags: downsides of ajax, disadvantages ajax, performance, ajax applications

Can't find what you're looking for? Try Google Search!

Characteristics of AJAX applications

The characteristics of Ajax applications include:

Continuous Feel: Traditional web applications force you to submit a form, wait a few seconds, watch the page redraw, and then add some more info. Forgot to enter the area code in a phone number? Start all over again. Sometimes, you feel like you're in the middle of a traffic jam: go 20 metres, stop a minute, go 20 metres, stop a minute ... How many E-Commerce sales have been lost because the user encountered one too many error message and gave up the battle? Ajax offers a smooth ride all the way. There's no page reloads here - you're just doing stuff and the browser is responding.

Real-Time Updates: As part of the continous feel, Ajax applications can update the page in real-time. Currently, news services on the web redraw the entire page at intervals, e.g. once every 15 minutes. In contrast, it's feasible for a browser running an Ajax application to poll the server every few seconds, so it's capable of updating any information directly on the parts of the page that need changing. The rest of the page is unaffected.

Graphical Interaction: Flashy backdrops are abundant on the web, but the basic mode of interaction has nevertheless mimicked the 1970s-style form-based data entry systems. Ajax represents a transition into the world of GUI controls visible on present-day desktops. Thus, you will encounter animations such as fading text to tell you something's just been saved, you will be able to drag items around, you will see some static text suddenly turn into an edit field as you hover over it.

Language Neutrality - Ajax strives to be equally usable with all the popular languages rather than be tied to one language. Past GUI attempts such as VB, Tk, and Swing tended to be married to one specific programming language. Ajax has learned from the past and rejects this notion. To help facilitate this, XML is often used as a declarative interface language.

To prevent any confusion, these things are not characterstic of Ajax:

Proprietary: "Ajax" is perhaps one of the most common brand names in history, but in context of web design, "Ajax" is neither the name of a company nor a product. It's not even the name of a standard or committee. It's a label for a design approach involving several related technologies.
Plugin-Based: Ajax applications do not require users to install browser plugins, or desktop software for that matter.
Browser Specific: As long as the user is working with a relatively recent, mainstream, browser (say 2001+), the application should work roughly the same way. Browser-specific applications somewhat defeat the purpose of Ajax.

Visit this link for more information

Tags: ajax, ajax application, characteristics of ajax, response time

Can't find what you're looking for? Try Google Search!

Lifecycle of an AJAX application

The Ajax lifecycle is more like that of a traditional GUI than a traditional web application, with DOM objects acting like GUI widgets. The script registers event listeners on DOM objects, and manipulates the DOM in response to those events. As part of the event-processing cycle, the server may be invoked. There's actually a slight complication here in that the server calls are asynchronous, so the event-listening phase is split from the event-responding phase.

Here's a typical Ajax lifecycle within the browser:

Visit: The user visits a site the usual way, i.e. by clicking on a link or typing a URL.
Initialisation The page initially loads. Callbacks are established to handle user input, a loop might be established to continously refresh page elements.
Event Loop:
- Browser Event An event occurs, such as a keypress.
- Server Request The browser sends a request to the server.
- ...<Server processes the event>
- Server Response A moment later, the server responds, and the response is passed into a request callback function, one that was specified when the request was issued.
- Browser Update The request callback function updates the DOM, including any Javascript variables, according to the response.

Of course, there are plenty of variants. In particular, many events are handled locally and don't actually trigger a trip to the server. Also, some Ajax applications are short-lived and the browser interaction is eventually terminated with the user submitting a form. Others remain to interact with the user as long as they are in the user's browser.

Note that the Browser Event and the Server Request occur in one thread, and the Server Response and Browser Update occur in a separate thread. This is due to the asynchronous nature of the server request. It's actually possible to configure XMLHttpRequest to make synchronous calls, but poor practice as it holds up the user.

Visit this link for much more information

Tags: AJAX, ajax lifecycle, gui, dom objects, widgets, browser, browser event, server, request, response

Can't find what you're looking for? Try Google Search!

Java AJAX Frameworks

You can visit AjaxPatterns for more information

Tags: AJAX, AJAX frameworks, java ajax, ajax patterns

Can't find what you're looking for? Try Google Search!

Best Practices Using DateTime in .NET Framework

Many programmers encounter assignments that require them to accurately store and process data that contain date and time information. On first glance, the common language runtime (CLR) DateTime data type appears to be perfect for these tasks. It isn't uncommon, however, for programmers, but more likely testers, to encounter cases where a program simply loses track of correct time values. This article focuses on issues associated with logic involving DateTime, and in doing so, uncovers best practices for writing and testing programs that capture, store, retrieve, and transmit DateTime information.

"The CLR System.DateTime value type represents dates and times ranging from 12:00:00 midnight, January 1, 0001 AD to 11:59:59 PM, December 31 9999 AD." Reading further, we learn, unsurprisingly, that a DateTime value represents an instant at a point in time, and that a common practice is to record point-in-time values in Coordinated Universal Time (UCT)—more commonly known as Greenwich Mean Time (GMT).

At first glance, then, a programmer discovers that a DateTime type is pretty good at storing time values that are likely to be encountered in current-day programming problems, such as in business applications. With this confidence, many an unsuspecting programmer begins coding, confident that they can learn as much as they need to about time as they go forward. This "learn-as-you-go" approach can lead you into a few problems, so let's start identifying them. They range from issues in the documentation to behaviors that need to be factored into your program designs.

The V1.0 and 1.1 documentation for System.DateTime makes a few generalizations that can throw the unsuspecting programmer off track. For instance, the documentation currently still says that the methods and properties found on the DateTime class always use the assumption that the value represents the local machine local time zone when making calculations or comparisons. This generalization turns out to be untrue because there are certain types of Date and Time calculations that assume GMT, and others that assume a local time zone view.

The Rules

Calculations and comparisons of DateTime instances are only meaningful when the instances being compared or used are representations of points in time from the same time-zone perspective.
A developer is responsible for keeping track of time-zone information associated with a DateTime value via some external mechanism. Typically this is accomplished by defining another field or variable that you use to record time-zone information when you store a DateTime value type. This approach (storing the time-zone sense alongside the DateTime value) is the most accurate and allows different developers at different points in a program's lifecycle to always have a clear understanding of the meaning of a DateTime value. Another common approach is to make it a "rule" in your design that all time values are stored in a specific time-zone context. This approach does not require additional storage to save a user's view of the time-zone context, but introduces the risk that a time value will be misinterpreted or stored incorrectly down the road by a developer that isn't aware of the rule.
Performing date and time calculations on values that represent machine local time may not always yield the correct result. When performing calculations on time values in time-zone contexts that practice daylight savings time, you should convert values to universal time representations before performing date arithmetic calculations. For a specific list of operations and proper time-zone contexts, see the table in the Sorting out DateTime Methods section.
A calculation on an instance of a DateTime value does not modify the value of the instance, thus a call to MyDateTime.ToLocalTime() does not modify the value of the instance of the DateTime. The methods associated with the Date (in Visual Basic®) and DateTime (in the .NET CLR) classes return new instances that represent the result of a calculation or operation.
When using the .NET Framework version 1.0 and 1.1, DO NOT send a DateTime value that represents UCT time thru System.XML.Serialization. This goes for Date, Time and DateTime values. For Web services and other forms of serialization to XML involving System.DateTime, always make sure that the value in the DateTime value represents current machine local time. The serializer will properly decode an XML Schema-defined DateTime value that is encoded in GMT (offset value = 0), but it will decode it to the local machine time viewpoint.
In general, if you are dealing with absolute elapsed time, such as measuring a timeout, performing arithmetic, or doing comparisons of different DateTime values, you should try and use a Universal time value if possible so that you get the best possible accuracy without effects of time zone and/or daylight savings having an impact.
When dealing with high-level, user-facing concepts such as scheduling, and you can safely assume that each day has 24 hours from a user's perspective, it may be okay to counter Rule #6 by performing arithmetic, et cetera, on local times.

Best Practice #1

When coding, store the time-zone information associated with a DateTime type in an adjunct variable.

Best Practice #2

When testing, check to see that stored values represent the point-in-time value you intend in the time zone you intend.

Best Practice #3

When coding, be careful if you need to perform DateTime calculations (add/subtract) on values representing time zones that practice daylight savings time. Unexpected calculation errors can result. Instead, convert the local time value to universal time, perform the calculation, and convert back to achieve maximum accuracy.

Best Practice #4

When testing, calculate the value you expect to see in the XML string that is serialized using a machine local time view of the point in time being tested. If the XML in the serialization stream differs, log a bug!

Best Practice #5

When writing code to serialize classes that have DateTime member variables, the values must represent local time. If they do not contain local time, adjust them prior to any serialization step, including passing or returning types that contain DateTime values in Web services.

Best Practice #6

When coding, make DateTime member variables private and provide two properties for manipulating your DateTime members in either local or universal time. Bias the storage in the private member as UCT time by controlling the logic in your getters and setters. Add the XML serialization attributes to the local time property declaration to make sure that the local time value is what is serialized.

Best Practice #7

When testing, if your programs accept user input specifying date and time values, be sure to test for data loss on "spring-ahead", "fall-back" 23- and 25-hour days. Also make sure to test for dates gathered on a machine in one time zone and stored on a machine in another time zone.

Best Practice #8

When you are coding and desire to store current time represented as universal time, avoid calling DateTime.Now() followed by a conversion to universal time. Instead, call the DateTime.UtcNow function directly.

Caveat: If you are going to serialize a class that contains a DateTime value, be sure that the value being serialized does not represent Universal time. XML serialization will not support UCT serialization until the Whidbey release of Visual Studio.

Get more information

Tags: .NET, .NET Framework, DateTime, Best Practices, CLR, System.DateTime, programming, time zones, universal time

Can't find what you're looking for? Try Google Search!

Most Common HTTP Errors

Errors are distinguished by their HTTP error codes; we can also specify a particular page to redirect to that is based on the HTTP error code that is raised.

The followings are some of the most common errors.

400: Bad Request - This means the request could not be understood by the server. The request was denied due to a syntax error in the request.

401: Unauthorized - This means the request requires authentication.

402: Payment required - This means the data is not accessible at the time. The owner of the space has not yet paid his or her service provider or the server was unable to serve the data that was requested.

403: Forbidden - This means the IP address or the username/password entered were not correct and the request was denied as there was no permission to access the data.

404: Not found - This means the document requested either no longer exists or has never existed on the server.

405: Method not allowed- Means the method you are using to access the document is not allowed.

408: Request Timeout - Means the server has closed the socket due to communications between the client and server taking too long.

414: The URL requested is too long.

500: Internal server error. The server encountered an error - This is most often caused by a scripting problem, a failed database access attempt, or similar reasons.

503: Service unavailable- This means the server is overloaded or down for maintenance and was unable to process the client request.

Can't find what you're looking for? Try Google Search!

Facade Design Pattern

Facade Design pattern provides an easy to use interface to an otherwise complicated collection of interfaces or subsystems. It makes things easier by hiding the details of the implementation.

When designing good programs, programmers usually attempt to avoid excess coupling between module/classes. Using this pattern helps to simplify much of the interfacing that makes large amounts of coupling complex to use and difficult to understand.

In a nutshell, this is accomplished by creating a small collection of classes that have a single class (Facade) that is used to access them.

The facade pattern is an object-oriented design pattern. A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can accomplish all of the following.

It can make a software library easier to use and understand since the facade has convenient methods for common tasks.
It makes code that uses the library more readable for the same reason.
It can reduce dependencies of outside code on the inner workings of a library since most code uses the facade. This allows for more flexibility in developing the system.
It can wrap a poorly designed collection of APIs with a single well-designed API.

Thus, Facade is a design pattern that hides the details and complexities of the lower-level software services for which it is written, making the service easier to use. In fact, the lower-level classes need not be classes at all; they can be an API in the form of a code library or a Web service.

A Facade also provides a unified entry point into the layers of the software. This reduces the application's dependency on the software service details and allows the Facade to hide future changes in the software service itself.

Can't find what you're looking for? Try Google Search!

eshwar's Web World

About Me

Favourite Links

Archives

Friday, September 15, 2006

PHP AJAX Frameworks

Javascript Remoting Frameworks

Show Progress Indicator Sample Example

Calculate propotion of task that's complete in AJAX Progress Indicator

AJAX Progress Indicator for server responses

Javascript Multipurpose Frameworks

On Demand Javascript Lazy loading

.NET AJAX Frameworks

Disadvantages or Downsides of AJAX

Characteristics of AJAX applications

Lifecycle of an AJAX application

Java AJAX Frameworks

Best Practices Using DateTime in .NET Framework

The Rules

Best Practice #1

Best Practice #2

Best Practice #3

Best Practice #4

Best Practice #5

Best Practice #6

Best Practice #7

Best Practice #8

Tuesday, September 12, 2006

Most Common HTTP Errors

Facade Design Pattern