во-первых, насчет чужих контролов
посмотрите, например:

http://bindows.net/
http://activewidgets.com

этот прекрасно написанный код можно и нужно использовать, или хотя бы по нему учиться. и старайтесь не использовать чужие JS компоненты, потому что будучи сложены в одну кучу они дают невалидный, несовместимый выход, практически не поддающийся отладке.

во-вторых, используйте XMLHttpRequest! работа со справочниками, автодополнением, сортировкой таблиц, in-place-редактированием, расширением форм в зависимости от выбранных параметров облегчается на порядок! ключевые слова AJAX, XMLHttpRequest - на асинхронных запросах уже делают крупные фреймворки, гляньте например Echo 2 Framework. для того, чтобы понять, как это работает, смотрите например, http://sarissa.sourceforge.net/doc/ .старайтесь не тащить в будущее все те грабли, которые били по башке веб-девелоперов еще 5 лет назад.

Это Интранет приложение, я навоял такую же систему и она трудится под IE 6.0 на оптовом складе. И нормального приложения без ActiveX не сделаешь, а не все бройзеры держат технологии от Microsoft. Так что для Инет свои просмотрщики, для Интры свои. Собственно не все технологии разрабатывались дли Инет и Интранет, везде свое, окромя DHTML естестно :)

я придерживаюсь мнения, что разработка комплексного gui на html/js для оператора - дело трудоемкое, дорогое и в большинстве случаев - не оправданное.

альтернативой является разработка rich-gui, работающего на одной из надстроек http-протокола, наподобие soap или xml-rpc. при этом сам ui может быть выполнен с использованием любых средств, хоть vcl, хоть qt.

объединяет эти два подхода следующее:

- обмен данными производится по текстовому протоколу, информация спокойно проходит любые прокси- и иса-серверы
- не требуется установка дополнительного программного обеспечения, такого как драйвера бд (в некоторых случаях возможно обойтись _вообще_ без установки по, если использовать что-то наподобие java web start)

плюсы у rich-gui следующие:

- возможность пользоваться любыми преимуществами, которые предоставляют нативные и пользовательсвие виджеты. соответственно, удобство и скорость работы для оператора
- клиент получается полноценно stateful, в отличие от стандартного браузерного интерфейса. возможно хранение жирных словарей на клиенте, кеширование любой информации
- простота взаимодействия с ПО рабочей станции (например, генерация отчета в word или обращение к местной БД через odbc-смычку)
- полное отделение представления от данных
- из предыдущего следуют значительное облегчение отладки, ввиду жесткой формализации протокола, отсутствия необходимости контроля всяких специфичных для browser-gui особенностей, типа повтороного ввода, потери кукисов, порчи адресной строки и тп. и тд

минусы

- более четкие требования к платформе (тут неоднозначно, потому что использование ie-only скриптов накладывает ограничения еще более жесткие, вплоть до версии браузера)
- требуется более высокая квалификация разработчиков
- требования безопасности отдельных контор могут запрещать выполнять любой не прошедший тот или иной вид сертификации код.

just another freak in the Freak Kingdom

PS: реализовывал клиент/сервера таким образом на mfc -> php, vcl -> isapi, swing, swt -> axis.

just another freak in the Freak Kingdom

>> и старайтесь не использовать чужие JS компоненты, потому что будучи сложены
>> в одну кучу они дают невалидный, несовместимый выход, практически не
>> поддающийся отладке.

отдельные чужие мелкие JS-компоненты

just another freak in the Freak Kingdom