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


Автор: Vitalik 23.7.2005, 00:09
Итак, сейчас идёт доработка компонента...

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

На данный момент правило-диапазон может открываться и закрываться только одной парой тегов, что в некоторых ситуациях бывает очень не удобным.
Потому как, например, скрипт VBScript в HTML может начинаться не одним, а несколькими способами:
• <script runat="server" language=VBScript name="test">
• <script runat="server" language='VBScript' name="test">
• <script runat="server" language="VBScript" name="test">
• <script language="VBScript">
• <script language='VBScript'>
• <script language=VBScript>

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

Теперь основной стратегический вопрос. При задании разных способов открытия/закрытия диапазона нужно ли у этих способов, кроме собственно строк тегов, также задавать такие свойства, как "закрытие в конце строки", "тег как часть слова" и т.п. или же это излишне?

Я лично придерживаюсь того мнения, что стоит позволять задавать ВСЕ эти свойства тега. Тем более что такая возможность уже практически реализована в компоненте.
Но большим минусом является непонятность дизайнерского решения и, возможно, его усложнение. Если будут идеи по этому поводу, прошу в студию!

Очень прошу аргументировать свои ответы или хотя бы постить любое сообщение, чтобы я знал кто и как уже проголосовал.

Спасибо за помощь в идеологическом проектировании компонента! http://forum.sources.ru/smiles/Main/wink.gif

Автор: Quadr0 23.7.2005, 01:26
...

Автор: miksayer 23.7.2005, 01:35
Конечно нужна, при чём для всех свойств тега

Автор: Quadr0 23.7.2005, 01:38
...

Автор: dionisiy 23.7.2005, 10:11
smile
smile

я не догоняю немного

Автор: dionisiy 23.7.2005, 11:36
А вспомнил.

Допустим у меня есть программа, в ней

НачалоПроцедуры Бла

бла бла

КонецПроцедуры

но может кончатся не на КонецПроцедуры, а просто Конец

ну есть такой язык Rsl там бывает такое. Код не сам пишешь, разные люди по разному пишут

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

Вы не представляете как занудно было добавлять копи пастом диапазоны, причем изменения вносить в двух местах, я помню еще давно за правила-ссылки говорил. Хотя они тут не помогли особо, конечно только если бы не ввели объекта Шаблон )

Я за причем доп. свойства тоже было бы интересно

Автор: Vit 24.7.2005, 02:52
Голосовал за второй пункт. Причина - не стоит усложнять чрезмерно

Автор: StayAtHome 25.7.2005, 02:00
Голосую за многотеговость. Но действительно, задавать параметры для каждого тега в отдельности -- перебор. Думаю, надо делать общий набор свойств ( "закрытие в конце строки", "тег как часть слова" и т.п) для всех тегов. Всякие "В конце строки" и так редко используются, а дизайнер схем и без того с каждым релизом усложняется. smile

Автор: jasny 25.7.2005, 09:58
Голосую за первый вариант

Да конечно, подсветки рисовать будет непросто, но и не надо допускать каждого встречного поперечного к данному процессу. Подсветки рисуются не так часто. Они часто правятся (кому-то там цвет не понравился или еще чего).

А ежели человек не может разобраться с правилами постороения подсветок, то не хрен и браться.

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

Ко всему вышесказанному - мой текст не оправдывает плохой дизайн редактора (эргомика должна быть эргономной smile).
Добавлено @ 10:07
В связи с понедельничными "тормозами" мне лично проголосовать не удалось smile

Всем подспудно подразумевать "плюс один голос" первому варианту.

Автор: Vitalik 28.7.2005, 21:49
Спасибо всем проголосовавшим в этом опросе! И особенно спасибо за аргументацию своих голосов.

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

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

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