Don't Mention the (Browser) War
I found this great but deleted article in the goolge cach, I know I have no right to publish it. But I claim knoledge is public.
Michael Jackson owns zero Beatle song, he didn't write the music, he has no right to exploit it. The artists made the music for the people not for exploitation.
If I write and sing a song some other person should earn royalties for not letting peole listen to my music? MY SONG? FUCK HIM!
I am sure Elvis, Bobmarley, Jimmy hendrix and mr mercury. All agree with me. So what is this law of yours based on and what is there to gain from this for the public. Thats who the singing was done for in the fist place.
So I ow you an apology Eddy, I didn't ask you if I could publish your brainwave. I just refuse to see how you one could own a set of bytes. Please don't let this post upset you, I will delete it if you want.
Don't Mention the (Browser) War
SAP Developer Network
By Eddy De Clercq
11 Jan 2005
Introduction
I sometimes feel nostalgic about the first war - browser war, that is. It began in mid-1995, lasting about one and a half years (not long indeed - but more on that later).
Netscape Communications and Microsoft were the competitors in the arena playing for market share. Netscape was the better player for a long time. That was mostly due to the fact that they came with new features and set standards like frames, Java, JavaScript, plug-ins, etc. Microsoft was always trying to catch up and instead of following the standards, made its own. Despite the fact that MIE was cheaper (it was free, Netscape wasn't), Netscape had an 80% market share in it glory days.
The war also had playful twists. Who doesn't remember hearing about the giant Mozilla (Netscape's mascot, after the Japanese cult movie dragon monster Godzilla and before it became a product) was placed at the entrance to the Microsoft building with a scoreboard indicating "1-0." The day after, a big "E" was placed at the Netscape entrance. Or was it vice versa? It doesn't really matter. There was also the Netscape employee of the month parody. Netscape employees spent a lot of time at their offices, claiming them to be more their homes than their real homes. So they were allowed to bring their pets to work. These pets were employees of the month, had their own websites with diaries, etc.
Then came the beginning of the end. Not immediately, but in 1997, you could tell that something was happening: The focus wasn't the browser anymore, but the web (application) servers. This was the subject at the first (and last) European DevCon in Paris. The Marc Andreessen I've shaken hands with wasn't the mean-and-lean whiz kid I knew from the myths, but a well-nourished business man in a three-piece suit.
In January 1998 came the news that the Netscape browser would be free, open source, and would be revamped into the Mozilla project. In November '98, Netscape Communications was sold to AOL for about 8.9 billion dollars (then, a high value). For several years I kept a video with a documentary on the early days of Mozilla that more or less explained that Mozilla was one of the key conditions of AOL's purchase.
Then it quickly spiralled downward. The next releases of Netscape were slow and buggy; the final 1.0 version of Mozilla took four years to actually get delivered. MIE took over market share – and that was the end.
Why the nostalgia? During those pioneering times, life as a web developer was fairly easy, despite the fact that during the boom months some kind of release was launched every fortnight. One had only three questions that had to be answered. Will the user follow? - Can we use the new functionality? - What will Microsoft do - will it follow, or try to create its own standard? We had to use our common sense and try not to jump on every new gadget that appeared to have a site that worked well on every browser. There were other players too. The best example is Opera, a project that was started at Telenor as an intranet browser back in 1994. But it was not always as fast, slick, and powerful as it is nowadays. It also became a kind of cult browser, the inner crowd just using it because it was an alternative to the other two big players. Strangely enough, we never saw Opera in our browser stats even if we (tried to) make our sites compatible.
Crossing Platforms
One would think that developing a site is much easier nowadays since MIE has/had (since Brower War II is predicted after the launch of Firefox, with Blake Ross as the new whiz kid to fear) the highest market share. Nothing could be less true. At the university, we need to support as many different browsers as possible on as many different platforms as possible. In contrast with other companies we don't impose any browser or platform. This academic freedom creates many challenges for us web developers and this isn't at all easy sometimes.
In fact, not a lot of commercial software is capable of doing this. There is, for example, the case for some software we were testing (the name doesn't really matter in this example). According to the specs, it should run on a certain browser version, but it obviously didn't. We reported this to the company, and after a long silence their reaction was not to fix the problems to get it to run properly; instead they changed their specifications and skipped out this version of the browser.
It isn't at all easy to find a browser that runs on and acts the same on all platforms. Some examples:
[MIE]
MIE runs (reasonably) well on Win32, doesn't have any plain Linux version, and the Mac version is stopped for further development. PocketPC is another story. I have this six month-old PocketPC with MIE on it that doesn't even show Microsoft sites properly. Our hope was that the new Windows release would be a step forward, but the manufacturer of this PDA decided to only offer this new version on their new PDAs, and not to provide any upgrade for "old" PocketPCs. In other words, I can throw my rather expensive mobile device in the garbage if I want to see sites on my PocketPC properly with MIE.
[Mozilla]
Mozilla then. At first it looks good: the binaries run on Win 32, different flavors of Linux, and Macintosh. But there are some clouds in the sky. We had some serious problems with it- but more on that later. Then there are all these different products: Mozilla, Firefox (was Firebird), Camino, Thunderbird, and the upcoming Sunbird. It's hard to tell the end user what the purpose of all these products are and which one is the best for them to use. Also, there is a lack of PocketPC and other non-desktop platforms.
[Opera]
Why not Opera? Indeed, it supports Windows, Mac, Linux, FreeBSD, Solaris, OS/2, QNX, but also less obvious platforms like Symbian (mobile phone), Home Media, and even cars. One big missing link is again PocketPC.
[Platform-Specific]
There are a lot of platform-specific browser types like Safari, Konqueror, and Netfront to name but a few. They try to cover certain niches, which is good from their perspective - but harder for us to support.
If this wasn't enough it's difficult to detect which browser somebody is using for consulting your site. The first method is to test the string a browser is sending to your server, but that is far from accurate. Some manufacturers fake a certain string – it's rather easy to do it on your own - for some strange, unfathomable reason. At first glance it might look like a good idea, but they harm themselves in their so-called browser stats annex market share. What use is it to fake a certain type of browser, if your browser isn't compatible with the one you pretend to be? But this string gives certain problems even if the browser string is for real - but more on that later.
Another method is the classic test:
script language="JavaScript">
if (document.document.images)
//the browser is NS 3+, IE 4+
if (!document.document.images)
//the browser is NS 2, IE 3
if (document.document.layers)
//the browser is NS 4
if (document.document.all)
// the browser is IE 4+
if (document.getElementById)
//the browser is IE5+ or NS6+
if (document.getElementById && !document.all)
//the browser is NS6+
This somewhat unreadable code is not error-proof either. It sometimes gives the strangest results, not to name MIE on PocketPC as an example. Web crawlers also seem to dislike this code.
W-Y-S-I-N-A-W-Y-G (What You See Is Not Always What You Get)
A couple of years ago we were searching for a method to let professors and others edit their syllabi via a web interface. We wanted to make sure that non-HTML gurus would be able to do this in a consistent way according to the house style. We needed to prevent blinking pink letters or obsolete HTML code generated by some HTML editors that were then pasted into our editor. And of course the main requirement was that it had to run on as many browsers/platforms as possible. We soon discovered that the latter was the major problem as we searched around to see what was available. Nearly everything was solely MIE-minded, with not even the slightest concern about other browser or even platforms. The following describes part of our journey and the pitfalls encountered along the way.
The Flashy Way
After a while we decided not to concentrate on the browser differences anymore and started looking for external solutions. The most obvious choice was Macromedia Flash. At that time Macromedia had just released the Developers Resource Kit Volume 2 (http://www.macromedia.com/macromedia/proom/pr/2002/drk2_announce.html), which contained the Flash UI Component Set 4. This component set included a rich text editor that was a perfect start for our solution. Of course it wasn't an off-the-shelf, ready-to-go-product, so we needed to do some extra work. Briefly put, this came down to:
a) The editor needed to be adapted to our needs.
b) The editor needed to retrieve data from SAP and store it again after editing. Some heavy communication between Flash, JavaScript, and SAP needed to be implemented in order to achieve this. The content could be relative, so it couldn't be put as parameter for the swf. So the Flash editor needed to retrieve the data itself. This is a tutorial on Flash that I can refer you to if you want to know more: http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_15683
c) On the SAP side, you needed to retrieve the data and 'serve' it to the editor.
Step 1: Create a BSP page.
Step 2: Put all the code for retrieving the data in the OnInitialization event handler.
Step 3: Put all the data in one string
Step 4: Make sure that the mime type is set correctly, and deal with special characters in order to let the editor understand them.
call method runtime->server->response->set_header_field
EXPORTING
name = 'content-type'
value = 'application/x-www-urlform-encoded'.
class cl_http_utility definition load.
Final_content = cl_http_utility=>escape_url( unescaped = original_content ).
Step 5: Put the content in the layout.
<%@page language="abap"%>
&content=<%=content.%>
d) When deploying the whole thing, make sure that you users have (the correct version of) a Flash Player installed. This might be somewhat tricky. Users aren't always allowed to install software on their own because it may be managed centrally via Tivoli for example, or for other reasons. So even if you explicitly specify in the codebase of your flash object that the browser will install the Flash Player automatically, don't rely on this fact.
The CSS Way
Suddenly clouds appeared, covering the sun up completely. The so-desired cross-platform feature didn't work at all anymore, after more than a year of running smoothly. We hadn't changed anything in the code and suddenly the editor didn't work anymore on Mozilla for Mac OS X and Linux (in our example RH 8). It was a total mystery to us.
The true reason was discovered after some extensive interchanging of information with Mozilla. The reason was that Flash was compiled with GCC 2.X and Mozilla (starting from a certain version) with 3.2. According to Mozilla there were "ABI incompatibilities" between the two GCC versions, which means that it doesn't work anymore. "Downgrading" Mozilla and compiling with the lower GCC was impossible due to incompatibilities with other Java plug-ins and for other reasons. We couldn't ask our users to compile their Mozilla by themselves with the correct GCC in order to make the editor work again. The only option seemed to be to wait for Macromedia to launch a GCC 3.2 compiled version. In fact, that wasn't really an option at all since we didn't know when that would be, and Macromedia didn't reply at all to our questions concerning this matter.
So we were back to where we started, but with multiple (future) applications requiring this editor. Luckily for us, computer science is ever-evolving. It didn't take us as much time as we thought to find an alternative. We found it in "Through-The-Web (TTW) Editor." [http://www.koivi.com/WYSIWYG-Editor/] This neat editor - called TTW - is first of all cross browser/platform. It didn't support all that we wanted, but was a start and better than a single browser/platform solution. Rome wasn't built in a day either, so there will be a day that we or someone else can provide the missing support in the future.
Also, it fell under the GNU Lesser General Public License (LGPL). Of course, it wasn't an off-the-shelf product, but took less effort to implement. We needed to adapt the editor to our needs, but we didn't have to build communication between the editor and SAP because it could be put directly in the BSP page. Strictly speaking, the editor comes down to some HTML and Javascript, and as such is a piece of cake for implementing in a BSP page.
The clouds vanished again, until a couple of months ago. It didn't work anymore for Mozilla on Debian Linux. To be more precise - it didn't recognize this browser as legit. What happened? The TTW editor uses the browser detection mechanism devised by Chris Nott (http://www.dithered.com/javascript/browser_detect/index.html), which falls under a Creative Commons License. This mechanism is based on the browser string that I already talked about before. It seemed that the length of the browser string was longer for Debian than for the others. We had to adjust this before because the browser detect didn't know what Camino was and recognized Firefox only by its old name (Firebird).
As previously said, detetecting via the browser string can be somewhat tedious and a neverending story. I once printed this list of ID strings on a printer capable of printing on both sides of paper, 2 pages on a side, making a booklet in small print and the result was > 50 pages: http://www.zytrax.com/tech/web/browser_ids.htm (please do read the more interesting "Browser Rants" at the end of the document).
My suggestion would be to download the latest version of browser detect and modify wherever applicable according to your needs and specifications of TTW.
The SAP Way
I hear you thinking that I'm always searching/giving solutions outside SAP. That's not exactly the case. We tried hard to find a solution from within SAP. We didn't find any. That is until December 15th 2004 when reading Thomas Jung's excellent weblog, Using the BTF Editor. Honestly, I was stunned. How couldn't we find this, and think that BTF only stood for the Behavioral Task Force, Beyond the Frame, the Buffalo Teacher Federation, or even Behind The Flag of Sheffield FC (to name a few) - and not the Business Text Framework, which came available in WAS 6.20. So I immediately started the BTF_EXT_DEMO and had a look at it. It looked really nice, but when we tested it in e.g. Firefox it didn't show things as expected. We have just upgraded to WAS 6.4 but Firefox unfortunately gave the same incorrect result.
The Ultimate Solution?
SAP has also been thinking about this cross browser/platform problem and looking for a solution to it. Their result is called Web Dynpro. These sentences from Service Marketplace say it all: "Web Dynpro is based on a powerful and flexible Model-View-Controller architecture that ensures a clear separation of user interfaces and backend services…. Design as much as possible and program as little as necessary: Higher productivity through declarative approach to modelling, instead of programming, layout, screen usage, navigation, and data binding."
Isn't that great? No more concerns about browsers and platforms; Web Dynpro will do all the thinking for you. The PAM – dd. December 30th 2004 published at https://service.sap.com/nw04 – of SAP NetWeaver starting with SP Stack 11 shows only a limited amount of supported browsers/platform under certain conditions. The new browser war may cause a new speed injection for new functionality, perhaps resulting in a whole new type of browser and the way we surf the Internet. Will SAP and Web Dynpro be able to catch up in/each time?
Secondly, will Web Dynpro support all the things we/you need in a site? I know it's impossible to cover it all and fulfill all our wishes. The future will tell what magical things Web Dynpro can do for us. For now, it already looks great and promising.
The Author
Eddy De Clercq has 20 years experience in computing. Currently he works at the Katholieke Universiteit Leuven (Belgium), the oldest university of the Low Countries and the largest Flemish university. Eddy makes up part of the E-university team which creates mostly self services (web) applications.
Michael Jackson owns zero Beatle song, he didn't write the music, he has no right to exploit it. The artists made the music for the people not for exploitation.
If I write and sing a song some other person should earn royalties for not letting peole listen to my music? MY SONG? FUCK HIM!
I am sure Elvis, Bobmarley, Jimmy hendrix and mr mercury. All agree with me. So what is this law of yours based on and what is there to gain from this for the public. Thats who the singing was done for in the fist place.
So I ow you an apology Eddy, I didn't ask you if I could publish your brainwave. I just refuse to see how you one could own a set of bytes. Please don't let this post upset you, I will delete it if you want.
Don't Mention the (Browser) War
SAP Developer Network
By Eddy De Clercq
11 Jan 2005
Introduction
I sometimes feel nostalgic about the first war - browser war, that is. It began in mid-1995, lasting about one and a half years (not long indeed - but more on that later).
Netscape Communications and Microsoft were the competitors in the arena playing for market share. Netscape was the better player for a long time. That was mostly due to the fact that they came with new features and set standards like frames, Java, JavaScript, plug-ins, etc. Microsoft was always trying to catch up and instead of following the standards, made its own. Despite the fact that MIE was cheaper (it was free, Netscape wasn't), Netscape had an 80% market share in it glory days.
The war also had playful twists. Who doesn't remember hearing about the giant Mozilla (Netscape's mascot, after the Japanese cult movie dragon monster Godzilla and before it became a product) was placed at the entrance to the Microsoft building with a scoreboard indicating "1-0." The day after, a big "E" was placed at the Netscape entrance. Or was it vice versa? It doesn't really matter. There was also the Netscape employee of the month parody. Netscape employees spent a lot of time at their offices, claiming them to be more their homes than their real homes. So they were allowed to bring their pets to work. These pets were employees of the month, had their own websites with diaries, etc.
Then came the beginning of the end. Not immediately, but in 1997, you could tell that something was happening: The focus wasn't the browser anymore, but the web (application) servers. This was the subject at the first (and last) European DevCon in Paris. The Marc Andreessen I've shaken hands with wasn't the mean-and-lean whiz kid I knew from the myths, but a well-nourished business man in a three-piece suit.
In January 1998 came the news that the Netscape browser would be free, open source, and would be revamped into the Mozilla project. In November '98, Netscape Communications was sold to AOL for about 8.9 billion dollars (then, a high value). For several years I kept a video with a documentary on the early days of Mozilla that more or less explained that Mozilla was one of the key conditions of AOL's purchase.
Then it quickly spiralled downward. The next releases of Netscape were slow and buggy; the final 1.0 version of Mozilla took four years to actually get delivered. MIE took over market share – and that was the end.
Why the nostalgia? During those pioneering times, life as a web developer was fairly easy, despite the fact that during the boom months some kind of release was launched every fortnight. One had only three questions that had to be answered. Will the user follow? - Can we use the new functionality? - What will Microsoft do - will it follow, or try to create its own standard? We had to use our common sense and try not to jump on every new gadget that appeared to have a site that worked well on every browser. There were other players too. The best example is Opera, a project that was started at Telenor as an intranet browser back in 1994. But it was not always as fast, slick, and powerful as it is nowadays. It also became a kind of cult browser, the inner crowd just using it because it was an alternative to the other two big players. Strangely enough, we never saw Opera in our browser stats even if we (tried to) make our sites compatible.
Crossing Platforms
One would think that developing a site is much easier nowadays since MIE has/had (since Brower War II is predicted after the launch of Firefox, with Blake Ross as the new whiz kid to fear) the highest market share. Nothing could be less true. At the university, we need to support as many different browsers as possible on as many different platforms as possible. In contrast with other companies we don't impose any browser or platform. This academic freedom creates many challenges for us web developers and this isn't at all easy sometimes.
In fact, not a lot of commercial software is capable of doing this. There is, for example, the case for some software we were testing (the name doesn't really matter in this example). According to the specs, it should run on a certain browser version, but it obviously didn't. We reported this to the company, and after a long silence their reaction was not to fix the problems to get it to run properly; instead they changed their specifications and skipped out this version of the browser.
It isn't at all easy to find a browser that runs on and acts the same on all platforms. Some examples:
[MIE]
MIE runs (reasonably) well on Win32, doesn't have any plain Linux version, and the Mac version is stopped for further development. PocketPC is another story. I have this six month-old PocketPC with MIE on it that doesn't even show Microsoft sites properly. Our hope was that the new Windows release would be a step forward, but the manufacturer of this PDA decided to only offer this new version on their new PDAs, and not to provide any upgrade for "old" PocketPCs. In other words, I can throw my rather expensive mobile device in the garbage if I want to see sites on my PocketPC properly with MIE.
[Mozilla]
Mozilla then. At first it looks good: the binaries run on Win 32, different flavors of Linux, and Macintosh. But there are some clouds in the sky. We had some serious problems with it- but more on that later. Then there are all these different products: Mozilla, Firefox (was Firebird), Camino, Thunderbird, and the upcoming Sunbird. It's hard to tell the end user what the purpose of all these products are and which one is the best for them to use. Also, there is a lack of PocketPC and other non-desktop platforms.
[Opera]
Why not Opera? Indeed, it supports Windows, Mac, Linux, FreeBSD, Solaris, OS/2, QNX, but also less obvious platforms like Symbian (mobile phone), Home Media, and even cars. One big missing link is again PocketPC.
[Platform-Specific]
There are a lot of platform-specific browser types like Safari, Konqueror, and Netfront to name but a few. They try to cover certain niches, which is good from their perspective - but harder for us to support.
If this wasn't enough it's difficult to detect which browser somebody is using for consulting your site. The first method is to test the string a browser is sending to your server, but that is far from accurate. Some manufacturers fake a certain string – it's rather easy to do it on your own - for some strange, unfathomable reason. At first glance it might look like a good idea, but they harm themselves in their so-called browser stats annex market share. What use is it to fake a certain type of browser, if your browser isn't compatible with the one you pretend to be? But this string gives certain problems even if the browser string is for real - but more on that later.
Another method is the classic test:
script language="JavaScript">
if (document.document.images)
//the browser is NS 3+, IE 4+
if (!document.document.images)
//the browser is NS 2, IE 3
if (document.document.layers)
//the browser is NS 4
if (document.document.all)
// the browser is IE 4+
if (document.getElementById)
//the browser is IE5+ or NS6+
if (document.getElementById && !document.all)
//the browser is NS6+
This somewhat unreadable code is not error-proof either. It sometimes gives the strangest results, not to name MIE on PocketPC as an example. Web crawlers also seem to dislike this code.
W-Y-S-I-N-A-W-Y-G (What You See Is Not Always What You Get)
A couple of years ago we were searching for a method to let professors and others edit their syllabi via a web interface. We wanted to make sure that non-HTML gurus would be able to do this in a consistent way according to the house style. We needed to prevent blinking pink letters or obsolete HTML code generated by some HTML editors that were then pasted into our editor. And of course the main requirement was that it had to run on as many browsers/platforms as possible. We soon discovered that the latter was the major problem as we searched around to see what was available. Nearly everything was solely MIE-minded, with not even the slightest concern about other browser or even platforms. The following describes part of our journey and the pitfalls encountered along the way.
The Flashy Way
After a while we decided not to concentrate on the browser differences anymore and started looking for external solutions. The most obvious choice was Macromedia Flash. At that time Macromedia had just released the Developers Resource Kit Volume 2 (http://www.macromedia.com/macromedia/proom/pr/2002/drk2_announce.html), which contained the Flash UI Component Set 4. This component set included a rich text editor that was a perfect start for our solution. Of course it wasn't an off-the-shelf, ready-to-go-product, so we needed to do some extra work. Briefly put, this came down to:
a) The editor needed to be adapted to our needs.
b) The editor needed to retrieve data from SAP and store it again after editing. Some heavy communication between Flash, JavaScript, and SAP needed to be implemented in order to achieve this. The content could be relative, so it couldn't be put as parameter for the swf. So the Flash editor needed to retrieve the data itself. This is a tutorial on Flash that I can refer you to if you want to know more: http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_15683
c) On the SAP side, you needed to retrieve the data and 'serve' it to the editor.
Step 1: Create a BSP page.
Step 2: Put all the code for retrieving the data in the OnInitialization event handler.
Step 3: Put all the data in one string
Step 4: Make sure that the mime type is set correctly, and deal with special characters in order to let the editor understand them.
call method runtime->server->response->set_header_field
EXPORTING
name = 'content-type'
value = 'application/x-www-urlform-encoded'.
class cl_http_utility definition load.
Final_content = cl_http_utility=>escape_url( unescaped = original_content ).
Step 5: Put the content in the layout.
<%@page language="abap"%>
&content=<%=content.%>
d) When deploying the whole thing, make sure that you users have (the correct version of) a Flash Player installed. This might be somewhat tricky. Users aren't always allowed to install software on their own because it may be managed centrally via Tivoli for example, or for other reasons. So even if you explicitly specify in the codebase of your flash object that the browser will install the Flash Player automatically, don't rely on this fact.
The CSS Way
Suddenly clouds appeared, covering the sun up completely. The so-desired cross-platform feature didn't work at all anymore, after more than a year of running smoothly. We hadn't changed anything in the code and suddenly the editor didn't work anymore on Mozilla for Mac OS X and Linux (in our example RH 8). It was a total mystery to us.
The true reason was discovered after some extensive interchanging of information with Mozilla. The reason was that Flash was compiled with GCC 2.X and Mozilla (starting from a certain version) with 3.2. According to Mozilla there were "ABI incompatibilities" between the two GCC versions, which means that it doesn't work anymore. "Downgrading" Mozilla and compiling with the lower GCC was impossible due to incompatibilities with other Java plug-ins and for other reasons. We couldn't ask our users to compile their Mozilla by themselves with the correct GCC in order to make the editor work again. The only option seemed to be to wait for Macromedia to launch a GCC 3.2 compiled version. In fact, that wasn't really an option at all since we didn't know when that would be, and Macromedia didn't reply at all to our questions concerning this matter.
So we were back to where we started, but with multiple (future) applications requiring this editor. Luckily for us, computer science is ever-evolving. It didn't take us as much time as we thought to find an alternative. We found it in "Through-The-Web (TTW) Editor." [http://www.koivi.com/WYSIWYG-Editor/] This neat editor - called TTW - is first of all cross browser/platform. It didn't support all that we wanted, but was a start and better than a single browser/platform solution. Rome wasn't built in a day either, so there will be a day that we or someone else can provide the missing support in the future.
Also, it fell under the GNU Lesser General Public License (LGPL). Of course, it wasn't an off-the-shelf product, but took less effort to implement. We needed to adapt the editor to our needs, but we didn't have to build communication between the editor and SAP because it could be put directly in the BSP page. Strictly speaking, the editor comes down to some HTML and Javascript, and as such is a piece of cake for implementing in a BSP page.
The clouds vanished again, until a couple of months ago. It didn't work anymore for Mozilla on Debian Linux. To be more precise - it didn't recognize this browser as legit. What happened? The TTW editor uses the browser detection mechanism devised by Chris Nott (http://www.dithered.com/javascript/browser_detect/index.html), which falls under a Creative Commons License. This mechanism is based on the browser string that I already talked about before. It seemed that the length of the browser string was longer for Debian than for the others. We had to adjust this before because the browser detect didn't know what Camino was and recognized Firefox only by its old name (Firebird).
As previously said, detetecting via the browser string can be somewhat tedious and a neverending story. I once printed this list of ID strings on a printer capable of printing on both sides of paper, 2 pages on a side, making a booklet in small print and the result was > 50 pages: http://www.zytrax.com/tech/web/browser_ids.htm (please do read the more interesting "Browser Rants" at the end of the document).
My suggestion would be to download the latest version of browser detect and modify wherever applicable according to your needs and specifications of TTW.
The SAP Way
I hear you thinking that I'm always searching/giving solutions outside SAP. That's not exactly the case. We tried hard to find a solution from within SAP. We didn't find any. That is until December 15th 2004 when reading Thomas Jung's excellent weblog, Using the BTF Editor. Honestly, I was stunned. How couldn't we find this, and think that BTF only stood for the Behavioral Task Force, Beyond the Frame, the Buffalo Teacher Federation, or even Behind The Flag of Sheffield FC (to name a few) - and not the Business Text Framework, which came available in WAS 6.20. So I immediately started the BTF_EXT_DEMO and had a look at it. It looked really nice, but when we tested it in e.g. Firefox it didn't show things as expected. We have just upgraded to WAS 6.4 but Firefox unfortunately gave the same incorrect result.
The Ultimate Solution?
SAP has also been thinking about this cross browser/platform problem and looking for a solution to it. Their result is called Web Dynpro. These sentences from Service Marketplace say it all: "Web Dynpro is based on a powerful and flexible Model-View-Controller architecture that ensures a clear separation of user interfaces and backend services…. Design as much as possible and program as little as necessary: Higher productivity through declarative approach to modelling, instead of programming, layout, screen usage, navigation, and data binding."
Isn't that great? No more concerns about browsers and platforms; Web Dynpro will do all the thinking for you. The PAM – dd. December 30th 2004 published at https://service.sap.com/nw04 – of SAP NetWeaver starting with SP Stack 11 shows only a limited amount of supported browsers/platform under certain conditions. The new browser war may cause a new speed injection for new functionality, perhaps resulting in a whole new type of browser and the way we surf the Internet. Will SAP and Web Dynpro be able to catch up in/each time?
Secondly, will Web Dynpro support all the things we/you need in a site? I know it's impossible to cover it all and fulfill all our wishes. The future will tell what magical things Web Dynpro can do for us. For now, it already looks great and promising.
The Author
Eddy De Clercq has 20 years experience in computing. Currently he works at the Katholieke Universiteit Leuven (Belgium), the oldest university of the Low Countries and the largest Flemish university. Eddy makes up part of the E-university team which creates mostly self services (web) applications.
0 Comments: