А как скоро ожидается переход на парсер от Quadr0?

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

Цитата(navykeds @  25.7.2006,  19:27 )

А как скоро ожидается переход на парсер от Quadr0?

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

Цитата(navykeds @  25.7.2006,  19:27 )

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

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

Цитата(navykeds @  25.7.2006,  19:27 )

А как скоро ожидается переход на парсер от Quadr0?

Цитата(navykeds @  25.7.2006,  19:27 )

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

Цитата(Vitalik @ 26.7.2006,  17:38)

Цитата(navykeds @  25.7.2006,  19:27 ) P.S: и чем не устраивал делфийский? Во-первых, многие нарекают на его "медленность" Во-вторых, в Delphi 5 и C++ Builder 5 его нет и в помине, а в C++ Builder 6 мне его подключить нормально не удалось..

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

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

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

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

Цитата(Vitalik @ 26.7.2006,  17:38)

Цитата(navykeds @  25.7.2006,  19:27 ) P.S: и чем не устраивал делфийский? Во-первых, многие нарекают на его "медленность" Во-вторых, в Delphi 5 и C++ Builder 5 его нет и в помине, а в C++ Builder 6 мне его подключить нормально не удалось..

Цитата(navykeds @  25.7.2006,  19:27 )

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

Цитата(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,  20:10 )

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

Цитата(navykeds @  26.7.2006,  20:10 )

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

Цитата(navykeds @  26.7.2006,  20:10 )

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

Цитата(navykeds @  26.7.2006,  20:10 )

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

Цитата(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 при исправлении каких-то ошибок или при добавлении новых возможностей или еще при каких-нибудь таких событиях..

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

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

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

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

Это сообщение отредактировал(а) navykeds - 26.7.2006, 23:56

Цитата(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,  20:10 )

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

Цитата(navykeds @  26.7.2006,  20:10 )

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

Цитата(navykeds @  26.7.2006,  20:10 )

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

Цитата(navykeds @  26.7.2006,  20:10 )

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

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 11:47

Цитата(navykeds @  26.7.2006,  20:10 )

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

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

Цитата(navykeds @  26.7.2006,  20:10 )

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

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

Цитата(navykeds @  26.7.2006,  20:10 )

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

Цитата(navykeds @  26.7.2006,  20:10 )

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

Цитата(Quadr0 @  28.7.2006,  13:28 )

Дельфийский (правильно сказать от Microsoft) вполне устраивал. Его можно оставить. Но ради создания кросплатформенности, к которой мы также стремимся, пришлось сделать свой, тоже очень хороший.

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

Цитата(Vitalik @  28.7.2006,  13:52 )

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

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

Цитата(Vitalik @  28.7.2006,  13:52 )

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

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

Цитата(Quadr0 @  28.7.2006,  13:28 )

Дельфийский (правильно сказать от Microsoft) вполне устраивал. Его можно оставить. Но ради создания кросплатформенности, к которой мы также стремимся, пришлось сделать свой, тоже очень хороший.

Цитата(Vitalik @  28.7.2006,  13:52 )

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

Цитата(Vitalik @  28.7.2006,  13:52 )

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

Цитата(navykeds @  28.7.2006,  14:18 )

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

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

Цитата(navykeds @  28.7.2006,  14:18 )

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

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

Цитата(navykeds @  28.7.2006,  14:18 )

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

Цитата(navykeds @  28.7.2006,  14:18 )

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

Цитата(Vitalik @  28.7.2006,  17:17 )

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

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

Цитата(Vitalik @  28.7.2006,  17:17 )

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

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

Цитата(Vitalik @  28.7.2006,  17:17 )

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

Цитата(Vitalik @  28.7.2006,  17:17 )

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

Цитата(navykeds @  28.7.2006,  17:34 )

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

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

Цитата(navykeds @  28.7.2006,  17:34 )

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

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

Цитата(navykeds @  28.7.2006,  17:34 )

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

Цитата(navykeds @  28.7.2006,  17:34 )

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

Цитата(Vitalik @  26.7.2006,  21:05 )

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

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

Ниже расскажу идею..
Есть файл 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.

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

Цитата(Vitalik @  26.7.2006,  21:05 )

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

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

Цитата(Sep. @  2.8.2006,  13:42 )

А не реально устроить сравнительное тестирование парсеров? =)

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

Цитата(Sep. @  2.8.2006,  13:42 )

(Хотя в лидере никто не сомневается =))

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

Цитата(Sep. @  2.8.2006,  13:42 )

А не реально устроить сравнительное тестирование парсеров? =)

Цитата(Sep. @  2.8.2006,  13:42 )

(Хотя в лидере никто не сомневается =))