можно что-нибудь придумать против jdghsgdhgshksg, в качестве названия вакансии на сайтах по работе ?
если не вести индекс со спарсенными названиями профессий, то хотя бы проверять язык ввода, и если он не "ру", то сперва требовать зарегистрироваться (введя номер телефона), так как вакансии в иностранные компании только для VIP-ов ))
зы: кстати, идея )
эти нравятся
http://klikvip.com/
http://daoklick.com/
http://www.affiliatecube.com/
если для хранения пользователей и групп - одного рута хватит с головой (вы подобие ACL хотите организовать, как я понимаю ?), кроме того, в первой ссылке вы добавили, что нет необходимости в пересчётах левых/правых ключей. Вот этот пересчёт - самое слабое место вложенных множеств.
То есть, как бы лично сделал я, в случае хранения иерархии пользователей и их прав - использовал бы одну рутовую ноду. Но, если задача стоит просто организовать иерархию пользователей, отношение их к конкретным группам (и не только к одной), и все возможные права на объекты модели данных проекта, рекомендую почитать об ACL (по-русски, с иллюстрациями) и используемых структурах, как таковых, безотносительно к конкретному движку и прочее.
у тебя ж вроди свой с морфологией был ?
ну, называйте это известностью или славой ) не каждый платник по телеку показывают )
лично я использую множество корней, для оптимизации работы скрипта при удалении/вставке дочерних нод. Но эта структура базы будет зависеть от конкретной архитектуры модели системы, то есть, у меня нет абстрактных универсальных хэлперов, которые рулят количеством рутовых нод (так как подобное может только негативно повлиять на скорость работы), а руты выбираются руками и заносятся конфиги, далее, всё зависит от абстракции уровня данных - это могут быть датамапперы с некоторой поддержкой ОРМ для всего конкретного дерева, начинающегося с этой корневой ноды, их совокупность (когда нужно осуществить многие ко многим или аналоги) или просто врапперы, типа актив-тэйбл, но только с поддержкой методов по работе с сабжем.
В общем - использую несколько корневых нод в целях оптимизации, когда такой подход будет оправдан с точки зрения требований к конкретному сайту.
зы: ну а лэйвл использую всегда, и разумеется ключи по всему ) Там, где можно выкрутиться без лэйвла при использовании nested sets (приемлемая производительность при пересчётах индексов нод, отсутствие необходимости выгребать предка предка 2й с боку ноды, которая сестринская по отношению к заданной ;) и т.д.) надобность в нестед сетс, имхо, отпадает, достаточно просто parent, child, level
угу, я не однозначно написал - на лету, здесь имелось ввиду, что при записи страницы для последующего анализа, а обычно, когда рисуем регулярки к чему-либо, то именно так и поступаем (я не имею ввиду гугла, а любой ресурс, копаться в котором нам было бы удобнее при помощи какого-либо редактора, например дримвивера).
То, что все пути на ресурсы (картинки, стили и т.д.) будут преобразованы в относительные - это и так понятно, но кроме того, браузер попытается исправить код (предположительно в соответствии с !DOCTYPE этого файла), например, возмёт значения всех атрибутов тэгов в кавычки (где их нет), а одинарные заменит на двойные. Этого уже достаточно, что бы неправильно работали паттерны для вытягивания урлов из <a href
Если у ТСа возникла проблема со включёным яваскриптом, то предположил, что такая особенность ему будет полезна.
Почему имено кУРЛ (или тот движок, который используем в парсере) - так сразу проверяется и сам транспорт, например, тот же редирект по ГЕО или языку, который браузер делает неявно, но в случае рукописи, это нужно учитывать.
Кроме того, некоторые сайты форсируют дефолтовый charset, и есть барузеры, которые руковотствуются именно значением из http-ответа, а не значением charset из <meta...> например, ИЕ 8 отрендерит страницу, в соответствии с charset, когда же ФФ возмёт значение из http-ответа.
Так вот, если писать регулярки, привязываясь к набору символов в своей локали (что в принципе не правильно, но есть лэйауты, где привязаться проще к какой-нибудь конкретной текстовой строке), на основе того, что видим после обработки браузером, рега тоже может быть неправильной, так как мы не знаем, в какой именно кодировке нам дадут страницу.
В общем, составлять паттерны для набора правил парсинга, имхо, удобнее при анализе страницы, которую мы получаем используемым транспортом.
1. это уже не ВП )) и так же, если выводимый текст будет меняться, то это уже не статика... чего хотите достигнуть в конечном итоге, может какой-нить плагин будет более идеологически верным решением? )
2. редактировать шаблон текущей темы
DmitryShustov, совет на будущее - когда вы пишите паттерны для парсинга чего-то, составляйте их на основе исходника вытянутого тем же методом, который используется в вашей парселке/граббилки. В вашем случае это скорее-всего PHP с cURLом, вот просто курлом и вытягивайте, разумеется, в курле нужно разрешить 2-3 редиректа (гугле может редирекнуть на более подходящий для вашей локации домен).
Когда вы тяните браузером, а потом по этому исходнику пишите регу, в большенстве случаев рега будет неправильная, так как браузеры имеют такую привычку валидировать налету исходник, и показывает вам уже изменённый хтмл код )
Блин, ТС, забей на онлайн, вот тебе актуальная тема, лови
