AJAX Capability Detection and Support Strategy Questions

[Johnson]

While I have done a substantial amount of ASP.NET programming, I have only
dabbled with AJAX (update panels and a 3rd party JSON setup - jayrock - that
directly updates the DOM). In any case, I'm considering offering Web pages
both to browsers that support AJAX and to those that do not support AJAX.

Questions:
1. In general, should I look to offer two versions of each page - one for
AJAX clients and the other for "non AJAX-supporting" clients? Or is it
reasonable to pursue the creation of a single page that renders differently
based on the browser capabilities? I'm not afraid of writing code to make
the single-page approach happen, but I also would go for two pages if that
would avoid a lot of headaches or unnecessarily complicated pages.

2. What browser capabilities specifically do I look for to know if a
client/browser supports AJAX? I'm sure JavaScript must be enabled, but what
else? Am I simply looking for uplevel vs downlevel browsers? I would not
think so given that many downlevel browsers support JavaScript.

The ASP.NET pages in consideration here will generally not be very
complicated - just displaying data in pretty tables, collecting some data
via text boxes, and providing buttons to submit updates. After the updates,
some of the displayed data would change. There might be an occasional
drop-down list or tree view control that auto posts back. But that's about
it.

I'm using Visual Studio 2008 /.NET 3.5 SP1.

Thanks!

[bruce barker]

it depends on the ajax toolkit. they will require javascript be enabled,
but don't require any special javascript features. the ajax call
requires connecting to the server. this is usually done with the
browsers XMLHttpRequest object or the msxml active/x object in IE. Some
browser's (say mobile) may that have these, so some kits will fall back
to using an iframe which only supports async callbacks. but you almost
always want a seperate mobile site.

the uplevel/downlevel is a measure of css and dhtml support. these say
what javascript can do to the browser. its a better practice to do this
detection on the client side.

-- bruce (sqlwork.com)

Johnson wrote:

While I have done a substantial amount of ASP.NET programming, I have only
dabbled with AJAX (update panels and a 3rd party JSON setup - jayrock - that
directly updates the DOM). In any case, I'm considering offering Web pages
both to browsers that support AJAX and to those that do not support AJAX.

Questions:
1. In general, should I look to offer two versions of each page - one for
AJAX clients and the other for "non AJAX-supporting" clients? Or is it
reasonable to pursue the creation of a single page that renders differently
based on the browser capabilities? I'm not afraid of writing code to make
the single-page approach happen, but I also would go for two pages if that
would avoid a lot of headaches or unnecessarily complicated pages.

2. What browser capabilities specifically do I look for to know if a
client/browser supports AJAX? I'm sure JavaScript must be enabled, but what
else? Am I simply looking for uplevel vs downlevel browsers? I would not
think so given that many downlevel browsers support JavaScript.

The ASP.NET pages in consideration here will generally not be very
complicated - just displaying data in pretty tables, collecting some data
via text boxes, and providing buttons to submit updates. After the updates,
some of the displayed data would change. There might be an occasional
drop-down list or tree view control that auto posts back. But that's about
it.

I'm using Visual Studio 2008 /.NET 3.5 SP1.

Thanks!

[Johnson]

Thanks Bruce... regarding: "...but you almost always want a seperate mobile
site."... yes I agree and understand about mobile devices. But in my case
I'm targeting only full-fledged browsers and not mobile devices. So, given
that consideration, is it still a general recommendation to have a separate
copy of the pages or site - one for AJAX enabled browsers and a separate
copy for non AJAX-enabled browsers? Or for non complex pages is it generally
acceptable to have one copy of the page that can work via AJAX or classic
full-page postback?

Thanks,

- J
"bruce barker" <no****@nospam.comwrote in message
news:uB**************@TK2MSFTNGP05.phx.gbl...

it depends on the ajax toolkit. they will require javascript be enabled,
but don't require any special javascript features. the ajax call requires
connecting to the server. this is usually done with the browsers
XMLHttpRequest object or the msxml active/x object in IE. Some browser's
(say mobile) may that have these, so some kits will fall back to using an
iframe which only supports async callbacks. but you almost always want a
seperate mobile site.

the uplevel/downlevel is a measure of css and dhtml support. these say
what javascript can do to the browser. its a better practice to do this
detection on the client side.

-- bruce (sqlwork.com)

Johnson wrote:

>While I have done a substantial amount of ASP.NET programming, I have
only dabbled with AJAX (update panels and a 3rd party JSON setup -
jayrock - that directly updates the DOM). In any case, I'm considering
offering Web pages both to browsers that support AJAX and to those that
do not support AJAX.

Questions:
1. In general, should I look to offer two versions of each page - one for
AJAX clients and the other for "non AJAX-supporting" clients? Or is it
reasonable to pursue the creation of a single page that renders
differently based on the browser capabilities? I'm not afraid of writing
code to make the single-page approach happen, but I also would go for two
pages if that would avoid a lot of headaches or unnecessarily complicated
pages.

2. What browser capabilities specifically do I look for to know if a
client/browser supports AJAX? I'm sure JavaScript must be enabled, but
what else? Am I simply looking for uplevel vs downlevel browsers? I would
not think so given that many downlevel browsers support JavaScript.

The ASP.NET pages in consideration here will generally not be very
complicated - just displaying data in pretty tables, collecting some data
via text boxes, and providing buttons to submit updates. After the
updates, some of the displayed data would change. There might be an
occasional drop-down list or tree view control that auto posts back. But
that's about it.

I'm using Visual Studio 2008 /.NET 3.5 SP1.

Thanks!