Requests for REGULAR flame
или
Особенности охоты на тагов
|
LAV#UNDEFINED
|
|
|
|
|
Эта рубрика открыта специально для шуток программистского юмора
и... э... АВТОМАТИЗАЦИИ ТРУДА АВТОРОВ (не обольщайтесь: только в части
подготовки текста к публикации).
|
Содержание
1. RFRF0: Предуведомления
Всем привет. Всем, кого достал "Дилетантский ХТМЛ ВРУЧНУЮ",
который, несмотря на надежность a la monster ZORG (If you wanna do something - do yourself) добивает рутиной (проще говоря,
ручная работа по бацанию "стандартных заклинаний черной магии" превращает
автора в... чернорабочего оформителя - сиречь, "дизайнера").
Думаю, всем нормальным людям (которым лениво делать одни и те же вещи
более двух раз), - особенно, далеким от программирования - будут небезынтересны
опыты с "автомагическим" добавлением тегов в изначальный голый текст... с последующей
возможностью их полного удаления. (Последняя задача не так уж факультативна,
как может показаться).
Меня самого очень давно (и просто ОЧЕНЬ) убивает оформительская рутина и,
понятно, ОЧЕНЬ интересуют средства, так сказать, публикации. Не абы какие
и уж конечно не монстры вроде "закрытого" софта, который, возможно, делает
нужные вещи и быстро... но неизвестным мне способом и... зависимым от произвола
разработчиков. Хотя бы в смысле формата документов.
ХТМЛ же универсален (из поддерживаемых, понятно, на СИ форматов: тот
же текст, только с "магическими последовательностями" - стартстопными).
Ясное дело: нужен потоковый редактор, простой, как грабли и самодостаточный
(не достающий пользователя).
Рассматривались разные варианты.
Cразу на ум приходят макросы ворда. Но они
мне быстро наскучили и возникли всякие "но" - ставить офис на машину за ради
обыкновенного ХТМЛа? а не углючит потом удалять лишние теги из конечных
файлов?
"Свободный софт"... Да-да: POSIX-среды типа Линуха, Sygwin и т.п.
"Встроенные" языки скриптов и прочие вкусности, которых ценят понимающие
в них люди... awk, sed и иже с ними - оно меня, допустим, не напрягает...
Но всякие вопросы "совместимости по возврату каретки" НАПРЯГАЮТ ОДНОЗНАЧНО.
Даже думать о них напряжно. ОДНОЗНАЧНЫЙ ЖЕ ФАКТ: большинство доступных в полевых условиях
компов - клятый Windows.
В котором есть такая (с позволения сказать... при дамах) штука, как Scripting Host:
"Поддержка скриптовых языков от Билли Г." Ну, а BASIC (пусть и Visual) -
это как автоматический рвотный рефлекс: врожденный программистский ответ на
неадекватность условий обучения компьютерной грамотности. (К тому же,
поддерживает регулярные выражения... Как мне их нехватало под Виндой - вы
себе не представляете. (В POSIX-средах от них просто некуда деться.)
Традиционный FAQ: "Регулярные выражения, говоришь... Че, типа, за звери?"
Ну, понятно, во-первых, не те регулярные выражения, которые
сопровождают работу под Виндой. На самом деле примерно так: объясняете задачу
шайтану WSH на понятном ему наречии (VBS... хотя можно и на JavaScript) -
"Хочу... это... Ну, ты меня понял?" И во все абзацах, по единому образцу, то есть
маске, волшебным образом возникают нужные нам "стартстопные
последовательности" - теги ХТМЛ, которые объясняют браузеру, как
надо показывать ваш текст). Чем черт не шутит?
Результатом этих п(р)оисков и душевных метаний стали два скрипта:
makehtml2.vbs
striphtml2.vbs
которые:
а) решают поставленные задачи простым способом и
б) работают на. (В смысле, на почти любой доступной в полевых условиях -
в т.ч. "И-нет кафе", машине, несущей на челе печать диавола "Designed for
Windows XXX")
Этот док будет пополняться,
по мере принятия мер. А теперь можете задавать вопросы.
2. RFRF1: Автомагические издержки
Прошу учесть: автоматика - палка с концами. Кто хочет
использовать ее, платит всегда - обычно, снижением гибкости. В нашем случае -
заливка в ХТМЛ будет производиться "по образу и подобию" использованной
ХТМЛ-болванки и правил заливки (на саом деле правила эти определяются
регвыражениями... Программисты, понятно, разберутся, как их сделать гибкими,
не переписывая каждый раз скрипты. А гуманитариям заплатить придется... Хотя бы
за пиво для знакомых программистов). Все остальное вам по-прежнему останется
настраивать ручками и дорабатывать напильником.
Второй конец палки: как сказал Н. Винер, а Н. Виндж - перефразировал, основная
проблема с автоматикой в том, что получаешь не то, чего хотел, а то, ЧЕГО
ПОПРОСИЛ. Так что, делайте выводы сами.
Для использования скрипта по назначению можно скопировать его текст
из соответствующего документа в файл с именем проги (например makehtml2.vbs) и
следовать правилам заливки.
АЛАРМА: Обнаружены след. "жюки", влияющие на результативность работы striphtml2.vbs
(см. "Жнец против клана тагов"):
[BUG1]: если внутри тега содержится перевод строки,
то этот тэг из исходного ХТМЛ-файла удален не будет. Возможные причины:
- документ был сохранен средствами Internet Explorer (иногда он перефигачивает
длинные теги в несколько строк, по не вполне понятным причинам:
длина тега не превышает размеры текстового экрана и такое принудительное
выравнивание только добавляет работы по его устранению);
- в файлах head, подготовленных описанным в
правилах заливки
способом, содержатся теги с переводом строки.
Устранение: убедитесь, что в исходном файле ХТМЛ-болванки нет тегов,
содержащих перевод строки. Тогда по крайней мере корректно будет
обрабатываться результат сборки опуса скриптом makehtml2.vbs Вообще,
издержки "готового ХТМЛ-файла" - куча левых тегов, которые многие генераторы
ХТМЛа (тот же ворд) добавлют "на всякий случай" (эксплицитно, как плейсхолдеры).
[BUG2]: некоторые теги часто используются как атомы, т.е. могут не иметь
параметров, но допускают их как опции (т.е. у них есть значения по умолчанию,
которые при сильном желании наивный хтмлщик может изменить).
"Тотально убийственное" регвыражение в скрипте striphtml2 не учитывает этого,
хотя пофиксить проще простого ;D Как говорится, "исправлено в следующей версии".
Кстати, стандартный декор блога (а СИ по своей структуре - типичный блог ПРОСТО, ЧТОБ ВЫ ЗНАЛИ)
скрипт striphtml2 пока не
удаляет. Для извлечения текста опуса можно копировать содержимое текстового
окна, которое появляется при редактировании документа средствами СИ, но
ручками это делать каждый раз лениво. Проще ведь качнуть на винт файл по ссылке -
"одним кликом выпадающего меню". Но вот беда: это будет малопонятный
большинству гуманитариев shtml, сгенерированный CGI-сервером (а СИ - типичный
CGI-сервер... ПРОСТО, ЧТОБ ВАМ ВНУШАЛО) по запросу браузера,
а вовсе не то, что заливалось на Самиздат...
Обработка shtml-файлов генерируемых CGIем тоже
просто автоматизируется: достаточно внутрь ХТМЛ-опуса ввести стартстопные метки
для нашего жнеца тагов
(или дописать скрипт-оболочку, которая будет их
учитывать) и он будет просто обрезать "заголовок" и "подвал"
блога, чтоб на выходе получался исходный файл - то самое, что автор залил на
СИ: без всякого служебного мусора типа кнопок, оценок и т.п. (Видится что-то такое
на основе тегов <a name ... > На подходе).
Всех заинтересованных, просьба "флеймить" сюда.
(Э-э-э! Я имел в виду "делать конструктивные предложения"!)
П.С.Типа новость: проходит тестирование версия makehtml3.1
Добавлена возможность вставки иллюстраций, исправлены некоторые глюки
регвыражений. COMING SOON ;P
Результат работы - Время смерти
3. RFRF2: Анонс версии 3.2(a)
В предыдущем RFRF заявлено начало работ над версией 3.1, но по ходу ее
написания появилась пара попутных идей, так что данный "релиз" получил
сразу индекс 3.2
В текущей стабильной "альфе" вы найдете:
+ все фишки версии 3.1-
+ автометки заголовка и подвала СИ-шного блога (А)
+ поддержку внешних наборов правил заливки (Б)
А. Автометки нужны для скрипта strip_shtml, который корректно вырезает из
СИ-шного представления страницы тот ХТМЛ, который вы заливали на сайт
(см. RFRF1) (Опубликуем, если кому понадобится)
Б. Внешние правила подключаются в виде текстового файла с расширением .cf
Все манипуляции над текстом задаются строками вида:
{правило}маска
Здесь "маска" - регулярное выражение для поиска в исходном тексте, а
"правило" - конечный вид текста после применения правила к исходной строке.
Внутри элемента "правило" возможны следующие метаподставновки:
_match_ - вставить в конечную строку текст совпадающий с маской
_smpl_ - вставить в конечную строку текст самой маски
_i_str_ - вставить в конечную строку текст исходной строки
Текущая версия также позволяет указывать символы разделителей в виде
цифровых кодов с префиксом #:
#32 - пробел
#13 - Enter
#9 - Tab
Примеры:
{}<p> - заменяет все теги <p> пустыми строками (1)
{<a href="/">_smpl_</a>}СИ - все вхождения строки "СИ"
преобразуются в гиперссылку (2)
{<DD>}^#32.* - все лидирующие пробелы заменяются тегом <DD> (3)
{&}& - все амперсанды заменяются ХТМЛ-ным обозначением (4)
{<}< - то же для всех все знаков "меньше" (5)
{>}> - и для всех "больше" (6)
При этом следует учитывать, что скрипт чувствителен к порядку правил:
при заливке текста в ХТМЛ правила из примеров 4-6 должны находиться в головной
части списка (чтоб замаскировать все честные амперсанды и знаки сравнения -
иначе они будут интерпретироваться браузером по своему).
Аналогично, при уборке тегов из ХТМЛ-текста следует поместить правила вида
{&}&
{<}<
{>}>
в конец файла правил.
Комментарий в тексте файла правил можно поместить, указав в начале строки
последовательность символов _rem_:
_rem_ Это комментарий
Внешние наборы правил позволяют "похерить" встроенный обработчик регулярных
выражений - уйти от эксплицитной разметки "табами" и прочего "наследия темного
прошлого", а также - создавать наборы правил для обработки различных типов
текстов. Единственный минус. пожалуй, в том, что встроенные правила работают
быстрее.
Скрипт стабильно работает с наборами правил применяемыми автором
для верстки (в частности, если кто помнит, на первых трех главах романа
"Время смерти" обкатывались еще тестовые версии 3.1 (RFRF1), но уже "десять
глав тому" строчка внизу имеет индекс "3.2a").
[BUG3(FIXED)]: В последней версии исправлена неточность, связанная с интерпретацией
пробелов. Internet Explorer трактует все символы табуляции по своему, поэтому,
при попытке залить в ХТМЛ текст программы makehtml c помощью нее самой
изменялась семантика некоторых регулярных выражений - при копировании в буфер
содержимого окна Explorer с загруженным текстом программы, сверстанным в ХТМЛ,
все "табы" заменялись пробелами, поэтому сохраненный из буфера скрипт начинал
"валять дурака" на отработанных наборах правил. Теперь шаблоны регвыражений,
зависящие от символов табуляции защищены от подобной интерпретации.
[BUG4]: Опять связан с попытками применить программу к ней самой: маски
подстановок, допустимые в наборах правил, приводят к лаже в сверстанной странице,
так как программа не проверяет входной текст на наличие "специальных
последовательностей". (Подстановка _i_str_ вызывает дублирование строк. Пока
правится "ручками" в сверстанной странице.)
В плане:
- инкрементная верстка (тестируется фоновая версия)
- поддержка интерактивного "веб-интерфейса" (тестируется локальный вариант)
- версия скрипта для JavaScript (тестируется фоновая, с инкрементной версткой)
- консольный ввод-вывод для пакетного режима скрипта (пока только идея)
- грамотные хелпы и "ФАКи" (вопросов пока не поступало ;)))))))))))))))
- компоновщик поставки (пока юзаются всякие самописные генераторы скриптов)
4. RFRF3: Расшифровка кода версии, текущие ветви разработки
Код версии представляет собой условную номенклатиуру вида:
MajorNum.MinorNum[[(ParentNode[PatchNum])][Branch][(PatchName)]]
Здесь "MajorNum" - основной код версии
"MinorNum" - номер "ревизии" кода
Внешние квадратные скобки указывают необязательную информацию о сборке.
Внутри допустимы следующие идентификаторы:
"ParentNode" - "ядро" кода, на котором основана данная сборка
(буквенное обозначение стадии разработки). Значения:
"a" - alpha - рабочая версия (для "камикадзе");
"b" - beta - стадия обкатки на желающих;
"rc" - release candidate - подготовка поставки;
"imago" - стадия поставки.
"PatchNum" - номер обновления "ядра". (В дальнейшем предполагается
использовать для распространения обновлений в виде заплат к предыдущим
версиям.)
"Branch" - ветвь разработки (используется для отладки новых "примочек").
"(PatchName)" - условное имя обновления (используется разработчиком для
внутренних нужд проекта - только в отладочных версиях).
Текущий индекс версии "3.2a1". В настоящее время доступны следующие ветви:
3.2a1 - неинтерактивная (фоновая) версия скрипта.
Для моих нужд ее пока достаточно: в совокупности с менеджером
файлов "FAR", позволяет даже контролировать, как идет процесс заливки текста в
ХТМЛ - достаточно сразу после запуска скрипта открыть на просмотр файл
результата и нажать комбинацию клавиш "Ctrl+End" (переход в конец файла) -
"Far" покажет все, что нужно:
И даже позволит выкинуть скрипт из списка
задач (комбинация "Ctrl+W"), если что-то пошло не так, не дожидаясь конца
обработки.
3.2(a1)incr - инкрементная верстка на основе фоновой.
Делает все то же, что и 3.2a1, но слегка оптимизирует процесс.
Уже иногда используется для добавления очередной главы к
роману "Время смерти". При этом можно не трогать текущую версию текста,
которая все равно хранится в кэше изменений - фактической обработке подвергается
только текст новой главы.
3.2(a1)gui - в данной версии поддержан интерактивный "вебинтерфейс"
в виде ХТМЛ-страницы с полями для ввода текста.
Здесь будут всякие "выборы по умолчанию" и прочие "массажеры для пупка": в частности, не придется
париться с файлами описаний проекта. Скрипт сам подготавливает файл spec на
основе заполненных пользователем полей формы, и в дальнейшем по
умолчанию использует запомненные значения (на самом деле
файл генерируется каждый раз вновь - если что-то изменилось,
изменения сразу вступят в силу). Скрипт
заботится о том, чтобы интерфейсная форма была "актуальной" на
момент запуска: все обнаруженные файлы наборов правил
собираются в выпадающий список, в котором пользователь может однократно
назначить набор правил "по умолчанию" - в дальнейшем будет использоваться он,
вплоть до указания использовать другой набор правил.
Предположительно,
именно эта ветвь в дальнейшем станет основной (после объединения с "incr").
По окончании обработки, скрипт автоматически открывает новое окно
браузера, куда загружается сверстанная страничка.
Идеология данной ветви предполагает, что вся "внутренняя кухня"
(то, что "под капотом") непрограммирующего пользователя (например,
СИ-шного автора с гуманитарным образованием) не касается. Для получения
базовых навыков ему достаточно будет ознакомиться с разделом справки "Быстрый
старт": дважды щелкнуть по ярлыку на рабочем столе,
заполнить поля формы и получить свой опус, сверстанный в ХТМЛ.
Однако, скрипт по-прежнему позволяет запуск в фоновом режиме (полностью
совместим с 3.2a1 по входным данным) - так оно привычнее, а порой быстрее.
Так что пиплы, относящие себя к "old-school & hard-trained" по-прежнему
могут извращаться в командной строке (именно для них запланирована
ветвь разработки "con" - с консольным выводом).
Пока дорабатывается дизайн формы: интеграция фоновых скриптов Windows
Scripting Host с формами ХТМЛ нетривиальная задача - внешне одни и те же
действия можно сделать разными способами.
Работа над ошибками в версии 3.2
[BUG4(FIXED)]: Исправлена ошибка интерпретации подстановки "_i_str_"
Теперь скрипт корректно обрабатывает собственный исходник: к примеру, сохранив
текст текущей версии, размещенной на СИ, в виде файла .vbs (методом
Copy-Paste из окна браузера) и запустив его на обработку
какого-либо текста, я получу результат, идентичный результату обработки
рабочей версией скрипта. Все исправления внесены в ветви разработки "incr" и
"gui".
|
|
|
Mar 24 - Aug 9/ Y2K+4, to be updated...
|
|
