By the way I plan to release different formats of sardalya for different uses.

1. sardalyaFull: The full library including experimental modules such as Editor.
2. sardalyaEvent: Just the event-attachment related part
3. sardalyaAJAX: Event attachment plus XmlHttpRequest wrappers.
4. sardalyaDrag: Specially crafted for drag and drop operations.
5. sardalyaMenu: User-interface widgets such as DropDownMenu, CollapsibleLayer.
6. sardalyaDynamic: Some bits and pieces added to sardalyaEvent to get and set various css properties, get window dimensions, track cursor coordinates.
7. some other variations may be.

Plus I need to find a convenient means of updating all those releases automagically.
I may write a C# application for it to make life easier on my side.

 bu yaziyi sevdin mi?  hemen una ekle!

A very good javascript verifier written in javascript

http://www.jslint.com/

Altough its rules are a bit strict for me (it cries if you do not put { before a return for instance) it will be really useful when developing stuff in teams. Since the world is shifting to a fat-client ajaxian paradigm applications like this are ultimately useful.

I will use it to reformat sardalya. Because in a few months time, I'm going to find myself collaborating with a couple of developers utilizing sardalya to create a fat-client ajax app.
And then, robustness of the script will be more important than its compactness.

I may add a similar logic to orkinos (giving apropriate credits of course),
Because, imho, the application may work faster when compiled into an executable.
Though it is not one of my high-priority to-do items.

Thanks Douglas for sharing this invaluable code piece with the rest of the world.

 bu yaziyi sevdin mi?  hemen una ekle!

After my post on thelist I have received several off-list questions asking

What would you recommend, instead of disabling form's default submit behavior,
so that only the submit button will submit the form?

in one way or in another.

Although, I am sure Christian has much more to say I have a few words to say anyway.

So what can you do to disable form auto-submitting when pressing enter on a form field.
Actually nothing other than the solution I've proposed apriori (using onsubmit="return false;" in the form tag).

Here is why I do not recommend it:

Submitting form on pressing enter on an input field is the default behavior and it is useful in terms of accessibility. By adding onsubmit="return false;"

1. You override the behavior which is an accessibility disaster (that's why I do not recommend it).
2. You cannot be 100% sure (user may disable javascript or simply type javascript:document.forms[0].submit(); on the addressbar, both of which will submit the form, regardless of which control you put in the form, none the less)
   

Javascript is to enhance functionality, it is not to create functionality, nor can it be used to impose "so called" security controls to your web application.

Any kind of javascript security control can be easily bypassed by

1. Either disabling javascript
2. or using javascript: pseudoprotocol on the addressbar and calling your js function directly (as in javascript:document.forms[0].submit();
3. or using a developer toolbar and injecting your own js into the code (mozilla is excellent on this)
4. or writing a low-level application which gets and posts http requests and never messes with javascript at all.
   

These are what come to my mind immediately.

I am sure there are dozens of other ways around and hundreds of readily cooked hacker tools
to make these possible even to the novice to alter the http request with a few button clicks.

So what is the the ideal way of doing it?

I hear you say "Come and do it yourself then, I have deadlines and I am feeling my client's / boss' breath on the nape of my neck".

You're right from a certain point of view: It will help you save a day or two, at a cost of never-ending future nightmares.

If you think this won't affect you at all ("bana bişey olmaz abi") then do not spare your precious time and read the rest of this post -- just enjoy your way to the dark side :)

So coming back to my former question, "what is the ideal way of doing it?":

Actually it's dead obvious and simple:

1. First of all, disable your Javascript

As I mentioned above Javascript should be used to enhance functionality,
not to implement it.

Thus the first and immediate thing you should do is to disable javascript, post your form and
validate everything on server.

If server-side validation fails, redirect the user to the same page with a message explaining what has gone wrong.

(Hell No!!! when I say message, I never for ever mean, a Javascript alert or worse a pop-up,
embed your message directly into the page and preferably highlight the erroneous fields with css)

2. After making sure that everthing works """without""" JavaScript, enable JavaScript
and implement whatever client-side control you wish to do.

This may seem duplicating your development time but it can save you hours on the long run.

Of course, if you like having stomachaches once a week because you cannot wonder how on earth that bloody user entered those god-damn invalid data into the form, then that's your choice.

I don't know you, but I have better things to do like eating, sleeping...

 bu yaziyi sevdin mi?  hemen una ekle!

If you write ajax applications and your pages are encoded in a non-UTF character set,
you will most probably find yourself in need of a conversion mechanism so that the data you send to server is encoded properly without damaging native characters.

Recently, I've been in a similar situation and I've written two methods (one server-side, one client-side) to sort out the issue.

Although my solution only covers Turkish character set (iso8859-9) it may be generalized to suit your needs.

XMLHttpRequest uses UTF-8 encoding to send data to the server.

You should normally use javascript's escape function to convert the data you wish to send to something server does not confuse.

As you may know, Escaping a string replaces special charaters such as space, ampersand (&), percent (%) to their UTF equivalents so that it will not damage the format of the QueryString when post to the server.

Under normal circumstances, escaping the data before sending it to the server is enough to encode it. However in our special case (where we are using a non-utf charset -iso-8859-9- along with native characters) it is not enough. We need to convert the native Turkish characters to their UTF equivalents as well.

Here is how to do it:

function iso88599Escape(strText)
{

strText=escape(strText);
strText=strText.replace(/ı/g,"%C4%B1");
strText=strText.replace(/Ü/g,"%C3%9C");
strText=strText.replace(/ü/g,"%C3%BC");
strText=strText.replace(/ğ/g,"%C4%9F");
strText=strText.replace(/Ğ/g,"%C49E%");
strText=strText.replace(/ü/g,"%C3%BC");
strText=strText.replace(/Ü/g,"%C3%9C");
strText=strText.replace(/İ/g,"%C4%B0");
strText=strText.replace(/ş/g,"%C5%9F");
strText=strText.replace(/Ş/g,"%C5%9E");
strText=strText.replace(/ç/g,"%C3%A7");
strText=strText.replace(/Ç/g,"%C3%87");
strText=strText.replace(/ö/g,"%C3%B6");
strText=strText.replace(/Ö/g,"%C3%96");
return strText;
}

Though there is another caveat here:
We are sending the data in the QueryString to the server in UTF format.
However the server is configured to interpret the data it received as if it were an
8 bit iso8859-9 encoded string. When it comes to native characters, this encoding differs from unicode.

So we need another conversion method on the server to convert the UTF data it received so that it becomes a properly encoded iso8859-9 string.

A quick and dirty solution would be a brute-force replacement of misinterpreted character sequences:

public static string AjaxRequestToIso88599(string value)
{
return value.Replace("Ãœ","Ü"
).Replace("Åz","Ş"
).Replace("Äz","Ğ"
).Replace("Ç","Ç"
).Replace("Ä°","İ"
).Replace("Ö","Ö"
).Replace("ü","ü"
).Replace("ÅŸ","ş"
).Replace("ÄŸ","ğ"
).Replace("ç","ç"
).Replace("ı","ı"
).Replace("ö","ö");
}

I hear you say "There should be a better way to do it.
And yes, you are right.

Let us go one by one:

UTF data as byte array(ajax request)
-> [server (Request.QueryString)]
-> ISO-8859-9 encoded String

The data posted to the server (i.e. the querystring we just formed) is in UTF-8 format.
Although server interprets it as if it were an Latin formatted stream (namely a stream with iso-8859-9 charset). This creates those cryptic characters.



So we need to convert the String into what it once were: a UTF String!

To do it, we first get the original byte array by decoding the incorrectly encoded String back to its bytes.
And then encode those bytes using UTF.

public static string Iso88599ToUTF8(string value)
{
return Encoding.GetEncoding("UTF-8").GetString(
Encoding.GetEncoding("ISO-8859-9").GetBytes(value)
);
}

Easy cheesy!
One line of code and your String is properly converted.

afiyet olsun!

Other References

1. Special Turkish Alphabet Characters
2. Jeppe's unicode page
3. UTF8 Transformation chart
4. JSPWiki UTF8 Issues
5. Another UTF conversion table

 bu yaziyi sevdin mi?  hemen una ekle!

In this post we will try to demonstrate the scope generation of closures step by step with illustrations.

Although the issue is important, it is generally misunderstood or misinterpreted.

I will try to be as clear and as simple as possible.
I'm open to any suggestions to enhance this post further.

---

Let us begin with a test case:

exhibit 1: source code of the test case.

Sorry, I cannot copy paste the source directly. 'cuz blogger reformats it.

Let us go line by line:

- We call test() method on window load (line 32).

- In lines 4, 5 and 7 we create three variances namely fnRef, j and i.



The scene looks like something like that. I've intentionally left too much whitespace on the image as we will need it later.

- Then at line 9 inside the for loop we create a closure at each iteration. That makes a total of three closures.



Note that fnRef stores a reference to the last closure created.

All those three closures close over the three variances that have been created a priori (i, j and fnRef).



The blue dashed line denotes the scope created by any of those closures.

- Each closure defines its variances as well:



Note that the local variance j (red one)
inside the closure overrides the global variance j (orange one).

- Then a brand new closure is spawned inside the closure at line 16:



which makes three more closures. Note that each local fnRef2 refers to one closure.

And here is the final picture:




The red line shows the scope generated for the innermost closures. As seen they can see both local variances inside the first closure (j and fnRef2) and the variances that closure sees (i, j and fnRef).

That's all for now.
Hope that was useful.

 bu yaziyi sevdin mi?  hemen una ekle!

s@rdalya recently got an A grade.

More to read on here and here.

 bu yaziyi sevdin mi?  hemen una ekle!

I've recently added some details and use-cases about sardalya's EventHandler object, things that may not have taken your attention at a first glance.

 bu yaziyi sevdin mi?  hemen una ekle!