Ken Slovak - said:
No. You would have to write a custom OWA that would have to be
different for every version of Exchange server that had to be
supported and rewritten every time the server was updated with a
service pack.
Actually, it's not that hard ;-)
Neither do you need to write it different for every Exchange Server version
nor do they need to get rewritten after a service pack has been applied.
Since Exchange 2000 has been introduced in September 2000 the latest
Exchange Web Form architecture works with any version (including Exchange
2003) and service pack without rewriting it. Though this architecture does
not work with the legacy Exchange 5.5 server, but won't mattter in the near
future since Exchange 5.5 is on its demise. And if you ever tried to make an
Outlook form work with Outlook 97 up to 2003 you know that this isn't
trivial too. In fact I recently saw, again, an Outlook form which opened
fine in Outlook 2000 RTM but refused with a "MAPI Error" when trying it with
Outlook 2000SP2. Since such Outlook forms are binary blobs you are pretty
much left with redoing the form completely - yuck.
Other additional benefits of Exchange Web Forms are that they work in any
browser, including Safari on the Mac (where an Outlook form doesn't run at
all) and on any operating system and version (even Linux). Another advantage
is that if you want to use additional controls on your form, like a calendar
picker, you don't need to deploy those to each client computer since it all
runs off the Exchange server.
Also, for those experienced Outlook developers nothing new, you don't need
to worry about such things like the local Outlook forms cache (which is
prone to get corrupted). Another plus is if offline access to the data isn't
a requirement you can easily use your Exchange Web Form even directly out of
Outlook by installing a little proxy form (which redirects any open request
made with Outlook to the Web Form - did this about 3 years ago). By
double-clicking the item in Olutlook it'll then open the Web Form. That way
development cost and time can be dramatically reduced (isn't cutting cost
the most important thing with the current economy?).
Another plus for Web based forms is that you can use established
technologies like (D)HTML, CSS, JavaScript etc. without learning that stuff
again. Also with the Internet full of sample code for those technologies it
is fairly simple to find something one just need to customize. E.g. I
recently found a JavaScript based calendar control which I have embedded on
an Exchange Web Form (no client installation necessary like with an Outlook
form and it worked straight out of the box). Not to mention that you don't
need a particular client to develop a Web Form. It can be done with
Frontpage, Visual Studio (for those who prefer a fully integrated IDE) or
just a simple text editor like UltraEdit or even Notepad (used to be my
prefered Web form editor for years).
To sum it up: there is only one reason where an Outlook form should be
preferred and that's when offline access is required (I'm fairly sure even
that case could be worked around with a Web form solution but I haven't
spend any time yet to explore this venue). In any other case an Exchange Web
form is the smarter choice since it is not locked into a particular client
application, not a binary blob, doesn't require a steep learning curve to
learn a new (Outlook) object model (and probably VBScript) and a new (very
limited) Outlook forms programming model, which makes it a snap with a
finger for an experienced Web developer doing Exchange OWA/Web forms instead
of an Outlook form.
