TechiX

When not to Ajaxify...?

For most web applications, it doesn't make any sense to use Javascript for everything or even anything.
Ajax only really clearly helps in a limited set of circumstances; the web already worked pretty well before Ajax and there are a lot of pitfalls and drawbacks to using Ajax in web development.

A straight html weblog works just fine without being generated dynamically on the client with a stream of asynchronous messages from the server. Plain old HTML also works great for documents, or navigating between documents. Simple or rarely used applications can get along fine without putting in a bunch of Javascript.

Here are some places Ajax shouldn't be used:

· Simple forms.
Even though forms are the single biggest beneficiary of Ajaxification, a simple comment form, or submit order form, or other one-off rarely used form does not benefit from Ajax driven submission. Generally, if a form is not used much, or it's critical to work properly, Ajax is not that helpful.

· Search.
LiveSearch on blogs is more annoying than useful. There's a reason that Google Suggest is staying in beta and not going on the front page of Google. Searching on Start.com Live.com doesn't allow use of the back button to see a previous search, or previous pages. Maybe it's possible that no one has gotten this right yet, but getting this right is hard enough that it's generally not a good idea, or more trouble that it's worth.

· Basic navigation.
In general, driving basic site/application navigation using Ajax is an awful idea. Why would anyone want to spend time writing code to emulate the browser behavior when they could spend time making their application better? For basic navigating between documents, Javascript doesn't help.

· Replacing a large amount of text
Ajax saves a complete refresh of the page, so small pieces of the page can be more dynamically updated. But if nearly everything on a page is changing, why not just request a new page from the server?

· Display manipulation.
Even though it seems that Ajax is purely a UI technology, it's not. It's actually a data synchronization, manipulation and transfer technology. For maintainable and clean web applications, it's a good idea not to have Ajax/Javascript manipulate the interface directly at all. Javascript can stay separate and simply manipulate the XHTML/HTML DOM, with CSS rules dictating how the UI displays that data.

· Useless widgets.
Sliders, drag and drops, bouncies, mouse gestures, whatever. Mostly these widgets can be replaced with more intuitive controls, or eliminated altogether in favor of simplicity. In picking colors, maybe a slider widget is useful to pick the exact shade. But in picking a price point in a store, a slider to pick the price to the cent is just overkill.

posted by Swetha Iyer @ 12:54 AM 0 comments

Really wanna use Ajax..?

It's been well over a year now since GMail changed the way everyone thought about web apps. It's now officially annoying to use web apps that haven't replaced clunky html functionality with peppy Ajax goodness.

Here are places Ajax should now be required in a web application:

· Form driven interaction.
Forms are slow. Very slow. Editing a tag on a del.icio.us bookmark? Click on the edit link to load the edit bookmark form page, then edit the field and hit submit to wait for the submission to go through, then return to the previous page and scroll down to find the bookmark to see if the tags look right. Ajax? Click on the edit link to instantly start changing tags, click on the submit button to asynchronously send off changes to the tags and quickly see in place what changed, no reloading the entire page.

· Deep hierarchical tree navigation.
First of all, applications with deep hierarchical tree navigation are generally a nightmare. Simple flat topologies and search/tagging works very well in most circumstances. But if an application really calls for it, use Javascript to manage the topology ui, and Ajax to lessen the burden on the server by lazy loading deep hierarchy data. For example: it's way too time consuming to read discussion threads by clicking through and loading completely new pages to see a one line response.

· Rapid user-to-user communication.
In a message posting application that creates immediate discussions between people, what really sucks is forcing the user to refresh the page over and over to see a reply. Replies should be instant, users shouldn't have to obsessively refresh. Even Gmail, which improves on the old hotmail/yahoo mail 'refresh inbox, refresh inbox' symptom, doesn't really push Ajax far enough yet in terms of notifying new mail instantly.

· Voting, Yes/No boxes, Ratings submissions.
It's really too bad there are no consistent UI cues for Ajax submission, because submitting a vote or a yes/no response is so much less painful when the submission is handled through Ajax. By reducing the time and impact of clicking on things, Ajax applications become a lot more interactive - if it takes a 40 seconds to register a vote, most people would probably pass unless they really care. If it takes 1 second to vote, a much larger percentage of people are likely to vote. (I have 2008 movie ratings on Netflix versus 210 ratings on IMDb.com).

· Filtering and involved data manipulation.
Applying a filter, sorting by date, sorting by date and name, toggling on and off filters, etc. Any highly interactive data manipulation should really be done in Javascript instead of through a series of server requests. Finding and manipulating a lot of data is hard enough without waiting 30 seconds between each change in views, Ajax can really speed this up.

· Commonly entered text hints/autocompletion.
Entering the same text phrases or predictable text phrases is something software/javascript can be good at helping out with. It's very useful in del.icio.us and GMail, for quickly adding tags/email addresses.

For heavy use applications such as a webmail client or a blogreader, users have the luxury of time to learn new UI concepts, and the frustration of interacting with a slow interface. This kind of application is a perfect opportunity to leverage Ajax everywhere. The more frequently users use an application, the more Ajax should be powering that use.

posted by Swetha Iyer @ 12:46 AM 0 comments

XSL Whitespaces...

Remember the piece of code you put in at the head of an XSL to preserve white spaces.? Well it does preserve whites if you have any midway, say in your variables or parameters passed.
But what if you wanted to add a white space, in the output HTML you are generating. The same job done by a or a VbCrLf...?
Sad for beginners like us, pampered by the abundance of such variables in most languages, XSL is devoid of one.

Has a work around though...(God bless..!)
Let us say you wanted to print:
Hoodibaba, 888, BabyMamon..in the same line...

Getting the basics done with...

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>

<xsl:param name = "firstString" select = "Hoodibaba">
<xsl:param name = "secondString" select = "888">
<xsl:param name = "thirdString" select = "BabyMamon">

<xsl:template match="/">

<html>
<body>
<b>I am going to print 3 strings!</b>

Now if you just selected the value of these 3 parameters and printed, say like this...

<b><xsl:value-of select = "$firstString"/></b><xsl:value-of select = "$secondString"/><xsl:value-of select = "$thirdString"/>

..your output would be something like this...

Hoodibaba888BabyMamon

Not exactly lookable right..?
Thats where the idea of white spaces comes in..

We use the <xsl:text> functionality for the same.
<xsl:text> basically adds any additional text into your template that is not covered by other features.


So rewriting the above statements as....

<b><xsl:value-of select = "$firstString"/></b><xsl:text> </xsl:text><xsl:value-of select = "$secondString"/><xsl:text> </xsl:text><xsl:value-of select = "$thirdString"/>

Would give something more liek what we want....

Hoodibaba 888 BabyMamon

It preserves white spaces, remember..?
So you could also imitate the carriage return this way...

<b><xsl:value-of select = "$firstString"/></b><xsl:text>
</xsl:text><xsl:value-of select = "$secondString"/><xsl:text>
</xsl:text><xsl:value-of select = "$thirdString"/>

Would make our output look like this...

Hoodibaba
888
BabyMamon

Problems solved..eh..?

Learnings:
1....uhmmm...its the best language to work on when you like to use every single command to its fullest, what if for a mere job like a WhiteSpace..!

posted by Swetha Iyer @ 11:51 PM 0 comments

Loop with XSL..

The kind of language that XSL is, with nothing written straight forward and a real nightmare for once having a first glance, it has no option for looping..There is the option...Quite contrary to what it actually sounds, it has nothing to do with the for loops of other programming languages. It merely runs through each repition of a node and performs the actions.
Searching around in the net for this was no joke either, for very few got me where i wanted. And finally i got one link that seemed god sent..posted just for me..!

Posting the code here:

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>

<xsl:template match="/">

<html>
<head><title>Say Hello Ten Times!</title></head>
<body>
<b>I am going to say hello Ten Times!</b>
<!-- begin_: Call the loop function -->
<xsl:call-template name="loop">
<xsl:with-param name="i">1</xsl:with-param>
<xsl:with-param name="count">10</xsl:with-param>
</xsl:call-template>
</body>
</html>

</xsl:template>


<!--begin_: Define_The_Output_Loop -->
<xsl:template name="loop">

<xsl:param name="i" />
<xsl:param name="count" />

<!--output to be printed for every loop-->
<xsl:if test="$i <= $count">
<br /><b><xsl:value-of select="$i" />.</b>Hello World
</xsl:if>

<!--Repeat The Loop Until Finished-->
<xsl:if test="$i <= $count">
<xsl:call-template name="loop">
<xsl:with-param name="i">
<xsl:value-of select="$i + 1"/>
</xsl:with-param>
<xsl:with-param name="count">
<xsl:value-of select="$count"/>
</xsl:with-param>
</xsl:call-template>
</xsl:if>

</xsl:template>
</xsl:stylesheet>



------------------------------------------------------------------------
learnings from this venture:

1. This is a huge workaround for a simple operation done by a for loop. Wonder why w3c dint come up with something simpler for it.
2. No new template can be defined within another. So make the call in place, and define the template elsewhere.
3. It doesnt matter whether u define the template before or after the call for template.
4. Templates rock.!

posted by Swetha Iyer @ 9:12 AM 0 comments

JAVASCRIPT weirdity...

Ran into an interesting problem while I was using javascript today. I had a dynamically generated group of checkboxes that I wanted to be able to check and uncheck as a group. Was using the checkboxes to denote the emails to be deleted from the list.

Came up with the code given below after much researching from our good old web.


function fnMoveMail()
{
for(i=0;i<document.frmWorkAreaTop.chkDelMail.length;i++)
{
if(document.frmWorkAreaTop.chkDelMail[i].checked==false)
(document.frmWorkAreaTop.chkDelMail[i].checked==true;}
}}"

Was calling it from a link that was something like this :
<a href="javascript:fnMoveMail()">

Things were all well and good, as long as the field that is passed into the function is an array of checkboxes. However, since javascript is a "typeless" language, you can call any method on an object, and depending on how egregarious the error is, the user might never see an error message. In this case, when the dynamically generated group of checkboxes has only one element, document.frmWorkAreaTop.chkDelMail is not an array of checkboxes, and its length attribute doesn't return anything. The for loop is not executed at all, and the box is never checked.

The solution is simple enough, just check the type of object passed in:
if(document.frmWorkAreaTop.chkDelMail.type != 'checkbox')
{
for(i=0;i<document.frmWorkAreaTop.chkDelMail.length;i++)
{
if(document.frmWorkAreaTop.chkDelMail[i].checked==true)
{lChkBxCnt = lChkBxCnt + document.frmWorkAreaTop.chkDelMail[i].value + ",";}
}//end of for
lChkBxCnt = lChkBxCnt.substring(0,lChkBxCnt.length-1);
}//end of if(document.frmWorkAreaTop.chkDelMail.type != 'checkbox')
else
{lChkBxCnt = lChkBxCnt + document.frmWorkAreaTop.chkDelMail.value;}

It makes little sense why one checkbox wouldn't be an array of size 1, but the switch caught me a bit off guard.
Unfortunately, a quick google did not turn anything up for me about the logic.

posted by Swetha Iyer @ 2:14 AM 0 comments