Форум » » Aml Pages : Что дальше? » Ответить
Aml Pages : Что дальше?
Carc: Отгремела Aml Pages 9.72 Традиционный русский вопрос. Что делать? Что делать дальше. Я конечно кое-что причесываю в последней сборке Aml Pages, но это уже рюшечки-цветочки-технические-должочки. А на самом деле пора задуматься о новых фичах, и улучшениях\исправлениях старых. Меня тут просили несколько человек о следующем. Иерархические теги. Ну как бы сейчас выбор тега всегда из списка (из меню). Причем это меню - всегда одного уровня. Ну список, он и есть список. А просили сделать чтобы теги могли быть дочерними\родительскими по отношению к друг другу. Общее видение и прикидки как-такое сделать у меня примерно есть Оно кому нибудь надо? Множественное выделение в дереве Сейчас в панели дерева в Aml Pages можно выделить один и только один узел. Выделяем другой - с предыдущего выделение снялось. Хотят чтобы можно было выделить сразу несколько - ну к примеру через выделение следующего узла в дерева, удерживая клавишу Ctrl. Нужно, чтобы проводить операции сразу над несколькими узлами. Ну например выбирать цвета\иконки. Рабочий прототип у меня в последней сборке Aml Pages уже есть. Кривой\косой, но само выделение множественное через Ctrl работает. Естественно, в production релизы публичные это не попадает. Это кому нибудь надо? Цветовые группы Уже сделано Сейчас можно отдельно выбирать цвет текста узла в дереве, цвет фона узла в дереве. Сделать чтобы можно было сразу, выбирать разом и то и другое, описанное в некой цветовой группе. Несложно, но уже какая-то мешанина получается. Есть категории - та еще муть (цвет текста + иконка) Есть цвета в дереве - текста и фона. Но суть в категориях что они работают как стили. Один раз вовне описали стиль (цвета, иконка) и все узлы, которым назначена эта категория используют именно эти настройки. Фишка в другом: поменяли парамеры конкретной категории и все узлы с этой категорией, автоматически изменили свой внешний вид. Поэтому цветовые группы напрашиваются в категории. Но там много переделывать, и скорее всего придется порушить совместимость форматов файлов сверху вниз (старые версии Aml Pages, не смогут прочитать версии документов созданные в новой - наоборот легко). Дикое сорри, конечно. Но категории делались еще в версии 9.00-9.02. Тогда я еще не придумал способ наращивать формат файла документа так, чтобы старые версии могли как минимум прочитать версии документов, созданные в новой версии Aml Pages, и нормально с ним работать. Просто не трогая данные новых версий (игнорируя их - прочитали, изменили только то что умеем, знаем - и записали всё обратно: измененные данные - и данные новой версии, неизменными обратно их в файл). В общем там не так все просто. Оно кому нибудь надо? Другие пожелания хотения?
Ответов - 56, стр:
1 2 3 All
DenisSMI: Carc пишет: Иерархические теги. Ну как бы сейчас выбор тега всегда из списка (из меню). Причем это меню - всегда одного уровня. Ну список, он и есть список. А просили сделать чтобы теги могли быть дочерними\родительскими по отношению к друг другу. Общее видение и прикидки как-такое сделать у меня примерно есть Оно кому нибудь надо? Мне будет очень полезно!
Carc: А тебе они для чего именно нужны? Как ты используешь иерархические теги?
DenisSMI: Carc пишет: А тебе они для чего именно нужны? Как ты используешь иерархические теги? Как классы и подклассы. Для разных тегов нужны подтеги с идентичными именами. Напр, теги "Россия", "Германия" Подтеги "Политика", "ТВ", "Адреса" и т.п.
Carc: DenisSMI пишет: Как классы и подклассы. Для разных тегов нужны подтеги с идентичными именами. Напр, теги "Россия", "Германия" Подтеги "Политика", "ТВ", "Адреса" и т.п. Странный какой-то способ у тебя использования тегов. У меня скорее наоборот. Теги это признак принадлежности страницы к какой-то тематике по определенному признаку. Т.е. теги "Россия", "Германия" + теги (не подтеги]) "Политика", "ТВ", "Адреса" Тогда страница в Aml Pages, которая имеет теги "Россия", и теги "Политика" - то это означает, что страница про что-то там про Россию, и про Политику. Представь: что есть другая страница с тегами "Германия" + "Политика". Тогда это означает, что страница содержит инфу какую-то тоже про политику, но про германию. А третья: содержит теги "Россия", "Германия", "Политика", "ТВ" - там просто ссылка про передачу на ТВ, в которой обсуждается срач спор бундестага и госдуры на политическую тему. Т.е. мысль проста: вроде как нет никаких подтегов. Есть только тег. Установка тега означает, что страница относится к тематике, которая описана этим тегом. Т.е. в приведенном примере: страницы могут относиться к разным тематикам (тегам) одновременно. И политика, и тв, и Россия. Это как бы классификатор. Но каждый тег ортоганален другому. Т.е. страница про Германию легко может содержать и тег "ТВ" - т.к. там что-то про телепередачу про германию, а может и не содержать тега "ТВ" - т.к. там просто список адресов в Германии. Улавливаешь, о чем я?
Carc: PS: другой разговор, что теги все-таки могут иметь некоторые соподчиненные отношения. Ну например: теги "Берлин" и "Германия". В странице с тегом "Берлин" допустим инфа про музеи Берлина. А в других страницах с тегом "Германия" - что-то вообще про Германию. Но не про прям вот про Берлин. Но кагбэ тут напрашивается соотношение, что тег Берлин дочерний тегу "Германия". Он как бы часть Германии. Ну и соответственно тогда все страницы, имеющие только тег Берлин, автоматически имеют и тег "Германия" - т.к. он более высокого порядка. И все что с тегом "Берлин" автоматически относится к тегу "Германия". Но не наоборот. Все страницы с тегом "Германия" не относятся автоматически к тегу Берлин. Вот как-то так иногда напрашивается…
SetQ: А мне чуть иначе видится. Пусть однородный список тэгов как был, так и остаётся. А иерархия будет только интерфейсом - удобным способом доступа (поиска, выбора) к тэгам. То есть тэги Германия и Берлин будут в одном списке, но чтобы найти тэг надо будет раскрыть список Германия. Я бы просто два тэга поставил - и Германия, и Берлин. Как у меня будет: скажем есть информация о строительных конструкциях. Я завожу папки для тэгов "материалы", "сооружения", "конструкции", в них будут группироваться тэги (сейчас они лежат в одном общем списке) железобетон, сталь, дерево; жилые дома, теплотрассы, спортивные комплексы; лестницы, крыши, фундаменты. Для каждого объекта строительства или справочного информации могут быть выбраны любые такие тэги в любом сочетании. А иерархический список - это способ навигации между ними. Сейчас описал - вроде полезная вещь получается. А то сейчас у меня список тегов в выпадающем меню на пол экрана. Остаётся придумать способ хранения иерархии тэгов. Он будет внутри документа apd или во внешнем файле? И способ создания иерархии. Я бы так предпочёл: AML генерирует текстовый файл со списком всех тэгов, я его редактирую - по некому синтаксису - там скобки или звёздочки для маркировки глубины вложения, сохраняю, велю AML его подцепить, при нажатии на кнопку "Тэги" появляется меню с подменю, в подменях - другие подменю (если есть) и тэги и т.д. Можно сделать только один уровень вложения, т.е. поделить тэги на группы, для меня это уже большой шаг вперёд будет. Вот так например: [материалы] железобетон сталь дерево [сооружения] жилые дома теплотрассы спортивные комплексы [конструкции] лестницы крыши фундаменты Можно в tags.ini просто добавить, там есть секция [tags] - для тэгов по умолчанию. А если уже установленный в документе тэг находится в одной из остальных секций tags.ini (все остальные секции - это указания по группировке тэгов в одноуровневую иерархию), то для него создаётся подменю и он туда группируется. Как? Все несгруппированные тэги просто как прежде остаются в основном списке по кнопке "Тэги". Тогда лучше такой формат: [tagstree] count=3 grupname1=материалы gruplist1=железобетон,сталь,дерево grupname2=сооружения gruplist2=жилые дома,теплотрассы,спортивные комплексы grupname3=конструкции gruplist3=лестницы,крыши,фундаменты Формат документа apd не меняется, дополняется только tags.ini и способ его обработки и поведение при нажатии на кнопку "Тэги". Ещё в фильтрах тэги появляются, там примерно также, как при назначении тэгов будет. Для географии я бы так сделал: [Германия] Германия Берлин Мюнхен [Россия] Россия Москва Петербург Если нужно всё про Германию, то можно просто добавить в меню тэгов при раскрытии подменю пункт "выбрать всё", и Германия, Берлин, Мюнхен будут выбраны одним кликом мышки - это для фильтра по тэгам.
Carc: SetQ пишет: Как у меня будет: скажем есть информация о строительных конструкциях. Я завожу папки для тэгов "материалы", "сооружения", "конструкции", в них будут группироваться тэги (сейчас они лежат в одном общем списке) железобетон, сталь, дерево; жилые дома, теплотрассы, спортивные комплексы; лестницы, крыши, фундаменты. Для каждого объекта строительства или справочного информации могут быть выбраны любые такие тэги в любом сочетании. А иерархический список - это способ навигации между ними. Сейчас описал - вроде полезная вещь получается. А то сейчас у меня список тегов в выпадающем меню на пол экрана. Именно это я и имел ввиду. Разве что не "папки", а родительские теги. Т.е. все эти "материалы", "сооружения", "конструкции" это тоже теги. Но родительские для других каких-то тегов. Мне кажется так нагляднее и понятнее. Хотя там больше будет мути с обработкой таких родительских тегов. А именно фильтры по тегам, и левая панель просмотра по тегам. Как оно будет соотноситься с такой постановкой. По уму напрашивается, что если выбран дочерний тег - то все его родители, и над-родители, дедушки как бы автоматически присутствуют. Но не наоборот.
SetQ: Родительские тэги - это, конечно, дополнительные возможности, но так и сделать их будет труднее.
Carc: SetQ пишет: Родительские тэги - это, конечно, дополнительные возможности, но так и сделать их будет труднее. А иначе кой смысл в группах тегов?
SetQ: Carc пишет: А иначе кой смысл в группах тегов? Можно просто группировать тэги в меню выбора по смыслу, а не по алфавиту сортировать - тоже полезно было бы. Но это программа - минимум.
Carc: SetQ пишет: Можно просто группировать тэги в меню выбора по смыслу, а не по алфавиту сортировать - тоже полезно было бы. Но это программа - минимум. Ну это очевидно! Что группировка. Но почему отдельная сущность? "Группа"? Просто родительский тег, он же группа дочерних тегов. Т.е. грубо говоря родительский тег-группа - это такой более обобщенный тег. Дочерние теги - это те же теги, из той же группы-тега - но по смыслу более частые. Тогда мое видение таково: что все страницы которым выставлен родительский тег считаются что они так же имеет и родительский тег-группу. Но не наоборот. Я это в смысле тегов. Выбрали в фильтрах тег-группу "Строительство" - туда попадут все страницы и с дочерними тегами "Материалы", "Конструкции". А выбрали в фильтрах дочерний тег "Материалы" - туда попадут только те страницы, которым явно выставлен дочерний тег "Материалы". Но не попадут у которых соседний тег "Конструкции", или только родительский тег "Строительство"
SetQ: Согласен, с дочерними тэгами совсем другая песня.
Carc: SetQ пишет: Согласен, с дочерними тэгами совсем другая песня. Единственное конечно, логика обработки тегов во всяких фильтрах становится весьма мутной. Ну да это проанализируется.
Carc: ЗЫ: вот видео что просили сделать как в myBase.
SetQ: Хорошо работает в майБазе.
Carc: SetQ пишет: Хорошо работает в майБазе. Да, там хотя бы пример наглядный.
Carc: SetQ пишет: Остаётся придумать способ хранения иерархии тэгов. Он будет внутри документа apd или во внешнем файле? Мне как-то казалось, что иерархия должна храниться внутри документа. + Дублироваться во внешнем файле или настройках. Чтобы не создавать иерархию заново для каждого нового документа.
SetQ: Тоже свои плюсы есть в документе хранить. Учитывая, что у меня всё в одном документе apd хранится, так будет удобнее для переноса на другой комп, если в доку иерархия.
Carc: SetQ пишет: Тоже свои плюсы есть в документе хранить. Учитывая, что у меня всё в одном документе apd хранится, так будет удобнее для переноса на другой комп, если в доку иерархия. Ну я думаю что приоритетом будет все таки документ. А теги по умолчанию так и останутся умолчаниями для новых документов. Как-то так вероятно.
Carc: SetQ пишет: Тогда лучше такой формат: Ну с форматом разберемся. Я думаю сделаем несколько иначе. Все равно понадобится редактор иерархиии тегов. Перетащить\Заменить и.т.д. А как он серилизуется во внешний файл дело наживное. Плюсы: ини-файла - легко писать в папку программы. Windows это по умолчанию вполне себе пропускает. А если и делает редирект ини-файла, то все равно для программы прозрачно. Минусы ини-файла: ну его редактировать ручками конечно дело не очень удобное. Второй вариант XML-файл: тут все с точностью до наоборот. Редактируй хоть в чем угодно, XML-редакторов огромное число. А вот записать XML-файл рядом в папку с программой при определенных установках безопасности винды может оказаться делом невыполнимым.
полная версия страницы