| dtsarapkin | Дата: Суббота, 26.08.2017, 17:24 | Сообщение # 1 |
|
Сержант
Группа: Проверенные
Сообщений: 35
Репутация: 18
Статус: Оффлайн
| Я занимаюсь переносом парсера GoldParser на 1С. Делал по исходным кодам (http://devtool1c.ucoz.ru/load/prochie/gold_parser_engine_net_iskhodniki/2-1-0-11).
Идея такая: иметь универсальный парсер, написанный на 1С. При этом, чтобы его программный интерфейс совпадал с GoldParser.
Это нужно для ИР? Чтобы, например, можно было использовать 1С-ный в тех случаях, когда компоненту не удается использовать.
Сейчас уже реализована первоначальная версия. Парсер успешно грузит грамматику и успешно и правильно проводит разбор (по крайней мере на моих экспериментах).
Пока нет некоторых реквизитов у классов - в особенности тех, которые в .Net получались динамически, при обращении. Позже добавлю.
Недостатки:
Он медленный. Работает достаточно долго, причем если подключена отладка, то совсем долго. Ещё есть возможности по ускорению, но он все равно будет сильно медленнее чем компонента.
Работает не на всех платформах. Используются ЧтениеТекста, ЧтениеДанных, например. Пока не изучал этот вопрос - начиная с какой платформы успешно работает. Но, думаю, можно будет дописать вариант и для более старых версий.
Основная проблема: нет возможности на 1С сделать такой же интерфейс, как и у Net-овской компоненты. У меня классы реализованы через Структуры/массивы и к ним нельзя приписать никакие методы.
Соответственно, получать данные так, как они получались из компоненты не удастся.
Например: Парсер.CurrentReduction.Tokens(0) - в моем случае приходится делать например так: Парсер.Tokens(Парсер.CurrentReduction, 0).
Такая вот эмуляция работы с классами)
Сейчас получается, чтобы сделать 2 работающих парсера, то придется дублировать процедуры/функции.
Если такой парсер на 1С нужен, то предлагаю переписать текущие обращения к парсеру-компоненте, чтобы можно было подсунуть туда парсер на 1С. Возможно, нужно будет немного изменить код самого .Net-овского парсера, чтобы изменить его интерфейсы на более процедурную модель. Тогда код обращения будет универсальным для обоих парсеров.
Но, основной вопрос: это все вообще нужно?)
p.s.: Сам парсер прикладываю. Также прикладываю обработку, которой его сравнивал с компонентой - там нужно будет путь в коде прописать.
|
| |
| |
| tormozit | Дата: Воскресенье, 27.08.2017, 23:41 | Сообщение # 2 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 6178
Репутация: 156
Статус: Оффлайн
| Пока не вижу применения такого функционала, т.к. скорость его работы не даст ему выйти за пределы академического интереса.
|
| |
| |
