|
Auto-Complete with Cookies using Mark's Communicator
What is this?
This is a demo of autocomplete. Initially, the dropdown box at the right is filled up with
50 states. After you type a character, say "c", "California" the first item in the subset
starting with "c" (ignoring cases) will be selected in the select box and the content of
text box will be changed to the first item, "California", too. If you look inside the
dropdown box now, you will see only the subset (3 states) instead of 50 states. This
demo not only shows how the remote scripting is done but also describe how Mark's
Communicator is built.
Compatibility: IE (6.x, 7.x), FireFox (1.5.0.4), Mozilla/Netscape(7.2), Opera(9.0)
were fully tested and worked in XP (v2002. sp2).
Design goal of Mark's Communicator:
the goal of Mark's Communicator is to wrap the implementation details to provide
its users a easily and clean remote scripting environment. It won't be necessary
for its user to learn what meant is used (they have their control if they want to)
and the Communicator will detect the maximum available environment and pick the
best one. Only thing they need to do for the communication is getting the result
return by server from Communicator in the handler they provide.
Design Issues of Mark's Communicator: the of Mark's Communicator is to wrap the
implementation details to provide its users a easily and clean remote scripting
environment. It won't be necessary for its user to learn what meant is used
(they have their control if they want to) and the Communicator will detect
the maximum available environment and pick the best one.
- Encapsulation
I wrapped all the communication details into a single js object, Communicator
In this way, detail implementation of Cookies is transparent to programmers using
Communicator. See communicator.js for details.
- Inheritance
Pattern "Template Method" is used so that the implementation of "sending" is
postpone to the subclass of Communicator such as CookieCommunicator. In this way,
all the concrete Communicators only have their send method different to maximize
code sharing and consistency. See CookieCommunicator.js for details.
- Preserving objects crossing the gap between sending and receiving
There are two chanllenges in this example:
1). preserve the reference of callback handler, "handler", so that we
can still access it when the callback wrapping method, "process", is
invoked in "process's" execution context. See details in CookieCommunicator.js.
2). the method "autocomplete" needs to be invoked in "hanlder" after the
response arrives so that we can select from the updated list but
all the parameters "autocomplete" needs are only available before sending.
So there are two closures formed to preserve them. See cookie1.jsp(closure 1) and CookieCommunicator.js(closure 2).
- Communicator pooling
The CookieCommunicator is pooled and managed by CCManager.
The reason I used a callback wrapper, "process", as onreadystatechange, instead
of the real callback function, "handler", is that I can do some preprocess and
clear up around "handler". This will give me a chance to maintain pool related
states used by my CookieCommunicator.
Running page:
Source Codes
- Mark Qian's codes:
- Third Party's codes:
|
|