Разработка поиска в стиле Quicksilver на основе AJAX с несколькими поисковыми плагинами для веб-сайта

Question

Я пытаюсь создать поисковую систему в стиле Quicksilver для внутреннего веб-приложения, которое мы разрабатываем на работе. Есть множество примеров действительно классных внешних интерфейсов для этого с использованием JQuery, MooTools или чего-либо еще. Ни один из этих примеров не говорит о серверной части. Насколько я могу судить, в этих примерах предполагается, что серверная часть выполняет поиск в одной таблице или, по крайней мере, выполняет один запрос. Что я хочу сделать, так это спроектировать систему, в которой вы можете буквально напечатать на ней что угодно и найти то, что искали. В идеале я хочу иметь возможность просто написать плагины для этой системы, вставить их и начать поиск.

У меня есть решение, в котором сервер использует шаблон наблюдателя для отправки запроса в различные плагины для каждого типа поиска. Однако это вернет результаты всех плагинов в виде одного чанка. Это может стать заметно медленным, если есть много видов поиска. Мне бы хотелось, чтобы он был быстрым и возвращал результаты более асинхронно, где результаты отображаются по мере их поступления, например, в Spotlight OS X или Quicksilver.

Другое решение - написать на лету массив javascript с именами подключаемых модулей. Затем я мог бы выполнить отдельные запросы к серверу с помощью запроса, по одному для каждого плагина. Что-то в этом решении кажется ... не для меня. Я не могу точно указать на это пальцем.

Итак, мой вопрос: есть ли у кого-нибудь лучшие решения для построения поисковой системы на основе плагинов, в которой отдельные типы поиска не известны до загрузки страницы и результаты возвращаются как можно скорее?

Answer 1

Другое решение - написать на лету массив javascript с именами подключаемых модулей. Затем я мог бы выполнить отдельные запросы к серверу с помощью запроса, по одному для каждого плагина. Что-то в этом решении кажется ... не для меня. Я не могу точно указать на это пальцем.

Это не похоже на плохой вариант. Это дает вам все необходимое.

1. Вам нужны результаты поиска, чтобы вернуться как можно скорее.
2. Это позволяет вам использовать вашу существующую архитектуру плагинов, я считаю.
3. Он следует принципу KISS .

Это не новое решение, но я думаю, что оно самое простое.

Привет.

Answer 2

Из всех комментариев и разговоров кажется, что вы хотите создать это на переднем крае.

Не создавайте массив плагинов, чтобы вызывать его, что заставляет вас беспокоиться о кешировании, когда вы заменяете плагины, которые вы должны сделать вместо этого - создать систему начальной загрузки. Это был бы простой вызов ajax, который получил бы список плагинов с URL для вызова. Это позволит вам включать и выключать плагины из центрального расположения, и это будет работать лучше.

Вы должны будете превратить каждый из ваших плагинов в веб-сервис, а не в плагин, чтобы каждый из них мог вызываться независимо. Обязательно используйте ссылку mediasalve о количестве подключений, потому что она будет ограничена браузерами, если вы не обойдете ее.

Answer 3

Вы можете сделать решение Comet style , которое использовало длинный опрос в Ajax для получения результатов поиска. Создайте одно место для вызова скрипта, который будет возвращать результаты всех плагинов по мере их поступления. Этот метод позволяет быстрее отображать быстрые результаты.

Наличие массива плагинов является опцией, но некоторые браузеры ограничены 2 запросами одновременно, что ограничивает количество запускаемых запросов и может привести к тому, что быстрому процессу придется ждать медленных процессов.

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

Несколько комментариев на заднем плане из комментария. Создайте рабочую очередь, чтобы поисковые запросы могли передаваться многим работникам. Можно было бы реализовать рабочую очередь в БД или через веб-сервис, чтобы вы могли использовать другие языки или даже компьютеры для выполнения работы для каждого поиска. Рабочему вызову потребуется некоторый идентификатор для передачи назад, чтобы направить данные нужному клиенту. Также вам нужен способ удалить задания из очереди или хотя бы пометить всю работу для клиента как недействительную, если этот клиент уйдет. (Вы должны быть в состоянии обнаружить это, если вы используете длинный опрос.)

Пределы подключения

IE7 для HTTP1 4

IE7 для HTTP1.1 2

IE8 для HTTP1 6

IE8 для HTTP1.1 6