Tag Archives: AJAX

Whoa

Traveling back to Amsterdam, with a short stop in Boston.

Today was one of those days where we had a customer going through the “whoa” experience again. This is a phenomena that typically occurs with customers who are still working with version 7 of Uniface (yes, they do exist), who think Uniface only has this old Windows 3.1 look and feel, are now suddenly shown a Uniface 9.5 AJAX front-end. And suddenly see for themselves how great looking a Uniface app can be…

Different reactions might follow, varying from utter disbelief through to “whoa, i gotta get me some of that…”. Which happened today again. Another customer migrating to 9 and continuing their mission critical development with Uniface.

Uniface in the Land of the Rising Sun (日本)

Those who know me will know I’ve always had an affinity with Japan. During my previous stint in product management it was my second home. So it’s always good to come back, catch up with old friends and customers, some of who I have known for over 15 years.

We had two user conferences this year, one in Osaka, serving the Kansai region of Japan, and one in Tokyo. We follow a slightly different program for the Japanese market, where we have a shorter program without the usual 9.6 workshops, which we are looking at doing as a separate event.

Japan is an interesting country from a business IT perspective (it’s an interesting country anyhow!). Despite being very technically advanced, it’s also a culture that is quite conservative when it comes to business technology and business apps. For example using old versions of Uniface connected to old versions of databases and we even have one customer who is still using a deployed application on Windows NT 4!

So I was really interested to hear the customer presentations at this years events, as one of them, NTT Data Business Brains (yes!) have built a Uniface  web  app (aka RIA or Web 2.0) and deployed it in the cloud. This was based on Uniface 9.4, which was the first RIA release, and in all honesty I would have expected that the work done in Uniface 9.5 to expand the functionality would have been necessary for them.

But the app is deployed and in use, and some of their end users are even using it with IE6, which bought them challenges, which they have worked around.

Talking to them afterwards, they are keen to take a look at 9.6, and the pagination functionality, as they said they ended up doing a fair amount of work with stored procedures to make sure they kept performance where they needed it to be. (I’m glad we’ve put the functionality into the product!).

During their presentation they had a couple of slides discussing security. They are bound by some corporate standards, which included the testing by a separate division within NTT, and tests both the application and also the deployment components. I couldn’t get details on what their criteria was for the testing, but I know that we had one issue in the web (wrd) layer, which we resolved (this was earlier this year).

We’ve actually done quite a lot in the area of web security, initially working on a project with Minnesota State, and resulted in us engaging an external company to regularly test our deployment bits and pieces. Maybe something for a future blog ramble.

 

Tab widget : PART I (UPDATED)

This little demo delivers an ajax driven tab widget controlled by a plain USP 🙂

a simple TAB-Widget with 100 lines of code

This little demo is contributed to all of you after it was presented at the CBG summit in Hagen september 2009.

The main purpose is to open your eyes and make you think about RIA and if it has to be rocket science or not! HTML is NOT
rocket science, but it seems there’s a lot of strange voodoo needed to maintain the DSPs presented in the RIA releases of
Uniface.

As I show you this code, I wan’t you to take a sharp look behind the Idea of Dynamic Server Pages! Understanding this
demonstration aswell as my previous posts will make the DSP component more and more obsolete 😉 … but well … you will have to figure this on your own.

 

“HUB MACHT SCHUB!” as Deniz says, but … what is this demo anyway?

My demo delivers a simple ajax driven tab widget controlled by a USP! HTML, CSS, JavaScript and Uniface
code will be less than 100(!) lines of code in the basic edition. It’s not EYECANDY but functional and effective. So feel
free to mix it to your personal flavour.

 

Ingredients

What we first of all need is a basic web page…

<html>
<head>
<title>USP instead!</title>
</head>
<body>
<h1>AJAX TAB Widget (AHP TECH DEMO)</h1>
</body>
</html>

Now it’s time to define, how wide we want the widget to be. As we are skilled and well known for good code, we don’t just put a size
on the HTML tags. So, we start here with a DIV tag, containing the widget. It will have the class “mytab”. With that done the DIV tag looks
like:

<div class=”mytab”> </div>

Why it has to use the named class will be explained a bit further down in this demo. At this moment take it as it is.

Next we need a some tabs. Tab are usually done by using the UNORDERED LIST widget (ul) while every tab is a LIST ITEM (li).
In order to click on the tabs and having space for some fanciness on that, we use the web anchor (a) to define, whats supposed
to happen, if a tab is clicked. Here we will add 3 tabs which will call a JavaScript code with a parameter delivered by the
tab.

<ul>
<li><a href=”javascript: ahp_load_tab(1);”>TAB 1</a></li>
<li><a href=”javascript: ahp_load_tab(2);”>TAB 2</a></li>
<li><a href=”javascript: ahp_load_tab(3);”>TAB 3</a></li>
</ul>

Okay, lets head on. In order to display something after we press the tab, we need an output container. Usually we use a DIV for that.

In this demo, we need to give it an ID so we can find that container again and put some data into it:

<div id=”inhalt”>
Inhalt von Tab
</div>

All this together makes a HTML code looking like:

<html>
<head>
<title>accept no imitations- … USP instead!</title>
</head>
<body>
<h1>AJAX TAB Widget (AHP TECH DEMO)</h1>
<div class=”mytab”>
<ul>
<li><a href=”javascript: ahp_load_tab(1);”>TAB 1</a></li>
<li><a href=”javascript: ahp_load_tab(2);”>TAB 2</a></li>
<li><a href=”javascript: ahp_load_tab(3);”>TAB 3</a></li>
</ul>
<div id=”inhalt”>
Inhalt von Tab
</div>
</div>
</body>
</html>

What’s next … ahh … yes, the JavaScript function with the AJAX voodoo 🙂 … it’s pretty obvious actually, but take a close look
at it though:

<script>
//###############################################################
function ahp_load_tab(xtab) {
//###############################################################// ### Benutzer über Aktivität informieren ###
document.getElementById(‘inhalt’).innerHTML = “wird geladen …”;

// ### Aufrufparameter bestimmen ###
var xURL = “http://localhost:8080/uniface/wrd/run/MYUSP.tab_”+xtab;
var http = null;

if (window.XMLHttpRequest) {
http = new XMLHttpRequest();
} else if (window.ActiveXObject) {
http = new ActiveXObject(“Microsoft.XMLHTTP”);
}

if (http != null) {
http.open(“GET”, xURL,true);

http.onreadystatechange = function () {
if (http.readyState == 4)
document.getElementById(‘inhalt’).innerHTML = http.responseText;
}

http.send(null);
}
}
</script>

Assuming you to be a developer should make you capable of scoping the functionality in this brief code. But still I will
pay you some explanation on it.

First we grab the HTML Tag with the ID called “inhalt” and fill it with the text “wird geladen …” (… for those of you not capable of the german language: this phrase tells the user, “it’s loading …”)
Done with that we assemble a string containing OUR SERVER PAGE ($componentname), a dot “.” which indicates an Uniface operation and the name of the operation.

We want to have three different tabs and as we are lazy we simply have 3 operations in our server page called tab_1, tab_2 and tab_3.

Looking at the HTML code we call the JavaScript with the params 1, 2 and 3. So our assembled string will represent the wanted operation.

DON’T come along now and blame me to be a retard just because I didn’t optimize the code to be one function…
ALLWAYS REMEMBER: it’s not  me who needs to learn how HTML, AJAX and those things work out together! At this very moment, it’s you 😉

But let’s get back on track. We assembled the string to be fitting to our server page. Now we need the AJAX object to get it up’n running.

Since we work browser independant ( YES, WE DO …! this one will even do on an iPhone @ CPWR ^^ ) we have to figure what browser
is used at the very moment. In general we can choose from two groups:
The standard obeying ones and Microsoft!

That’s exactly how the code goes here. After the first lines, we have an instance of the XMLHTTP object in our variable “http”.
With that we request the String in xURL (e.g. our assembled string with the server page) with the method GET and define the request to
be async! Finally we send it and hope for a reply 😉

Hopefully the reply comes some 20-40ms after the request. Because, if it does, the response on our request will be taken to the container
defined by the id “inhalt”. So far for JavaScript at this very moment.

 

CSS

Now we should take care of the presentation of our widget: Let’s shape it a bit, so it looks like a tab widget. We hereby grab the CSS
definitions for our widget and put it into the listing:

<style type=”text/css”>
#inhalt {
border: 1px dotted #303030;
clear: left;
width: 500px;
padding: 5px;
}
.mytab ul {
margin: 0;
padding: 0;
border: 1px solid transparent; /* FIX: ONLY FOR IE, ELSE OBSOLETE! */
}
.mytab ul li {
display: inline-block;
width: 100px;
padding: 0;
padding-right: 3px;
margin: 0;
list-style: none;
float: left;
}
.mytab li a {
border: 1px solid #101010;
border-bottom: none;
text-decoration: none;
display: block;
padding-left: 5px;
background-color: #aaaaff;
color: #eee;
height: 22px;
line-height: 22px;
}
.mytab li a:hover {
background-color: blue;
color: #FFF;
}
</style>

Place the CSS block within the HEAD tag (e.g. somewhere between <head> and </head>). Save it!
Then we are done here!

Heading over to Uniface for the final things to do.

We will make a USP and delete the following crap:

-GetState Trigger
-SetState Trigger
-Exec Trigger
-Everything else … it’s simply obsolete 😉

Now create a dummy entity and kill those triggers, because without that we won’t be able to compile it 😉 …

Switch over to the operations and insert following code:

;###################################################################
operation tab_1
;###################################################################
$webinfo(“OUTPUT”) = “This is TAB 1”
end
;###################################################################
operation tab_2
;###################################################################
$webinfo(“OUTPUT”) = “You clicked TAB 2”
end
;###################################################################
operation tab_3
;###################################################################
$webinfo(“OUTPUT”) = “TAB 3, Sir, it’s TAB 3!”
end

After having done this, try to compile it! … since this ain’t rocket science, it surely will do!

Starting the widget

Launch your Tomcat (WRD), and Try out the HTML page. Aslong all this resides on your pc, it should work. Be aware of
that some browsers (in this test Google Chrome and Mozilla Firefox refused) deny to AJAX a url not placed in the actual “domain”.
Since this is the cheap and dirty version of the widget, try to take Apple Safari or Internet Explorer. They apparently don’t care about
XSS (Cross site scripting) and do whatever they’re told! 😉

If it works for you in this point of development, then let’s conclude, what we have done now:

We made a HTML page ourselves with Stylesheets, JavaScript and some little tags. Furthermore we made 3(!) redundant operations in
Uniface to handle the AJAX requests from that little HTML code!

THIS IS IN TOTALLY 98 lines of code … 🙂 … pretty nice, eh? … well you could try to do this in a DSP, but erhmmm … don’t get
confused by the generated code hehehe!

Background information on : XSS / “Error: uncaught exception: Permission denied to call method XMLHttpRequest.open”

If you want to do cross-domain scripting with XMLHttpRequest, e.g. fetching data from a remote location but you’re on a
local page or local XUL application (file:///), you need to tell Mozilla/Firefox about that, otherwise you get this infamous error 😉
This is called cross site scripting or just XSS. Often abused in the internet to show ads, load malware or doing other stupid things.

This could explain why Mozilla and Google build in some security in their browsers- … thanx guys! 😉

But of course there is a way around that. At this moment im not aware of how to switch the behavios with Chrome (… ok, u got me- i didn’t google it!)
so i will show you the fix for Firefox:

try {
netscape.security.PrivilegeManager.enablePrivilege(“UniversalBrowserRead”);
} catch (e) {
alert(“Permission UniversalBrowserRead denied.”);
}

Add this in front of the code in the JavaScript function and Firefox will obey 😉

So this is it!

And that’s the end of my little demo. Hope you enjoyed the trip so far and didn’t get frustrated by doing HTML, JavaScript, CSS,
AJAX, Uniface and a little XSS! 😉 … My apologize for the missing CODE INDENTATION, but adding a source in here is a real pain in the … erhmm … stomach 😉

This demo was successfully tested on Uniface 9.4 CR before release and YOU have officially been GHANified!
Tell me, how you liked it and if it worked for you. Questions, suggests and critics are welcome aswell 😉

Straight from the department of digital propaganda and with kind regards,

-GHAN-

HINT: find the updated article on http://www.udev.info/uniface/a-simple-tabwidget-with-100-lines-of-code/

PART 03: What is AJAX?!

In PART03 we will take a look at, how to combine the things from PART01 and PART02.

PART 03: What is AJAX?!

Welcome to the third part of my HOW-TO. It’s nice to have you back in front of my text and see your eyes run from right to left while I use my coffee breaks to write all this for you, hehe.

In this part I will take a focus on AJAX. We will find out

  • what it is
  • how we can use it and
  • start a first attempt on the voodoo behind RIA

So, what is AJAX anyway?

It stands for Asynchronous JavaScript And XML and is nothing new invented. Mostly it is a set of techniques enabling us to get data from somewhere into the current HMTL Page. All of it is written in JavaScript and has been available since the launch of Microsoft Internet Explorer 4.0.

The inventer of the name “AJAX” is surely unknown but the name became popular after Jesse James Garrett published and used it in his document “Ajax: A New Approach to Web Applications” in February 2005. To finish the historical background I would like to say that AJAX is the key to WEB2.0!

More footage on this is found on Wikipedia.com

 

Time to reveal what it looks like.  I took the HTML code from PART 01 an put some Javascript on it.

<html> 
<head> 
  <title>AJAX</title> 
</head> 
<body> 
Hello, earthlings … this is UNIFACE taking over your web browser!   

<div id='xcontent'>   Here goes my content </div> 
<span onclick="do_ajax()">click me!</span>   

<script type="text/javascript">    
// ### do you remember what THIS does? ###
   document.getElementById('xcontent').innerHTML = 'do as is do!';

// #############################################################
function do_ajax() {
// #############################################################
    var http = null;

    if (window.XMLHttpRequest) {
       http = new XMLHttpRequest();
    } else if (window.ActiveXObject) {
       http = new ActiveXObject("Microsoft.XMLHTTP");
    }
    if (http != null) {
       http.open("GET", "MY_URL_FROM_SOMEWHERE", true);
       http.onreadystatechange = show_the_result;
       http.send(null);
    }
}
// #############################################################
function show_the_result () {
// #############################################################
   if (http.readyState == 4) {
      document.getElementById("xcontent").innerHTML =
         http.responseText;
   }
}
</script>
</body>
</html>

You are not supposed to understand all this at this point 🙂  This code shows the HTML from part 01 where we figured how to manipulate the content of tags via JavaScript.

The line with the “innerHTML” puts the string “do as I do!” into content of the <div> tag. Somewhere below there is a line called “function do_ajax()“. When called it GETs us data from the address “MY_URL_FROM_SOMEHWERE” (e.g. this could be your Uniface server page) and puts its output to the <div> tag. If all this is a bit blurry at the moment don’t hesitate 🙂 It’s ok!

But now you know what AJAX looks like 😉

I want you to take this code into your editor. Search and replace the following:

MY_URL_FROM_SOMEWHERE => Path and name to your server page of PART 02 (I called it MYUSP: e.g. “MYUSP.hello_entity”)

Afterwards save it and load it into your favorite browser. Try to click on the text “click me!

If everything worked out, you should see the contents of the entity in your HTML page.

Caveats and a fast check list:

    • Did your browser complain about “JAVASCRIPT” ERRORS when it opened the page?
    • Is uRouter up and running?
    • Is it possible to call the server page by hand (like in PART 02)?
    • If the assignment file is told to produce a putmess log, what does it say?

 

I will assume it to work! And my first task is then to tell you:

CONGRATULATIONS“! You just did your first AJAX WEB2.0 RIA UNIFACE server page by yourself 🙂 Go get the Champaign … awesome!

You should start to play around with your server page and the calling HTML. Make your mind and try out some things! Play and learn how it behaves. To make it a bit easier, I will tweak up the “do_ajax()” thing for you.

Change the function called “do_ajax()” and “show_the_result()”  to the following:

// #############################################################
function do_ajax(vURL,vTARGET_ID) {
// #############################################################
    var http = null;

    if (window.XMLHttpRequest) {
      http = new XMLHttpRequest();
    } else if (window.ActiveXObject) {
      http = new ActiveXObject("Microsoft.XMLHTTP");
    }

    if (http != null) {
      http.open("GET", vURL, true);
      http.onreadystatechange = function() {show_the_result(vTARGET_ID)}; 
      http.send(null); 
    }
}
// #############################################################
function show_the_result (vTARGET_ID) {
// #############################################################
   if (http.readyState == 4) {
      document.getElementById("vTARGET_ID").innerHTML = http.responseText;
   }
}

Having done so lets you easy do different calls on different urls. The function now requires TWO parameters and for our page this would look like:

Onclick=”do_ajax(‘MYUSP.hello_entity’,’xcontent’)

The function “do_ajax” needs to know what has to be done.  We hereby tell it to GET MYUSP.hello_entity and PUT the result in to the tag with the id “xcontent” (in our page a <div> tag). Although this looks good, it’s still far from being perfect!  But NOW you can interact with Uniface in a dynamic way and retrieve data by choice.
All this is basically what happens within a DSP (ok, let me be precise: DSP works with AJAX). The DSP produces a HTML code which then generates AJAX calls to the DSP. The DSP answers and feeds the browser.

HERE we now (can) do the same while we still are in control of what happens (when)!

Conclusion on PART 03
AJAX is a word invented in 2005 describing techniques based upon an JavaScript object called XMLHttp(Request).  It looks a bit weird although it’s not (…says who?).
Using AJAX and the stuff learned in the previous parts puts us in the situation to take control on dynamic server pages with regular Uniface versions. This lets us reinvent the common USP and catch up to what will be introduced as Uniface dynamic server page.As we learned in Part 01 this has some disadvantages (less triggers) but still it opens up a whole bunch of new options including to have control of what happens in the server page.

Please let me know, if you find some errors 🙂

 

EDIT:

2009-03-10 : Fixed the JavaScript issue according to the discription of Discooctopus and some nasty mispelled words 😉

HINT: find the updated article on http://www.udev.info

PART 02: Getting Uniface involved

This is the second part of my HOW-TO. It refers to the first part and describes, how a USP works.

PART 02:  Getting Uniface involved

Calling Uniface is an easy one. Basically we just put the address of the server page into the browser and wait for a response. At this point I don’t know how the server pages were meant to be (ab)used but when you are out there and do the web development, then your code is capable of doing more than ONE THING at the same time.

As you might know, we can activate component operations in order to reuse the given code. Actually this also works within the USP 🙂

Let’s  say we have the server page “myusp”. Calling it in the browser makes us see some html (or whatever it should show). Now we append another operation called “hello_browser”. Using a normal activate would make it look like:

Activate “MYUSP”.hello_browser

… right? But we don’t activate while using a browser. So to get that operation to run, we amend the address of the server page to “myusp.hello_browser”. Try to make an operation with the following code:

———8<—————————–

Operation hello_browser

$webinfo(“OUTPUT”) = “<html><head><title>Hello browser</title></head><body>This is the operation HELLO_BROWSER serving you!</body></html>”

end

———8<—————————–

Now take a look at the SetState trigger. If there is a WEBGEN then just remove  or move it to the execute trigger.

Press [CTRL]+[F7] (… compile) and check for errors. If everything seems fine, call is in your browser.

First call the server page in the normal way. It should show the HTML code from the painted screen. Then change the address to “myusp.hello_browser”.

If this works for you, then you took the first step into a better server page.

 

Familiar with HTML or not?!

At this point you will have to decide for yourself if this is an option for you or just CRAP! It demands you to have knowledge in building HTML code. Failing here should let you hit the brakes and say “ok, I gave it a try!” But if it feels not that tricky, then just head on- there is much more to explore.

 

Since you read this line, I assume you want more- fine … let’s go deeper then 😉

Putting it straight: Code should be/is capable of more than one function.

Compuware bound us to let a server page have only one display functionality. This is because you must draw the layout of the server page in the component editor and have no option of doing more than one layout.  Paint it, compile it- finished.  Unluckily this didn’t feed my needs so I started to live without it.

In the previous part of this how-to I introduced a method to do so. I didn’t mention, why this will do, so I better get it done now.

How the USP works

The server page consists of three main things to do its job: WEBGET, WEBGEN and $webinfo(“output”). (Don’t nail me for not mentioning header and input stuff as well as the other interesting buffers)

WEBGET takes care of all parameters that comes in from the web (CGI – common gateway interface … or just say web interface). Filling out fields in the browser puts the value back in your component fields. This voodoo is done by the webget statement in Uniface which also fires the triggers here and there. The idea of this is nice but doesn’t work with more than one layout and neither will it fill out our own fields and containers.

WEBGEN is the second part of this paint-and-be-happy construct. It takes the HTML from the painted fields and supplies it with the necessary Javascript code in order get this thing running. Fields are filled out and the complete code is put in the main buffer.

$WEBINFO(“output”) is the (mentioned main) buffer that is transferred to the web. Everything in this buffer will reach the browser. It doesn’t care about syntax, integrity or other stuff- it’s just the output buffer.

So, what do we need to get going? Only the $WEBINFO(“OUTPUT”). The rest is obsolete! (… yes, forget about this! You won’t need it) Doing so will save time and money 🙂

Instead of bugging around with the layout, just get used to store HTML layouts in external files or even the db (database). Then just load it, put it into $webinfo(“output”) and that’s all. No layout will be disrupted, scratched or lost! Uniface will have no hands on that any longer.

Next let’s have a look at the triggers. Uniface is definitely about triggers. We only want to look at the surface of that and skip all those triggers fired when using WEBGET (we don’t want to use it, remember?).

The normal path through the server page looks like:

  • GetState
  • Execute
  • SetState

 

The path is changed as we call an operation:

  • GetState
  • Operation
  • SetState

Anything else is to be invoked by your code (e.g. retrieve -> read trigger). Please be aware of that no field triggers will be fired due to no WEBGET! This also impacts the format triggers and other stuff like that. But that’s not as nasty as it sounds.

While working with data, we will need some entities for two reasons:

  • To be able to compile (*doh*)
  • To work with dynamic data in the entities

Let’s declare an entity in the painting. Switch to the SOURCE tab below and enter the following:

———8<—————————–

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<html xmlns=”http://www.w3.org/1999/xhtml”>

<head>

</head>

<body>

<x-entity name=”myentity.model”></x-entity>

</body>

</html>

———8<—————————–

Change the “myentity.model” to your desired entity and return to the component editor. Hit the refresh button in the bottom and suddenly your entity will appear. Make sure to modify its properties to ALL fields like in a service. This gives access to all possible fields and won’t cause any headaches like “yak, I forgot to declare the field!”.

 

Now you can work with the entity as you like. Be aware of that from now on, you are STATELESS- there is no hitlist any longer! No strings attached, no hidden catch- you are stateless! Retrieved data will be brought to you. If your retrieve profile results a 10.000 occs, then you get 10.000 occs  🙂

Let’s try it out! We will take your entity and let the contents of some fields pass through to your browser. Declare another operation in the previously started server page and let it look like:

———8<—————————–

Operation hello_entity

Variables

String vhtmlcode

Endvariables

;### Start the html header ###

Vhtmlcode = “<html><head><title>Hello entity</title></head><body>”

Clear/e “myentity”

Retrieve/e “myentity”

Setocc “myentity”,1

;### amend a row per occ ###

While ($status > 0)

  Vhtmlcode = $concat(vhtmlcode,field.myentity,”<br />”)

 Setocc “myentity”,$curocc(myentity”) +1

Endwhile

 

;### finish the html code ###

Vhtmlcode = $concat(vhtmlcode, “</body></html>”)

 

;### feed the browser ###

$webinfo(“OUTPUT”) = Vhtmlcode

end

———8<—————————–

Finished with that? Fine! Hit [CTRL]+[F7] and RESTART your uRouter service! Since Uniface is a kind software, it buffers the loaded components from the last request (… that’s why I call it the BUFFERHOG, hehe!) After having done that, reload the server page in your browser and try out the new operation.

A few words  about the browser

The browser is your client in this game! It will get your html code and try to do the job for you.  Be sure to do some well formed html code which applies to the standards! Doing so will let you forget about special code for browser x which won’t work on browser y. Do it once and let it fit to the standard.

There are a bunch of fine browsers out there to aim at. Personally I group them into categories. Those may be “The good ones” and “the rest”. Let me mention the group members for you:

The goods ones, who work fine and obey given standards, are:

  • Mozilla (all sorts, all platforms)
  • Webkit based (Safari, chrome, Konqueror and again : all platforms)
  • Opera

The rest at the moment just holds one name: Microsoft Internet Explorer!

  • v5.x is scaring my pants off
  • v6.x is creepy as hell (widgets are rendered in a strange way, fatally insecure)
  • v7.x is at a level where you can say “ok …!” (but still insecure)
  • v8 (not released yet) will not be a 100% but do better than the previous ones

 Hear my advice: Take your HANDS OF IE6 and below!  They will tear you apart if your project gets complex!

Personally I use Mozilla Firefox 3.x with the Firebug extension. To test my work with IE I use the “IE TAB” extension.  Jason (Huggings) mentioned that there is a nice debugging tool for IE user as well. This works exactly like Firebug and is called “IE developer toolbar” available for download at Microsoft (or just put it to Google). Which browser you may choose is up to yourself!

Finally I must mention that there are a lot of further browsers out there. These claim to be the fastest, easiest and smartest because they can do “everything” and combine the features of the major browsers. Just skip those! They won’t help you at all. Here comes some reason:

1)      Debugging is not, what they are best at! They will only let you surf!

2)      Companies won’t use this! (They mostly use IE, then Firefox and perhaps Opera)

3)      Try to Google any errata concerning those browsers! There’s not much to be found!

 

Conclusion on PART 02

Congrats, you made it to the end of PART 02! Try to fool around with the server page and see, how things behave with that! We learned how a server page works and how to expand the capabilities of it (U7(!), U8, U9). Further we figured how to use entities and talked about browsers obeying standards while others don’t give a damn 😉

HINT: find the updated article on http://www.udev.info