Archive

Archive for August, 2009

Race Conditions within Ajax

August 30th, 2009 Comments off

What is a race condition? A race condition is a flaw in a system or process whereby the output and/or result of the process is unexpectedly and critically dependent on the sequence or timing of other events. (Wikipedia on Race Conditions.).

So far, so good.

How does race conditions appear using Ajax?
It happens when two or more operations are started, and the result of these operations needs to be displayed AFTER all operations has been finished.

For example: You want to display the different types of information like price, weight, dimensions of a car. For each of these information, you use an Ajax operation (It is no question, that this problem can be also solved in other ways). Now…you want that these information are displayed AFTER all figures has been determined.

But where is the problem? Have a look at the following code:

function determineFigure()
{
   var serialNo = "XK8LBV42".
   getPrice(serialNo);
   getLength(serialNo);
   getWidth(serialNo);
   getHeight(serialNo);
   displayFigures();
}

function getPrice(serialNo)
{
  ... Ajax Operation ...
}

function getLength(serialNo)
{
  ... Ajax Operation ...
}

function getWidth(serialNo)
{
  ... Ajax Operation ...
}

function getWeight(serialNo)
{
   ... Ajax Operation ...
}

function displayFigures()
{
   ... Display operation
}

The problem is that the “displayFigures()” will be called before all the figures has been determined. How come? Each Ajax request has to be transmitted, processed
and the result has to be sent back to the client. This all takes time; and definitely more time to invoke the methods mentioned above!than invoking the four methods.

So how can we solve this problem? I would like to introduce here two options: “Chaining” and “Counting”

Option 1: Chaining

Each Ajax request has a so called “Callback Method”. See code below!

function getPrice(serialNo)
{
    $.ajax(
              {
                type: "POST", // Set the Post Method
                url: "/keyFigureController.php, // Set the target url
                data: "serialNo=" + serialNo + "&type=price", // set the parameters
                success: function(msg)
                {
                  getLength(serialNo);
                },
                error: function(msg)
                {
                }
   });
}

These methods are called in case of an successful (“success”) or errorneous (“error”) outcome of the request. So, what you can do here, is to write in each success method the next method until every figure is determined and the information can be displayed.

Option 2: Counting

Another way is to count the number of completed requests.

function getPrice(serialNo)
{
    incrementTotalRequestCounter();

    $.ajax(
             {
               type: "POST", // Set the Post Method
               url: "/keyFigureController.php, // Set the target url
               data: "serialNo=" + serialNo + "&type=price", // set the parameters
               success: function(msg)
               {
                  incrementProcessedRequestCounters();
                  addNumberToTable();
                  checkCounter();
              },
              error: function(msg)
             {
             }
           }
      );
}

function checkCounter()
{
   incrementProcessedCounter();
   if(getTotalRequestCounter == getProcessedCounter())
  {
    showDialog();
  }
}

vTiger CRM 5.0.4 umlaut display issue

August 25th, 2009 Comments off

The freely available CRM software vTiger (version 5.0.4) still has issues with the display of UTF-8 and ISO-8859-1x characters (German umlauts like äöü and ß).

When you open an EMail in the Webmailer module, the text following such a character is completely gone – the rendering engine of vTiger simply stops the rendering of all characters starting from here.

After many reading in the internet and in the relevant forums and trying out several proposals for fixing this issue, one simple change did the trick:

Open ../modules/Webmails/Webmails.php and scroll down to the function declaration load_mail() – in our sources, this is located around line 712.

712
713
714
715
function load_mail($attach_tab)
{
    // parse the message
    $ref_contenu_message =  @imap_headerinfo($this->mbox, $this->mailid);

Right after the “parse…” comment add the following line

716
    global $default_charset;

Now the beginning of the function looks as follows:

712
713
714
715
716
717
function load_mail($attach_tab)
{
    // parse the message
    // HK 25.08.2009 fix for umlaut display problem - added the following line
    global $default_charset;
    $ref_contenu_message =  @imap_headerinfo($this->mbox, $this->mailid);

This solved the issue for us.

After upgrading to the new version 5.1.0, we will have to see whether the developers of this really outstanding piece of software have provided a common fix for all of those Hungarians, Germans and other poor special-character-users like us :-)

Categories: General Tags: , ,

Browser-Kompatibilität testen

August 6th, 2009 1 comment

Wer heute als Entwickler Frontends für Webanwendungen erstellt, muss sich früher oder später damit auseinander setzen auf welchen Browsern die Anwendung später läuft oder laufen muss. Üblicherweise nutzt der Webentwickler in seiner Entwicklungsumgebung immer die neuste Version eines flexiblen Browsers, der mit vielen unterstützenden Plugins versehen ist, möglichst alle aktuellen Standards beherrscht und fehlertolerant ist. Leider spiegelt das aber in den wenigsten Fällen die Situation beim Kunden bzw. Benutzer wieder.

Im besten Fall stellt der Kunde die Anforderung, dass lediglich der im Unternehmen eingesetzte Standardbrowser genutzt wird. Im schlimmsten Fall soll die Anwendung auf “allen gängigen Browsern” funktionieren.

Spätestens jetzt steht der Entwickler vor einem Problem und muss sich folgende Fragen stellen:

  • Welche sind die “gängigsten” Browser?
  • Wie kann ich die Webseite auf diesen Browsern testen?
  • Wie kann ich die Webseite so optimieren, dass sie auf möglichst allen Browsern funktioniert?

Browser am Markt

Eine Übersicht vieler bekannter und weniger bekannter Browser findet man recht schnell in Wikipedia. Doch alleine nützt diese Übersicht natürlich wenig. Das ausschlaggebende Kriterium welchen Browser man derzeit als “gängig” betrachtet ist natürlich dessen Verbreitung bzw. Marktanteil. Auch hier gibt es aussagekräftige Statistiken, die in regelmäßigen Abständen die reale Verbreitung der unterschiedlichen Browser anzeigen.

Anhand der Marktanteile sieht man sehr deutlich, dass sicherlich viele aktuelle Browser wie IE7, IE8 und Firefox 3.5 den Markt beherrschen, aber auch z.B. der IE6 noch eine nicht zu unterschätzende Verbreitung genießt. Ebenfalls Browser wie Opera, Safari und Google Chrome spielen in der Top-Liste der Browser zum jetzigen Zeitpunkt eine Rolle. Wenn man von “gängigen Browsern” spricht, kommt man an den genannten also nicht vorbei.

Browser testen

Um also zu testen ob die Webanwendung auf allen “gängigen Browsern” funktioniert und möglichst auch identisch aussieht, muss man sich etwas einfallen lassen.

Bedenken sollte man dabei, dass eine 100% Kompatibilität mit allen Browsern nahezu unmöglich ist. Man muss also aus wirtschaftlicher Sicht genau abwägen wie das Kosten/Nutzen-Verhältnis ist und wie viel Prozent Kompatibilität man erreichen möchte.

Eine einfache und oftmals ausreichende Möglichkeit ist, jeden ausgewählten Test-Browser parallel zum Entwicklungsbrowser zu installieren und bereits während der Entwicklung stetig die Ausgabe der anderen Browser zu kontrollieren und ggf. gleich nachzusteuern. Installationen von Opera, Google Chrome und Safari für Windows lassen sich in der Tat einfach parallel installieren. Problematisch wird es aber mit dem Internet Explorer. Da dieser tief im Kern von Windows verwurzelt ist, lassen sich unterschiedliche Versionen nicht einfach so parallel installieren. Googelt man ein wenig nach diesem Problem, bekommt man haufenweise Tipps und so genannte “Sandbox-” oder “Standalone-Browser” angeboten. Aber Vorsicht: Nicht alle angebotenen Lösungen sind empfehlenswert und können gar den vorinstallierten Browser zerstören. Die aktuell beste Lösung und zweifelsfrei zu empfehlen ist der IETester, welcher auch unter Windows Vista und Windows 7 lauffähig ist. Das rund 25MB große Programmpaket installiert den IETester, in welchem beliebige Browser-Tabs mit unterschiedlichen IE-Versionen geöffnet werden können. Dabei werden mit dem IE5.5 bis IE8 alle nötigen und sinnvollen Versionen abgedeckt.

Sollen darüber hinaus noch weitere Browser auf anderen Betriebssystemen getestet werden, bietet das Internet auch hier eine Lösung die allerdings nicht ganz so flexibel ist. Auf der Webseite browsershots.org wird nach Angabe der URL die eigene Webseite in allen denkbaren Browservarianten gerendert und das Ergebnis als Screenshot präsentiert. Die eigentliche Funktionalität der Webseite kann damit allerdings nicht getestet werden.

Auch wenn man mit diesen Tools und Tricks die Kompatibilität der meisten Browser meist ausreichend gut testen kann, lohnt es sich doch immer die Seite auch auf einem “realen” System zu testen. Wer die Möglichkeit hat oder schaffen kann einen Rechner mit MacOS oder Linux, bzw. (virtuelle) Rechner mit unterschiedlichen Windows- und Browser-Versionen zu nutzen, sollte dies aus Sicht der Qualitätssicherung tun.

Webseiten für Browser optimieren

Da jeder Browser eine Webseite bestehend aus HTML, CSS und JavaScript auf unterschiedliche Art und Weisen oder gar fehlerhaft rendert und interpretiert, und dabei gesetzte Standards mehr oder weniger einhält oder ergänzt, muss der Frontend-Entwickler erhebliche Anstrengungen unternehmen den eigenen Code so anzupassen, dass er tatsächlich auf allen Browsern gleich funktioniert und aussieht. Der steigende Anteil an JavaScript (Ajax) und die Einführung von CSS3 machen das nicht unbedingt einfacher, auch wenn die Browserhersteller mehr denn je versuchen Standards einzuhalten. (vergl. ACID-Test)

Als Frontend-Entwickler ist man fast schon gezwungen Standards zu umgehen und fehlerhaften Code zu erzeugen, um die Kompatibilität herzustellen.

Weitere Informationen zu diesem umfassenden Thema findet man im Internet mit der Suche nach u.A. diesen Stichwörtern: DOCTYPE, CSS-Hack, Browserweiche, Box-Modell.

Eine weitere Möglichkeit Webseiten im Sinne der Browser-Kompatibilität zu optimieren ist das Nutzen von Frameworks. Gerade im Bereich JavaScript haben sich in jüngster Vergangenheit etliche Frameworks entwickelt, die von Seiten derer Entwickler auf eine hohe Browser- und Plattformunabhängigkeit optimiert wurden. Beim Einsatz dieser Frameworks muss der Frontend-Entwickler sich also darüber kaum noch selbst Gedanken machen.

Auch andere Web-Frameworks für die unterschiedlichsten Bereiche und Programmiersprachen bringen meist ihre eigenen Lösungen mit, so dass der Frontend-Entwickler sich auf seine eigentliche Aufgabe konzentrieren kann und bei seiner Arbeit deutlich entlastet wird.

Categories: Java, PHP Tags: , , ,

JEE 6 – Was ist drin?

August 5th, 2009 Comments off

Die Java EE Spezifikation in der Version 6 befindet sich noch immer im Review:
JSR 316.

Wer die neuen Features jedoch vorab schon einmal testen möchte, der kann diese mit dem Glassfish Enterprise Server Preview bereits genauer ansehen.

Es wird jedoch darauf hingewiesen, dass diese Implementierung auf dem aktuellen Entwurf der Spezifikation basieren und Änderungen daher nicht ausgeschlossen sind.

 Was genau enthalten ist, fasst SUN auf der Übersicht Java EE 6 Standards zusammen.

Categories: Java Tags: ,