да какое там апи.. обычный сайт. Если сайт видит, что в урле есть subdomain, то ставит в топ статьи для текущего юзера. Вот и все. А по поводу routing - в настройках домена выставляете А запись на * чтобы все сабдомены шли на один IP, а потом в nginx пишете конфиг для wildcard subdomains
Андрей Никифоров: тогда правильный вопрос чем апи занимается внутри. Если это прослойка/роутинг между сервисами, то язык роли не играет. А если сложные вычисления, то конечно стоит подумать.
Андрей Никифоров: а если 1 запрос в секунду на сервер? Это высокая нагрузка? А если я скажу что это перекодировка видео? Все относительно. Сервер может и 20,000 запросов в секунду обрабатывать и это НЕ будет высокой нагрузкой если это просто сброс данных в таблицу, например (логирование).
Андрей Кондратьев: Чаще упираются во внешние сервисы, в базу например. Язык вторичен. Большая часть времени в веб уходит на IO. Когда сервис упрется в язык, вы будете уже богаты :)
Ну вообще я писал о том, чтобы бросать перебор при первой успешно примененной регулярке. Неверно искать зависимые части отдельно (множества могут перекрываться), это должна быть одна общая регулярка. Хотя конкретно в вашей задаче наверное можно и разделить, вам просто минимальное и максимальное число найти нужно.
В таком случае может быть подойдет просто:
^.*?(\d+).*?(\d+)?
По поводу склейки — это не проблема вовсе, там по длине правила определяется приоритет + если явно не заданы настройки текста, то они переходят от родительского элемента. Важнее найти подходящие правила.
Вот вы написали: .base .child и .base .child .node
А ведь может быть и: .base .child и .node
Т.е. .node может быть и внутри и снаружи.
Да, я по второму варианту и хотел делать, вопрос только в эффективном и правильном поиске правил для заданного пути.
Хм… накладывать на уже готовый DOM список селекторов это идея. Тут надо подумать что быстрее: искать css селекторы в DOM, или искать список правил для заданного пути DOM.
С css-селекторами в dom наверное проще будет в реализации, т.к. есть готовые билиотеки поддерживающие xpath, но чего-то скорость беспокоит. Типичный сайт имеет от 3-5 тысяч css селекторов… для каждого вызывать прогон по DOM накладно… будем эксперементировать.
>> Тогда зачем Вы искали CSS парсер в Chrome (сами же писали)
Как зачем? Прежде чем писать свой, хотел гугловский портировать на python, он же наверняка там учитывает много особенностей css и поддерживает css3. Велосипед еще не значит что мне не интересны другие реализации.
За ссылку спасибо.
>> И почему Вы решили, что поиск снизу вверх будет быстрее
Тут не в «быстрее» даже дело, а в том что конечный элемент находится справа. Зачем нам проходить через span, p, div и т.д. если нам нужно множество 'a' элементов? По такой же логики и работа с предыдущими элементами. Тут полюбому инверсия эффективнее прямой структуры.
Грубый пример прямой таблицы:
div <rule>
p span <rule>
div p span <rule>
div h3 span a <rule>
a <rule>
Обратная таблица:
div <rule>
span p <rule>
span p div <rule>
a span h3 div <rule>
a <rule>
Тогда при запросе table.get_rules('html > body > div > h3 > span > a') я уже первым прогоном сужаю область правил до 2х, а вторым прогоном получаю более конкретное (приоритет при слиянии).
Прямой поиск тут однозначно проигрывает. Я даже не могу придумать нормального алгоритма для поиска по прямой таблице.
