0003609: Неверное отображение описаний меток при щелчке на метку или группу меток

Notes
(0019610) vdemidov (manager) 13-01-2020 09:08	А вот это мне уже не нравится. Я бы предложил в редакторе сделать кнопочку с авто расстановкой тегов параграфов.

(0019611) zed (manager) 13-01-2020 09:35 edited on: 13-01-2020 09:38	Можно сделать так: если в описании метки нету символов "<" (т.е. это не html, а простой текст), то перед выводом в браузере заменить все символы перевода строки на html тег "br". А редактор трогать вообще не надо.

(0019612) dimasic (developer) 13-01-2020 10:18 edited on: 13-01-2020 10:21	Ладно. Допустим, что такая схема потенциально может поломать какое-то сложное форматирование (скажем, стили параграфа, если кто-то их использует) и пользователь никак не может повлиять на логику работы алгоритма. Более того, этот код придется продублировать сразу в двух местах (хоть это довольно странно) - и в frm_Main в обработке клика на группу меток, и во встроенном браузере, и в случае чего исправлять код дважды. Тогда по данному багу (а это именно баг), если в описании нет ни одного HTML тега (кроме ката) и есть несколько переводов строк (то есть, есть чему склеиваться в кучу), можно просто использовать обрамление в PRE - это гораздо лучше, чем склеенные абзацы текста. И еще проще в реализации, чем добавление BR. А кнопочку в редакторе выделить из данного баг-репорта в реквест фичи.

(0019613) zed (manager) 13-01-2020 10:50	Pre использует особый стиль шрифта для вывода текста, а этого не хотелось бы (как мне кажется).

(0019614) dimasic (developer) 13-01-2020 11:17	Моноширинный, да. Мне он тоже не очень нравится. Хотя в данной ситуации данный тег наиболее логичен: например, P съедает пробелы в начале строки, абзац в теле без тегов P - съедает, а PRE - не съедает, и это может быть использовано для оформления отступов абзацев без использования стилей, если пользователь вообще не пользуется тегами.

(0019615) zed (manager) 14-01-2020 09:39	Шрифт вроде можно стилем поправить? В реализации получится сложнее, чем с BR, но зато сохранится форматирование пробелами. Если оно, конечно нужно. Ждать пулреквеста?

(0019616) vdemidov (manager) 14-01-2020 09:56	Дело ваше, но я бы все-таки отдал такие автоматизации на усмотрение самого пользователя. Максимум обеспечить удобными инструментами, что бы было просто заменить переводы строк на br, или обрамить все содержимое при помощи pre поставив одну галочку или нажав кнопку.

(0019617) zed (manager) 14-01-2020 10:04 edited on: 14-01-2020 10:05	А я не против того, чтобы простой текст автоматически отображался одинаково, что в браузере, что в редакторе метки. Также я не против удобных инструментов - одно другому не мешает.

(0019618) vdemidov (manager) 14-01-2020 10:10	Ну, мне просто не нравится появление какой-то неочевидной эвриситики, которая в рантайме, будет анализировать содержимое описания, и менять отображение. Я за то что-бы если и делать что-то такое, то только в редакторе. И что бы это было можно понять. Например, вставили большой текст с кучей отступов, переводов строк и тд - оно автоматом выставило галочку "Без форматирования" и обрамило это все тегом Pre (возможно даже не отображая этот тег). Но при этом пользователь всегда может снять эту галочку или увидеть подсказку, что в теле описания есть теги и ее лучше таки снять.

(0019619) zed (manager) 14-01-2020 10:23 edited on: 14-01-2020 10:24	Убрать и скрыть вставленный тег не получится. Сильно продвинутая эвристика получается и дополнительно к описанию придётся хранить ещё какую-то метаинформацию (было/не было вставлено автоматически и что было вставлено и проч.). Если взять для примера GoogleEarth, то там в описании меток можно так же использовать html теги, но и форматирование простого текста сохраняется автоматически. Там никто не заставляет пользователя вставлять какие-то чуждые простому смертному pre и br. И что самое интересное, там эвристика работает ровно так, как я описал - если руками вставить хоть один тег, то авто-форматирование пропадает. И судя по всему, там используется авто-вставка br, т.к. форматирование пробелами не сохраняется.

(0019620) dimasic (developer) 14-01-2020 12:57 edited on: 14-01-2020 13:01	> Но при этом пользователь всегда может снять эту галочку или увидеть подсказку, что в теле описания есть теги и ее лучше таки снять. Две ситуации. В обоих случаях пользователь без понятия, что такое HTML, теги и какое-то P, PRE и так далее. Сложное форматирование ему не нужно, достаточно простого описания в 1-2-3-несколько абзацев. 1. Ввел простой текст, ровно два абзаца. Эвристика определяет отсутствие тегов и ставит PRE или BR. Прямо в описание метки, пусть даже без отображения в коде. Все замечательно. (Кстати, вставка скрытого PRE в описание по сути ничем не отличается от вставки PRE при выводе документа в окно). 2. Ввел простой текст и нажал кнопку вставки картинки. В описании добавилось что-то непонятное, какие-то угловые скобочки, но он решает, что раз нажал кнопку, то так и должно быть. Все, оформил описание как ему хотелось. И вдруг ему выскакивает сообщение, что в теле описания есть теги (???), и что ему надо снять галочку. Или не снять. Если он ее снимает, но не добавляет BR в конец каждого абзаца или не обрамляет абзацы в P, абзацы у него склеиваются в кучу друг с другом и с картинками. Получается нечто. Если не снимает, описание непонятно почему выводится другим шрифтом. Повторюсь, пользователь у нас неопытный. Но даже опытному ставить около каждого абзаца теги - то еще удовольствие. Поэтому наиболее универсальным вариантом может быть 1) обрамление текста без тегов в PRE или вставка BR в конце каждого абзаца по рецепту zed при непосредственном выводе описания в окне встроенного браузера при отсутствии тегов в тексте (кроме тега ката, его за тег не считаем, он на отображение документа никак не влияет) + 2) кнопочка автоматического форматирования в редакторе с расстановкой P или BR, а там пусть пользователь сам смотрит, пользоваться ей или нет. > дополнительно к описанию придётся хранить ещё какую-то метаинформацию (было/не было вставлено автоматически и что было вставлено и проч.). Да, эту метаинформацию надо где-то хранить. Или в отдельном поле описания метки (на что едва ли пойдем), или прямо в поле описания в виде какой-то неотображаемого (?) в редакторе тега. Оба варианта не очень. Кроме того, метаинформацию надо еще и поддерживать в актуальном состоянии.

(0019621) zed (manager) 14-01-2020 13:00	Я решил сам заняться этим тикетом и сделать на подобии GE. Посмотрим, что получится.

(0019622) zed (manager) 14-01-2020 13:34	Сделал, тестируйте.

(0019623) dimasic (developer) 14-01-2020 16:52 edited on: 14-01-2020 16:55	С простым текстом работает. И с одиночными метками, и с группами в любых комбинациях (простой текст с простым текстом, простой текст с форматированным). Только хорошо бы после BR добавить перевод строки. На отображение не влияет, но ничего не стоит, а без него в коде странице получается мрак. Но все равно поведение не очевидно и не однозначно. Пока тегов нет, работает нормально. Стоит затесаться безобидному жирному шрифту, не говоря о ссылке или картинке - и описание склеивается в большую кучу. Может быть, есть смысл теги, вставляемые кнопками редактора (B, I и так далее, включая IMG и A), не считать тегами, требующими ручного форматирования? И отключать эвристику только при наличии посторонних, введенных в поле описания самим пользователем, тегов?

(0019624) zed (manager) 14-01-2020 16:56	> и описание склеивается в большую кучу Ну да, но раз уж пользователь начинает играться с тегами, то ничего не поделаешь. Остаётся доработать редактор меток и добавить функцию авто-вставки br.

(0019625) dimasic (developer) 14-01-2020 17:11	> Ну да, но раз уж пользователь начинает играться с тегами, то ничего не поделаешь. А он не начинает играться, он просто хочет выделить одно слово жирным, пользуясь штатными средствами программы - кнопкой панели форматирования. Даже если слово "тег" никогда и не слышал. Тогда или кнопки B-I-U и т.д. вообще убирать, или сделать для них исключение. Кстати, если написать 1 < 2 - тоже получаем склеенные абзацы, потому что алгоритм считает знак "меньше" признаком открывающего тега, хотя это тегом не является. Ну, это пока лишь баг, понятно. Но искать этот значок в описании очень скоро даже мы с вами не сразу догадаемся, что там про остальных людей говорить.

(0019626) zed (manager) 14-01-2020 18:20 edited on: 14-01-2020 18:46	Ок, я пока что пас. Далее, как мне кажется, надо дорабатывать редактор метки: - добавить индикацию, как в данный момент программа воспринимает описание: Text или Html - добавить кнопки Escape/Unescape Html Chars, чтобы всякие больше/меньше заменились на валидные &lt, &gt и обратно - добавить кнопки вставить/удалить переводы строк (тег br) - ...

(0019627) dimasic (developer) 14-01-2020 19:23	> Ок, я пока что пас. На самом деле, если чуть доработать уже вами реализованное по данной проблеме, то получается вполне себе хорошо. В коде проверки форматирования удаляем не только тег ката, но еще открывающие и закрывающие теги B, I, U, CENTER, а также начало тега DIV ALIGN и /DIV, начало тега IMG и начало A HREF + /A. Выглядит вроде сложно, но чтобы коду придать изящности, удалять их не как в THtmlToHintTextConverterStuped.HTML2Txt - в каждой строчке по фрагменту, а в цикле перебором элементов кортежа? перечисления? или как это называется в Паскале, или просто строки с перечислением элементов, разбивая ее по разделителю. Потом проверяем наличие открывающих тегов (для начала можно оставить одну угловую скобку плюс пробел - это уже уберет бОльшую часть ложных срабатываний, а потом, если всего этого окажется мало, подключить регулярные выражения). Если открывающих тегов нет, возвращаем исходный текст описания, в нем меняем переводы строк на BR+13+10 иии... уже очень-очень похоже на то, что нужно. Лично меня такое уже вполне устраивает. А если встречаем что-то подозрительное и отключаем эвристику, в конце страницы даем ссылку на Вики, где пользователь может почитать о возможных проблемах в отображении описаний.

(0019628) dimasic (developer) 14-01-2020 19:31 edited on: 14-01-2020 19:35	Да, ну и для особо продвинутых пользователей можно ввести метатеги, принудительно включающие и отключающие эвристику, по типу тега sas.cut - например, sas.preformat.on и sas.preformat.off - для очистки совести, так сказать. Это перекроет нужды большинства.

(0019629) zed (manager) 14-01-2020 19:36	Ничего себе "чуть доработать". Если делать по уму, то это уже тянет на полноценный html парсер, который пропускает только некий заданный набор тегов. А если делать в лоб, то будут ложные срабатывания, как с больше/меньше.

(0019630) dimasic (developer) 14-01-2020 19:52	Полноценный парсер вообще не нужен. Достаточно игнорирования тегов, вставляемых редактором. А если юзер настолько продвинутый, что эвристика нежелательна, он всегда сможет почитать справку и отключить эвристику. Если он добавил что-то эдакое, из-за чего эвристика отключает автоформат, он при желании сможет его включить обратно. Лично я не смогу даже навскидку сказать, какими тегами, помимо существующих, я бы с удовольствием пользовался. Возможно, тегами таблицы, но до сих пор ни разу таблицу не вставлял. Лично для меня описанный выше алгоритм подходит более чем на 99%, а с учетом возможности управления автоформатом - на все 100%. Больше просто не бывает.

(0019631) dimasic (developer) 14-01-2020 20:43	Поигрался с реализацией этого алгоритма, работает в точности как хотелось, чего мне давно не хватало. А чтобы не вставлять теги включения и отключения автоформата, можно добавить в форму чекбокс с тремя положениями: включен, выключен и авто. И пусть его состояние запоминается в тексте описания и восстанавливается из текста, но при этом не отображается в форме. Да, и тег лучше не autoformat назвать, а smartformat, например. Иначе может получиться путаница, что именно там автоматическое: определение необходимости форматирования или собственно форматирование.

Users who viewed this issue
User List	Anonymous (1386x), brayan99 (1x), suregoodru (1x), noxicus (1x), zed (34x), dimasic (26x), Tolik (2x), vdemidov (18x), kalakotkas (1x), bk99 (1x)
Total Views	1471
Last View	22-11-2024 10:12

Issue History
Date Modified	Username	Field	Change
12-01-2020 19:07	dimasic	New Issue
13-01-2020 09:08	vdemidov	Note Added: 0019610
13-01-2020 09:35	zed	Note Added: 0019611
13-01-2020 09:38	zed	Note Edited: 0019611	View Revisions
13-01-2020 10:18	dimasic	Note Added: 0019612
13-01-2020 10:21	dimasic	Note Edited: 0019612	View Revisions
13-01-2020 10:50	zed	Note Added: 0019613
13-01-2020 11:17	dimasic	Note Added: 0019614
14-01-2020 09:39	zed	Note Added: 0019615
14-01-2020 09:56	vdemidov	Note Added: 0019616
14-01-2020 10:04	zed	Note Added: 0019617
14-01-2020 10:05	zed	Note Edited: 0019617	View Revisions
14-01-2020 10:10	vdemidov	Note Added: 0019618
14-01-2020 10:23	zed	Note Added: 0019619
14-01-2020 10:24	zed	Note Edited: 0019619	View Revisions
14-01-2020 12:57	dimasic	Note Added: 0019620
14-01-2020 13:00	zed	Note Added: 0019621
14-01-2020 13:01	dimasic	Note Edited: 0019620	View Revisions
14-01-2020 13:34	zed	Note Added: 0019622
14-01-2020 13:35	zed	Assigned To	=> zed
14-01-2020 13:35	zed	Status	new => feedback
14-01-2020 13:35	zed	Product Version	=> 191221
14-01-2020 13:35	zed	Target Version	=> 211230
14-01-2020 16:52	dimasic	Note Added: 0019623
14-01-2020 16:52	dimasic	Status	feedback => assigned
14-01-2020 16:55	dimasic	Note Edited: 0019623	View Revisions
14-01-2020 16:56	zed	Note Added: 0019624
14-01-2020 17:11	dimasic	Note Added: 0019625
14-01-2020 18:20	zed	Assigned To	zed =>
14-01-2020 18:20	zed	Status	assigned => confirmed
14-01-2020 18:20	zed	Note Added: 0019626
14-01-2020 18:46	zed	Note Edited: 0019626	View Revisions
14-01-2020 19:23	dimasic	Note Added: 0019627
14-01-2020 19:31	dimasic	Note Added: 0019628
14-01-2020 19:35	dimasic	Note Edited: 0019628	View Revisions
14-01-2020 19:36	zed	Note Added: 0019629
14-01-2020 19:52	dimasic	Note Added: 0019630
14-01-2020 20:43	dimasic	Note Added: 0019631
30-12-2021 08:59	zed	Target Version	211230 => 26xxxx

Relationships

SASGIS