timstall: javascript

Showing posts with label javascript. Show all posts

Sunday, December 21, 2008

Super Mario in JavaScript (no kidding)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/super_mario_in_javascript_no_kidding.htm]

I am impressed - someone has ported a trimmed-down Super Mario engine to JavaScript. Wow. I was impressed with Silverlight because it allowed 2D game development and let you avoid writing as much JavaScript. Just wow, got to give credit where credit is due.

http://www.nihilogic.dk/labs/javascript-games/

Wednesday, July 9, 2008

Persisting data in a web app by using frames

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/persisting_data_in_a_web_app_by_using_frames.htm]

A basic problem with developing web applications is that their foundation technology, html, is stateless. That means that you constantly need to jump through hoops in order to pass data from page1 to page2. Of course there are ways to solve this, such as using ASP.Net session state, querystrings, cookies, or persisting to a database. There is another way that may work for simple data if your app is hosted in a frame.

Say you have your main page, which is just a frameset. All the navigation occurs within that frameset, such that going from page1 to page2 merely updates the frame's url, it doesn't re-create the host page. This leaves the host page intact, including it's JavaScript state. Therefore, you could have a JavaScript variable persist data between pages.

<html>
<head>
    <title>My Apptitle>
    <script language="javascript" type="text/javascript">
      var _javaScriptVar = null;
    script>
head>
<frameset>
      <frame src="Page1.aspx" id="mainFrame">
frameset>
html>

You could then reference this variable from your child pages via the DOM:

window.parent._javaScriptVar = "someValue";

This means that page1 could set the value, and page2 could retrieve that value. To the end user, it looks like data has been persisted across pages. You could also expand this using JavaScript hashtables to store name-value pairs of data, and then add wrapper methods for an easy API. This is a surprisingly simple approach, and it has pros and cons:

Pro:

Very easy to implement for new apps
Scalable - as it stores data on the client, instead of on the server (like session state)
Can store strongly-typed data. This saves to a JavaScript variable, which can store complex data as opposed to just strings (although you could just use JSON to serialize most complex objects to a string and back)
It avoids cookies, which have their own limits and problems.

Con:

It messes up your URLs, as the user only sees the URL for the host page, not the child pages. (But this may be a good thing)
It is absolutely not secure, as any hacker could modify the JavaScript variables.
It does not persist across sessions - it's only good for convenience data on the UI.

Overall, it's a cute trick for certain apps. Although, I'd rather use Silverlight if I could.

Monday, April 21, 2008

JavaScript enums

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/javascript_enums.htm]

While JavaScript does not explicitly have the enum keyword, you can work around it using JS rich objects to get the functional equivalent. Here's a minimalist example that defines the enum, passes it in as a parameter, and then checks for it in a switch-case statement. Although, this doesn't throw a "compile time" exception if you pass in an invalid value.

Thanks to VS2008, you at least get JS intellisence on the "Enum_Colors" object, so that's better than just typing in error-prone literal strings.

Thursday, March 27, 2008

Fast cloning of dropdowns

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/fast_cloning_of_dropdowns.htm]

There are times that you'll want to dynamically add items to an html dropdown using JavaScript. It can be a huge performance gain, even with Ajax and update panels. You can easily do this like so:

      function DoStuff()
      {
        var selectbox = document.getElementById("Select1");
        addOption(selectbox, "AAA", "1");
        addOption(selectbox, "BBBBB", "2");
        addOption(selectbox, "CC", "3");

      }

      function addOption(selectbox, strText, strValue )
      {
        var optn2 = document.createElement("OPTION");
        optn2.text = strText;
        optn2.value = strValue;
        selectbox.options.add(optn2);    //This line is very slow
      }

The problem I wanted to solve was how to do this when adding 4000 items? It could take several seconds, and be very slow. (Yes, ideally a simple dropdown by definition doesn't have that many items, but let's say there are legacy constraints there, and the client wants a dropdown). For example, say you have a grid, each row has a dropdown, and that dropdown may be huge. A much faster way is to load only 1 dropdown, make it hidden (via JS on the client), and then clone it's nodes.

For example, have a hidden dropdown, which you populate from whatever server values:

<span id="Span1">span

And then, call this function to clone those values. It will clone the entire dropdown (sparing you from calling the very slow options.add method 4000 times), and then dump it in some nested container (like a span):

      function cloneDropdowns_fast(strSourceId, strContainerId)
      {
        o = document.getElementById(strSourceId).cloneNode(true);
        o.style.visibility = "";
        var container = document.getElementById(strContainerId);
        container.appendChild(o);
      }

      function PopulateDropdown()
      {
        cloneDropdowns_fast("Select2", "Span1");
      }

So, calling the method "PopulateDropdown" will copy the entire dropdown from "Select2", and dump a whole new dropdown in the "Span1" container. It works much faster (and appears to work in both IE and FF).

Friday, January 5, 2007

Free online JavaScript formatter

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/free_online_javascript_formatter.htm]

Sometimes you'll see JavaScript in what appears to be a garbled mess - no spaces, comments, or line breaks. This may be because JavaScript is transmitted over the wire, therefore it's faster performance to omit all those things that are unnecessary to the end user. However, they're great for the developer trying to read someone else's JavaScript. Hence, the need to format JavaScript.

There are several free formatters out there. Criteria I'm interested in is: (1) Accuracy, (2) Convenience - ideally an online tool as opposed to something I need to download, (3) Cost - ideally it'd be free, and (4) Length - I'd want it to be able to format large scripts, not just some 5 line demo.

There seems to be a lot to choose from: http://www.google.com/search?hl=en&q=JavaScript+formatter

Currently I'm looking at: http://www.jwmdev.tzo.com:8080/resources/js-tools/index.html

I'm also finding the NotePadd++ language feature helpful with this because it (1) color highlights JavaScript, and (2) match thes parenthesis and brackets for you (including nesting), making it very easy for you to format it yourself as you run through what the code actually does.

Sunday, October 15, 2006

'__pendingCallbacks[...].async' is null or not an object

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/__pendingcallbacksasync_is_null_or_not_an_object.htm]

I was doing so ASP.Net 2.0 callbacks (see an overview here: http://dotnet.sys-con.com/read/192509.htm), and kept getting this error when I did a document.location redirect on the ReceiveCallback JavaScript function.

Microsoft JScript runtime error: '__pendingCallbacks[...].async' is null or not an object

Looks like a flagrant Microsoft bug: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101974

People have different suggestions

What worked for me is the setTimeout. However, I needed to pass a parameter to the variable, so I used a technique like so:

var _gRValue;
function ReceiveCallback(rValue)
{
_gRValue = rValue;
window.setTimeout('__ReceiveCallback(_gRValue)',0);
}

function __ReceiveCallback(rValue)
{
//Do stuff here
} //end of method

To handle the nature of setTimeout, I stored the returned data in a member variable.

Tuesday, March 28, 2006

Viewing the source of an Html File, even with the ContextMenu disabled

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/viewing_the_source_of_an_html_file_even_with_the_contextmenu.htm]

In IE, you can view the source of any file through either the context menu or tool bar. However, sometimes there are design reasons to disable or hide these. For example, you can prevent the content menu by putting this in the a script in the HTML body:

document.oncontextmenu=new Function("return false");

And you can hide toolbars by opening up a new window and passing in the appropriate options:

window.open(...);

However, even if a site does this, you can still view the source through the VS.Net debugger. Simply start debugging one of your own apps, then navigate to the target site in the address bar, and you'll see full source in the Script Explorer window.

Sunday, March 26, 2006

ASP.Net 2.0 Callbacks: Using callbacks to create a rich Web UI

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/aspnet_20_callbacks_using_callbacks_to_create_a_rich_web_ui.htm]

I just had an article on ASP.Net 2.0 Callbacks published in .Net DJ. It provides a basic intro, and some more advanced uses like handling multiple callbacks and passing multiple data values.