Browser Support in Pavuk
Bill Crowell
Martin Phillips contacted me and it is evident that I was not clear in
my previous posting regarding browser support in Pavuk. I see a few
jabs here and there from some of the others on the list.
Pavuk emits W3C compliant HTML and Javascript. It keeps within the
official, published standards. Standards are good.
What this means is that if a browser will render forms within the
published standards, it will run Pavuk just fine. Martin has reported
that forms render for him nicely on his workstation and he is using
IE. My beta site was running IE and the forms were rendering, but
because of old versions of Windows, really crappy hardware, the
rendering of very complex forms such as a complete eye exam with over
150 controls was slow in IE. On the very same computers, installing
Safari presented a 5x increase in speed on the very same hardware.
What I've seen over the years is that many releases of IE do not
conform to the standards and have issues - not just for Pavuk, but for
many web sites. We've also seen problems in some versions of Opera.
Fortunately, the Opera people acknowledge their bugs and try to fix
them and generally do so quickly. MS is not as responsive. The Firefox
people also do a very good job, though their latest versions are
rather bloated.
The whole point in having a web application system such as Pavuk is to
support as many devices as possible and let the user decide if they
want to run Linux, Windows or Mac desktops, iPhones or even
Blackberries and still be able to use an application system. Pavuk
runs nicely on all of the tested platforms.
The caveat really is that MS regularly breaks something in new
releases of IE and all web developers have problems adjusting their
web services to deal with the latest bugs from MS. What I'm saying is
that, if MS releases a version of IE that causes problems for the
world in general, Pavuk is not going to have a rewrite just because of
the bugs du jour of IE.
If one examines the source HTML of many web sites, they have the
equivalent of:
begin case
case browser is IE version x; do this
case browser is IE version y with patch level 3; do something else
case browser is IE version z; do yet something different
...
end case
Pavuk has been tested to run:
Windows XP Pro: Most versions of IE, Safari, most versions of Opera,
Firefox
Mac OS X: Safari, Opera, Firefox
iPhone: Safari
Linux: Firefox, Opera
Cheers!
Bill
Tony Gravagno
some coding concepts.
Browser issues aren't _that_ serious. The problem is making all
browsers look exactly alike - a developer can spend days trying to
make output in each browser look exactly the same. However, when one
realizes that the UI's don't need to look exactly alike, they just
need to work unto themselves, then most of the problems go away.
These days JavaScript libraries like jQuery, ExtJS, and Prototype help
with a lot of that.
Regarding "case browser is IE version x" type logic. If that's the
way you're coding then you're presenting yesterday's technology as
tomorrow's solution. Servers can easily tell which browser the client
is running so there is little reason to export a bunch of code to the
client and ask it to figure out what it's going to do. Just export
the code required to make a specific browser do what it should do
under specific circumstances. Again, as above, any one client
interface doesn't need to know what another client looks like, each
client can accept and render specifically targeted code. And
debugging is a Lot easier if client only has one set of
browser-specific code for you to debug.
This is one of the reasons why I use ASP.NET. Very little of the
effort is browser-specific. The runtime generates the right code for
each client that connects in. You can choose to get your hands dirty
with wiring that involves scripting but in most cases that's
unnecessary, so a lot of the browser-specific issues with wiring
events and updating components all goes away.
And this is also one of the reasons why Flex (soon to be renamed back
to Flash just to create more confusion *sigh*) is very popular for
RIA, and why Silverlight has been gaining rapid traction in this area
as well. One of the key differences between these is that Flex is
mostly JavaScript coding for the client, while in Silverlight you code
with VB.NET or C#, the same languages you use on the server. I
haven't quite jumped onto that bandwagon yet but it's definitely a
viable option for most applications.
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno
Mike Preece
I believe you're doing exactly the right thing in adhering to W3C
standards. It can be difficult at times to resist the temptation to
use MS "extensions" but resist we should - imo.