Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > SynUniHighlighter и SynEdit > Вопросы и предложения по xml-парсеру для компонента


Автор: navykeds 25.7.2006, 20:27
А как скоро ожидается переход на парсер от Quadr0?

P.S: и чем не устраивал делфийский? smile 

Автор: Vitalik 26.7.2006, 17:38
Цитата(navykeds @  25.7.2006,  19:27 Найти цитируемый пост)
А как скоро ожидается переход на парсер от Quadr0?

Как только я или Quadr0 реализуем возможность считывания всяких там &qt; и 
 smile

Цитата(navykeds @  25.7.2006,  19:27 Найти цитируемый пост)
P.S: и чем не устраивал делфийский?

Во-первых, многие нарекают на его "медленность"
Во-вторых, в Delphi 5 и C++ Builder 5 его нет и в помине, а в C++ Builder 6 мне его подключить нормально не удалось.. smile 

Автор: navykeds 26.7.2006, 21:10
Цитата(Vitalik @ 26.7.2006,  17:38)
Цитата(navykeds @  25.7.2006,  19:27 Найти цитируемый пост)
P.S: и чем не устраивал делфийский?

Во-первых, многие нарекают на его "медленность"
Во-вторых, в Delphi 5 и C++ Builder 5 его нет и в помине, а в C++ Builder 6 мне его подключить нормально не удалось.. smile

Ну медленность, в данном случае, понятие субъективное. С переходом на SimpleXML какого-либо прироста скорости я не увидел. 

По-поводу C++ Bulder 5/6 и Delphi 5: с таким же успехом можно пытаться прикручивать поддержку Delphi 1 smile D6/7 от D5 коренным образом не отличается.

Вытекающее из всего этого: действительно ли так нужен собственный парсер, если есть уже готовый, оттестированный, с документацией и т.д. и т.п.?

Дабы пояснить, почему возник сей вопрос: дело в том, что лично я уже использую делфийский парсер (со времен когда компонент работал именно с ним), под него написана значительная часть кода и переделывать все заново было бы весьма утомительно, а главное безцельно. Возможно, имеет смысл сделать поддержку встроенного парсера и по необходимости переключаться на него директивой?
 

Автор: Vitalik 26.7.2006, 22:05
Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
Ну медленность, в данном случае, понятие субъективное. С переходом на SimpleXML какого-либо прироста скорости я не увидел.

По поводу не-"медлительности" стандартного парсера я частично с тобой согласен и поэтому мы его использовали в UniHighlighter 2.0a..

Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
По-поводу C++ Bulder 5/6 и Delphi 5: с таким же успехом можно пытаться прикручивать поддержку Delphi 1  D6/7 от D5 коренным образом не отличается.

Но для компонента было бы полезно поддерживать не только Delphi 6 и Delphi 7, но еще хотя бы Delphi 5. Плюс также как у тебя симпатия к этому парсеру, у некоторых, к сожалению, антипатия.

Поэтому ответ на вопрос
Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
действительно ли так нужен собственный парсер, если есть уже готовый, оттестированный, с документацией и т.д. и т.п.?
такой: "альтернативный парсер действительно нужен..."

А вот на счет этого:
Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
Возможно, имеет смысл сделать поддержку встроенного парсера и по необходимости переключаться на него директивой?
Я с тобой полностью согласен и скоро я это обязательно сделаю..

Вот только пока не решил как лучше это реализовать. Пока что вижу два варианта:
1). Остановиться на достигнутом и просто сделать дублирующие файлы SynUniFormatNativeXml*.pas, которые будут написаны для нужных xml-парсеров. Для того чтобы использовать другой парсер нужно будет просто заменить эти файлы на альтернативные.
2). Сделать как-нибудь возможность использования в файлах SynUniFormatNativeXml*.pas какого-нибудь абстрактного парсера, методы которого можно было бы обучать работе с нужным конкретным парсером. Такой подход избавил бы от не обходимости обновления всех файлов SynUniFormatNativeXml*.pas при исправлении каких-то ошибок или при добавлении новых возможностей или еще при каких-нибудь таких событиях.. 

Автор: navykeds 26.7.2006, 23:55
Цитата(Vitalik @ 26.7.2006,  22:05)
Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
Ну медленность, в данном случае, понятие субъективное. С переходом на SimpleXML какого-либо прироста скорости я не увидел.

По поводу не-"медлительности" стандартного парсера я частично с тобой согласен и поэтому мы его использовали в UniHighlighter 2.0a..

Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
По-поводу C++ Bulder 5/6 и Delphi 5: с таким же успехом можно пытаться прикручивать поддержку Delphi 1  D6/7 от D5 коренным образом не отличается.

Но для компонента было бы полезно поддерживать не только Delphi 6 и Delphi 7, но еще хотя бы Delphi 5. Плюс также как у тебя симпатия к этому парсеру, у некоторых, к сожалению, антипатия.

Поэтому ответ на вопрос
Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
действительно ли так нужен собственный парсер, если есть уже готовый, оттестированный, с документацией и т.д. и т.п.?
такой: "альтернативный парсер действительно нужен..."

А вот на счет этого:
Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
Возможно, имеет смысл сделать поддержку встроенного парсера и по необходимости переключаться на него директивой?
Я с тобой полностью согласен и скоро я это обязательно сделаю..

Вот только пока не решил как лучше это реализовать. Пока что вижу два варианта:
1). Остановиться на достигнутом и просто сделать дублирующие файлы SynUniFormatNativeXml*.pas, которые будут написаны для нужных xml-парсеров. Для того чтобы использовать другой парсер нужно будет просто заменить эти файлы на альтернативные.
2). Сделать как-нибудь возможность использования в файлах SynUniFormatNativeXml*.pas какого-нибудь абстрактного парсера, методы которого можно было бы обучать работе с нужным конкретным парсером. Такой подход избавил бы от не обходимости обновления всех файлов SynUniFormatNativeXml*.pas при исправлении каких-то ошибок или при добавлении новых возможностей или еще при каких-нибудь таких событиях..

По-поводу поддержки разных сред: это я к тому, что поддерживать можно, иногда нужно и полезно, но это не должно мешать развитию компонента.

Насчет реализации поддержки обоих типов парсера: второй вариант, конечно, правильнее. Но тут уже решать тебе, желательно принимая в расчет время работы над разными вариантами smile

Впрочем, лично мне, заменить несколько файлов не сложно. Совершенно.

P.S: как же тут быстро цитировать отдельные куски сообщения?  

Автор: Quadr0 28.7.2006, 13:28
...

Автор: Vitalik 28.7.2006, 13:52
Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
лично я уже использую делфийский парсер (со времен когда компонент работал именно с ним), под него написана значительная часть кода и переделывать все заново было бы весьма утомительно, а главное безцельно.

А что это за часть кода, если не секрет? smile
Расскажешь подробнее?

Цитата(navykeds @  26.7.2006,  20:10 Найти цитируемый пост)
P.S: как же тут быстро цитировать отдельные куски сообщения?

Выделяешь текст в сообщении, а потом щелкаешь по кнопке-картинке "Быстрая цитата" сверху сообщения smile 

Автор: navykeds 28.7.2006, 15:18
Цитата(Quadr0 @  28.7.2006,  13:28 Найти цитируемый пост)
Дельфийский (правильно сказать от Microsoft) вполне устраивал. Его можно оставить.
Но ради создания кросплатформенности, к которой мы также стремимся, пришлось сделать свой, тоже очень хороший.


Да, свой нужен, не спорю. А если поддерживать оба, то будет совсем замечательно  smile


Цитата(Vitalik @  28.7.2006,  13:52 Найти цитируемый пост)
А что это за часть кода, если не секрет? 
Расскажешь подробнее?


Быстрая работа с файлами подсветки, считывание нужных значений.


Цитата(Vitalik @  28.7.2006,  13:52 Найти цитируемый пост)
Цитата(navykeds @  26.7.2006,  20:10 )
P.S: как же тут быстро цитировать отдельные куски сообщения?


Выделяешь текст в сообщении, а потом щелкаешь по кнопке-картинке "Быстрая цитата" сверху сообщения   


В IE работает, в Опере (9) не очень smile 

Автор: Vitalik 28.7.2006, 17:17
Цитата(navykeds @  28.7.2006,  14:18 Найти цитируемый пост)
Быстрая работа с файлами подсветки, считывание нужных значений.

Очень интересно smile
А примерчик кода не приведешь?.. Я думаю это было бы полезно smile

Цитата(navykeds @  28.7.2006,  14:18 Найти цитируемый пост)
В IE работает, в Опере (9) не очень

Я сам Оперой пользуюсь, и все прекрасно работает smile
А что оно тебе при этом говорит? 

Автор: navykeds 28.7.2006, 18:34
Цитата(Vitalik @  28.7.2006,  17:17 Найти цитируемый пост)
Очень интересно А примерчик кода не приведешь?.. Я думаю это было бы полезно 


Сожалею, нет smile  Чтобы понять как это работает, нужно привести в качестве примерчика пару модулей, а они будут полезны не только тебе — конкуренция..


Цитата(Vitalik @  28.7.2006,  17:17 Найти цитируемый пост)
Я сам Оперой пользуюсь, и все прекрасно работает А что оно тебе при этом говорит? 


Иногда говорит, что я воспользовался кнопкой цитирования другого участника. Сейчас под Оперой, раза с третьего цитату вставило. 

Автор: Vitalik 28.7.2006, 21:20
Цитата(navykeds @  28.7.2006,  17:34 Найти цитируемый пост)
Чтобы понять как это работает, нужно привести в качестве примерчика пару модулей, а они будут полезны не только тебе — конкуренция..

Может тогда на мыло? Если не жалко smile
А что ты там такое разрабатывашь? Ссылочкой не поделишься? smile

Цитата(navykeds @  28.7.2006,  17:34 Найти цитируемый пост)
Иногда говорит, что я воспользовался кнопкой цитирования другого участника.

Ну эт правильно smile
Просто нужно жать именно на ту кнопку "Быстрая цитата", которая соответствуюет выделенному сообщению (находится сверху от него) smile
 

Автор: Vitalik 1.8.2006, 15:46
Цитата(Vitalik @  26.7.2006,  21:05 Найти цитируемый пост)
2). Сделать как-нибудь возможность использования в файлах SynUniFormatNativeXml*.pas какого-нибудь абстрактного парсера, методы которого можно было бы обучать работе с нужным конкретным парсером. Такой подход избавил бы от не обходимости обновления всех файлов SynUniFormatNativeXml*.pas при исправлении каких-то ошибок или при добавлении новых возможностей или еще при каких-нибудь таких событиях.. 

УРА!
Наконец-то реализовал эту возможность! smile

Ниже расскажу идею..
Есть файл SynUniXmlParserInterface.pas содержащий классы для "абстрактного" xml-парсера. 
Файл SynUniXmlParser.pas содержит классы-наследники от "абстрактного" парсера и соответственно реализацию всех методов под нужный парсер.
Если нужно использовать нестандартный xml-парсер, то нужно написать свой файлик SynUniXmlParser.pas и перекрыть нужные методы "абстрактного" парсера из SynUniXmlParserInterface.pas.

Были разработаны файлы SynUniXmlParser.pas для стандартного делфийского xml-парсера, для xml-парсера SimpleXml и для xml-парсера от Quadr0
Файлы называются соответственно:
SynUniXmlParser_XmlDocument.pas,
SynUniXmlParser_SimpleXml.pas,
SynUniXmlParser_YZXmlParser.pas
Чтобы использовать нужный xml-парсер надо просто переименовать соответствующий файл в SynUniXmlParser.pas.

Так пойдет или лучше реализовать как-нить покрасивее? smile

Автор: Sep. 2.8.2006, 14:42
А не реально устроить сравнительное тестирование парсеров? =) И самый быстрый пусть по умолчанию уже будет переименованный.
(Хотя в лидере никто не сомневается =))

Автор: Vitalik 4.8.2006, 16:23
Цитата(Sep. @  2.8.2006,  13:42 Найти цитируемый пост)
А не реально устроить сравнительное тестирование парсеров? =)

Ага, надо будет сообразить smile

Цитата(Sep. @  2.8.2006,  13:42 Найти цитируемый пост)
(Хотя в лидере никто не сомневается =))

В каком смысле? smile

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)