Ajax and cascading drop downs

[Colin Walls]

I have been asked to produce a web catalogue of services and associated
options, this eventually will be used for ordering the services.

My initial thought was to use a set of cascading drop downs, select an
option from the first fills the available options for the second and so on.
Given the current buzz about Ajax this would seem an opportunity to try out
some of its features.

Could anyone point me at an example of what I am trying to do? For
information, the target web server environment is Apache with both mod perl
and mod php being available.

The result should be browser neutral.

 

[VK]

That's pretty close to what you're looking for:

<http://developer.apple.com/internet/webcontent/XMLHttpRequestExample/example.html>

 

[RobG]

That's pretty close to what you're looking for:

<http://developer.apple.com/internet/webcontent/XMLHttpRequestExample/example.html>

It doesn't work in Safari 1.0.3 but it's fine in Firefox 1.0.4

Does I gotta get me Tigger?

:-x

 

[VK]

It doesn't work in Safari 1.0.3 but it's fine in Firefox 1.0.4
Does I gotta get me Tigger?

Grrh...

This Safary is a real pain in one place. From one side it still seems
to be the browser of the choice on Mac OS X, from other side it's not
something you can install for testing on Win XP.
And one good profound test results table, just different rumors here
and there.
Got this link though, may be relevant or not:
<http://www.bitterpill.org/logid/1117777362000>

 

[Richard Cornford]

I have been asked to produce a web catalogue of services
and associated options, this eventually will be used for
ordering the services.

So this is a commercial endeavour with the intention of making money.

My initial thought was to use a set of cascading drop downs,

Introducing a javascript dependency that will reduce the potential
customer base.

select an option from the first fills the available options
for the second and so on.
Given the current buzz about Ajax this would seem an
opportunity to try out some of its features.

But as AJAX depends on xmlHttpRequest objects you would compound
javascript dependency with a reliance on the user agent being one of a
limited set of modern(ish) dynamic visual browsers. And the most common
of those, IE, in a subset of configurations (ActiveX enabled).

AJAX has a place, but that is probably in web applications that can be
specified as trusted to be safe enough to place in a less restricted
security zone. In a public front line selling context the being 'flash'
with AJAX might have such an impact of potential turnover that its use
should be subject to informed confirmation before hand from those with a
business interest in the outcome.

Could anyone point me at an example of what I am trying
to do? For information, the target web server environment
is Apache with both mod perl and mod php being available.

The result should be browser neutral.

Then you cannot use AJAX and cannot be javascript dependent. So you are
left with doing the work on the server and generating standard HTML
forms for user input. So a 'wizard' style where the user enters a
selection on one page, submits it, and gets the narrower options
presented on the next. That is as near 100% reliable in all HTML user
agents as it gets, maximising the potential customer base.

More elaborate designs might start from the reliable server-side code
and use client-side technologies to enhance the process. Skipping steps
bringing information into new elements in existing forms in response to
user selections, with background requests. Such enhancements would be
conditional on the availability of the client-side features and designed
to fall-back to the server-side alternative in the absence of those
features. Thus a 'best of both worlds' approach providing the
reliability and browser neutrality of the server-side process and the
'flash' of a scripted dynamic client whenever it was available.

Richard.

 

[Colin Walls]

So this is a commercial endeavour with the intention of making money.

That is the aim for the company. My aim is to make an effective way for
people to order a complex product in as simple a fashion as possible.

Introducing a javascript dependency that will reduce the potential
customer base.

Ordinarily I would agree with you. However this is a direct extranet
connection between two companies.

But as AJAX depends on xmlHttpRequest objects you would compound
javascript dependency with a reliance on the user agent being one of a
limited set of modern(ish) dynamic visual browsers. And the most common
of those, IE, in a subset of configurations (ActiveX enabled).

AJAX has a place, but that is probably in web applications that can be
specified as trusted to be safe enough to place in a less restricted
security zone. In a public front line selling context the being 'flash'
with AJAX might have such an impact of potential turnover that its use
should be subject to informed confirmation before hand from those with a
business interest in the outcome.

See above.

Then you cannot use AJAX and cannot be javascript dependent. So you are
left with doing the work on the server and generating standard HTML
forms for user input. So a 'wizard' style where the user enters a
selection on one page, submits it, and gets the narrower options
presented on the next. That is as near 100% reliable in all HTML user
agents as it gets, maximising the potential customer base.

Again, I would normally agree with you. However, in these particular
circumstances I have chance to learn something new in a fairly controlled
environment.

More elaborate designs might start from the reliable server-side code
and use client-side technologies to enhance the process. Skipping steps
bringing information into new elements in existing forms in response to
user selections, with background requests. Such enhancements would be
conditional on the availability of the client-side features and designed
to fall-back to the server-side alternative in the absence of those
features. Thus a 'best of both worlds' approach providing the
reliability and browser neutrality of the server-side process and the
'flash' of a scripted dynamic client whenever it was available.

Actually, this is probably fairly close to what I was intending to do.