Є така собі проблемка. Аналітичний сайт. Статті. Глосарій. Є потреба виділяти слова з глосарію в статтях у вигляді посилань на той же глосарій. Тобто, виводиться стаття, є слово, що міститься в глосарію - воно перетворюється на посилання.
Так от, щодо реалізації. Добре, якщо глосарій маленький. Тоді при виводі скрипт прокрутить саттю по всіх ключових словах, автоматично виділивши потрібні, вірніше, перетворивши їх на посилання. А якщо глосарій розростеться? Прокручувати заміну слів статті одноразово, перед публікуванням - тоді не враховується поповнення глосарію.
Може хтось підкаже якийсь вихід, що і враховуватиме поповнення глосарію, і не з`їдатиме ресурси сервера та не гальмуватиме вивід статей?
по крону з потрібною частотою (наскільки швидко розростається глосарій, я не знаю). Або - складніше, але інтелігентніше - організуй нотифікації. Коли хтось поповнює глосарій, хай скрипт кидає в якусь спецтабличку запис-команду на перекомпіляцію статей. По крону (більш-менш часто) працює інший скрипт, який, як тільки бачить нову нотифікацію, перекомпілює статті і стирає цей запис. Віддалено схожим чином працює підписка на оголошення на autoua.biz.
ХМЛ/ХСЛ перетворення мали б тебе порятувати: глосарій робиш у вигляді хмля і перед показом сторінки перетворюєш її
не вижу особой проблемы.
нужно будет только несколько скриптов - 1. первичное выделение 2. обработка при добавлении в глоссарий (палюбу старые статьи нужно будет шерстить) 3. обработка при добавлении статьи
пункты 1 и 3 вроде похожи. можт, можно обойтись один скриптом.
АХТУНГ!!! не бойся проверять каждое слово статьи на вхождение в глоссарий! только сделай так - грузишь глоссарий в ХЕШ и тогда 1. разбиваешь статью на слова 2. пословно проверяешь, есть ли в хеше ключ, совпадающий с твоим словом 3. и т.д.
поиск в хеше обычно работает достаточно шустро.
Так от, щодо реалізації. Добре, якщо глосарій маленький. Тоді при виводі скрипт прокрутить саттю по всіх ключових словах, автоматично виділивши потрібні, вірніше, перетворивши їх на посилання. А якщо глосарій розростеться?
Правильно. Так не робиться. Вивід статті треба максимально прискорити.
Прокручувати заміну слів статті одноразово, перед публікуванням - тоді не враховується поповнення глосарію.
Не розумію, чому цей варіант не підходить. Саме так і треба робити, тільки з доповненням - стосовно поповнення словника.
Отже, 1) при підготовці статті - автоматично проганяти скриптом по існуючому словнику; 2) при внесенні змін (доповнень) до словника - повторити 1) для всіх статей.
Якщо словник змінюється часто, винести прогонку 2) в окремий процес під управлінням редактора - хай сам визначає необхідну частоту прогонки.
Крон підходить тоді, коли якщо точність і оперативність не постраждають (не потрібні). Якщо сервер слабкуватий, то пункт 2) можна виконувати по крону наприклад двічі на добу - того буде досить.
Можна зробити багато чого, але без пункту 2) не обійтись .
зробити і забути. А наповнювати далі базу будуть випадкові люди, тому хочеться максимально автоматизувати. Ще раз дякую, буду щось думати
Отже, 1) при підготовці статті - автоматично проганяти скриптом по існуючому словнику; 2) при внесенні змін (доповнень) до словника - повторити 1) для всіх статей.
Тільки одна поправка по п.2 - проганяти старі статті не для всього глоссарію, а тільки для його змін - це буде значно швидче.
cron + diff + awk|perl|python|тощо = все що завгодно
Тільки одна поправка по п.2 - проганяти старі статті не для всього глоссарію, а тільки для його змін...
Відповісти
Поперед.
Зміст
Наступ.
Гілками
и тогда
