Цитата(Fantasist @ 6.8.2005, 22:44)

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

Тоже вариант!

Вот только вопрос. В виде чего ты хочешь это сделать?

1. В ввиде отдельного юнита более и менее универсального парсера.
То есть загрузка произвольного, а не кокретного формата xml-файла, поддержка комментариев и т.п....
Это было бы действительно круто!

2. Втроенная в компонент загрузка конкретного формата xml-файла.
Это уже очень не хорошо, так как, к примеру, сейчас уже есть три формата наших файлов (v1.5 (~v1.0), v1.8, v2.0)...
И с каждым новым релизом при добавлении новых возможностей формат будет наращиваться.
Поэтому было бы очень удобно всё же использовать парсер из пункта 1.

Цитата(Fantasist @ 6.8.2005, 22:44)

пришлите или выложите мне пожалуйста примермы файлов для загрузки с наиболее разнообразными сложностями.

Для всех трёх/четырёх форматов выкладывать?..

...

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

Цитата(Vitalik @ 7.8.2005, 13:49)

1. В ввиде отдельного юнита более и менее универсального парсера. То есть загрузка произвольного, а не кокретного формата xml-файла, поддержка комментариев и т.п.... Это было бы действительно круто!

Именно так.

Цитата(Quadr0 @ 7.8.2005, 16:27)

Возьмём парсёр, написанный ещё Fantasist'ом и просто подправим его под наши нужды.

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

Вот только я и говорю, что нужно посмотреть что нужно поддерживать. Сейчас например не поддерживается тег CDATA. Я думаю, он нам и не понадобиться, но если есть что-то еще, то легко добавить. Главное знать, что нужно.

Цитата(Vitalik @ 7.8.2005, 13:49)

Для всех трёх/четырёх форматов выкладывать?..

Да чем больше тем лучше. Мне надо убедиться, что все необходимые возможности поддерживаются.

...

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

Цитата(Quadr0 @ 7.8.2005, 19:27)

Почему быстро взять и не сделать загрузку без всяких xml? Возьмём парсёр, написанный ещё Fantasist'ом и просто подправим его под наши нужды. Будет и скорость и совместимость полная. Я лично вообще не понял зачем был выполнен переход на xml парсёр.

Переход на xml-парсер был выполнен по причине не удобной работы с самописным парсером и отсутствия поддержки в нём некоторых возможностей стандартна xml.
Quadr0, а ты разве не по тем же причинам захотел перейти с TXmlParser на TXmlDocument, а?

Цитата(Quadr0 @ 7.8.2005, 19:27)

Формат файла всегда строгий, так почему просто не использовать самописный парсёр?

Ну какой же он всегда строгий? Ведь уже есть три разных формата файла
И с добавлением новых возможностей всё равно будут добавляться новые теги. Это что получается три/четыре отдельных парсера писать нужно было бы?

Цитата(Quadr0 @ 7.8.2005, 19:27)

С ним мы выигрываем по всем параметрам.

Как видишь - нет.

Цитата(Quadr0 @ 7.8.2005, 19:27)

Так что предлагаю эту тему закрыть и начать обсуждение по поводу создания нашего собственного парсёра, колдовать над которым, как я уже понял, собрался Fantasist.  Там мы сможем решить что требуется от парсёра.

Хорошо, обсуждение собственного парсера я выделяю в отдельную тему, а вот закрывать темы я думаю не стоит

Цитата(Fantasist @ 7.8.2005, 21:17)

Именно так.

Да! Это будет просто замечательно! ИМХО, "то что доктор прописал"
Таким образом можно будет этот парсер легко подстраивать под свои нужды.

Цитата(Fantasist @ 7.8.2005, 21:17)

Вот только я и говорю, что нужно посмотреть что нужно поддерживать. Сейчас например не поддерживается тег CDATA. Я думаю, он нам и не понадобиться, но если есть что-то еще, то легко добавить. Главное знать, что нужно.

Подробнее, пожалуйста, о каких возможностях ты говоришь?..
Пока что я вижу так. Нужно просто уметь:
1). считывать теги, атрибуты и содержимое тега;
2). теги и атрибуты могут располагаться как угодно и где угодно (то есть между ними произвольное количество пробелов/табов/энтеров);
3). игнорирование (пока что) комментариев. А потом может и считывание комментариев...
4). чтение директив <?xml version="1.0" encoding="win-1251"?> и считывание файла в нужной кодировке (думаю utf-8 был бы полезен, но это не так уж и обязательно...)
5). возможность сохранения xml-я в файл

Цитата(Fantasist @ 7.8.2005, 21:17)

Да чем больше тем лучше. Мне надо убедиться, что все необходимые возможности поддерживаются.

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

...

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

Цитата(Quadr0 @ 8.8.2005, 12:48)

А закой нам эти стандарты?

Чтобы у нас был полноценный xml файлик, который можно было бы прочитать в любой программе, которая умеет работать с xml!

Цитата(Quadr0 @ 8.8.2005, 12:48)

Я думал, что XML парсёр реально компоненту нужен. Именно XML. А сейчас вижу, что использование xml парсёра будет нерентабельно.

Поясняй свою мысль

Цитата(Quadr0 @ 8.8.2005, 12:48)

И по каким же нет?

Читай выше.

Цитата(Quadr0 @ 8.8.2005, 12:48)

Цитата(Vitalik @ 8.8.2005, 11:25) А потом может и считывание комментариев... Зачем?

А же написал: может

Цитата(Quadr0 @ 8.8.2005, 12:48)

Зачем разных, если нужно делать, основываясь на последнем? Прошлые форматы от текущего не особо отличались.

Затем, что прошлые форматы файлов тоже должны считываться нашим парсером, разве нет?
А если рассуждать как ты, то чем вообще наш новый файл отличается от обыкновенного xml-файла?

Вот, подготовил несколько файликов для примера...
Правильность не проверял, но вроде ошибок при создании не допустил.

Вот содержимое архива:

• Format 1.0.hgl - Самый первый вариант файла. Заметь, что там трабла с &qt;
• Format 1.5.hgl - Эта версия полностью совместима с 1.0, только добавляет новые теги для новых возможностей
• Format 1.8.hgl - Здесь уже формат файл а кардинально поменялся. Я думаю в лучшую сторону
• Format 2.0a.hgl, Format 2.0b.hgl - Это предварительные файлики новой версии 2.0
• Format X.hgl - А это вариант того, как можно теги и комментарии разбрасывать по файлу...

Присоединённый файл ( Кол-во скачиваний: 5 )
 Highlighters.samples.zip 5,97 Kb

...

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

Цитата(Quadr0 @ 9.8.2005, 01:04)

А это зачем? Подсветки не предназначены для xml редактора. Они предназначены для компонента SynUniHighlighter. Слышал о таком?

Цитата(Quadr0 @ 9.8.2005, 01:04)

Зачем нам гнаться за этой XML совместимостью? Кому она нужна, и что она нам даст?

Цитата(Quadr0 @ 9.8.2005, 01:04)

В файлах подсветки комментариев вроде нет (да и зачем они?).

Может я как-то непонятно изъясняюсь... Сейчас попробую пояснить свою мысль...
Но сначала, ты должен уяснить одну идею. Компонентом пользуемся не только мы и не только те, кто появляется на этом и другом форуме, но и еще большое количество людей со своими личными предпочтениями.
Теперь ближе к делу. Совместимость с xml-ем нужна, так как:
1). есть люди, которые не пользуются дизайнером, а предпочитают предоставлять пользователям своей программы менять файлы подсветки вручную. Благодаря этому файл подсветки может произвольно разбиваться пробелами и табами, а также может содержать поясняющие комментарии, описывающие назначение правил или элементов файла... И вот поэтому мы должны уметь считывать такие файлы. С этим согласен?
2). допустим, кто-нибудь захочет использовать другой парсер для считывания файлов подсветки. Если формат подсветки будет несовместим со стандартами xml, то у него ничего не получится. Также нужно, чтобы xml-ка просматривалась во всех просмотрщиках и редакторах xml-я. Например, хотя бы в том же Internet Explorer.

Цитата(Quadr0 @ 9.8.2005, 01:04)

Я уже говорил. Подсветки имеют строгий формат.

А я уже говорил, что этот формат не такой уж и строгий!
Уже есть ТРИ формата! И что для каждого формата свой парсер писать? Нерентабельно!
Плюс учитывай, что в будущем формат файла также может поменяться (никто не застрахован).

Цитата(Quadr0 @ 9.8.2005, 01:04)

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

- Скорость... А почему ты думаешь, что будет большое увеличение скорости? За счёт чего она может значительно увеличиться? Ведь принципы считывания будут те же самые.
- Отсутствие ненужного кода... Вот как раз если выделить самостоятельный парсер в виде отдельного файла - тогда и не будет нагромождения ненужного кода в файлах самого компонента!
Плюс Monty высказал интересную мысль: "например, я использую TMyXML ... а в вашем компоненте есть другой TVashXML ... так что делать? Смирится с +120кб или использовать ваш? Или же переписать компонент под свой TMyXML ...". Выделение парсера в отдельный независимый файл позволит более гладко переходить на другой xml-парсер (в случае необходимости).

Цитата(Quadr0 @ 9.8.2005, 01:04)

Может, юникода хватит?

Кодировка Windows-1252 (или подобная) должна поддерживаться в любом случае. Так как именно эту кодировку используют старые файлы подсветки.
А на счёт юникода. Пока что в нём нет абсолютно никакой необходимости, так как наш парсер ("токенов") об юникоде ничего не знает. И официальный SynEdit тоже.
Вот когда будет доделан UniSynEdit и когда (если) мы возьмёмся за добавление юникода в наш парсер, то можно будет и подсветки в юникоде хранить
Но, в принципе, реализовать поддержку юникода можно уже и сейчас (единственно, что она будет востребована не на всю катушку). При чём UTF-8 тоже тогда был бы полезен.