Здесь описаны правила оформления объектов AOT в Базе Знаний
Компоненты именуются как в АОТ, и помещаются в кластер, по названию совпадающий с названием типа объекта. Например:
Так сделано во-первых, для того чтобы различать одноименные компоненты разных типов, во-вторых чтобы не делать слишком вложенных кластеров и не затруднять этим адресацию. Русские названия — исходя из естественности упоминания в русском тексте: «Таблица\Invent Journal Trans? также отвечает за...» «Форма\Invent Journal Table? содержит пример использования того-то»
Методы классов — это страницы в кластере класса. Например:
Для того, чтобы представить наследование класса X от класса Y надо добавить на страницу класса X Маркер «/Axapta/Extends/X" — тогда перечень наследников появится в классе X автоматически.
Класс / Object содержит пример того, как этого добиться.
кластеры содержат описания иерархий наследования для компонентов
предполагается, что компоненты должны включать соответствующие страницы иерархии, например Класс / Object должна включать Иерархия Классов / Object?
вопрос как должна осуществляться навигация по иерархии?
что имеешь в виду? MazzyMazzy /17.01.2005 22:20/
каким образом тыкая по классу во включенной странице иерархии произойдет переход на, например, родительсий класс? — /Max Belugin
хм... родительский класс ведь всегда один. См. /Axapta / Иерархия Типов / rec Id? Или я не понимаю чего? MazzyMazzy /18.01.2005 15:33/
как из Иерархия Типов / rec Id? перейти на EDT/recID? на EDT/RefRecID (а не на Иерархия Типов / Ref Rec ID?)? — /Max Belugin
а... теперь понял. в EDT/recID будет include из иерархии. Вообще говоря, я хотел упорядочить и стандартизировать список разделов для каждого объекта. Так для каждого объекта должно быть:
Что-нибудь в этом духе.
MazzyMazzy /18.01.2005 17:08/
«а... теперь понял. в EDT/recID будет include из иерархии.» — это обратная задача: как из EDT/... перейти в Иерархия Типов?/... а я спрашивал про наоборот. Вообще, можешь сделать пример? — /Max Belugin
вот /Axapta / Класс / Form Run
обратного перехода предусматривать не стоит, на мой взгляд. почему? разве это не будетудобнее? — //MaxBelugin
обрати внимание на параметр nomark="2" в инклюде. Попробуй зайти на эту страницу под собой и под гостем.
я пробовал. попробуй и ты.
добавь в иерархию переход на описание класса.
вставь иерархию в описание.
посмотри описание с иерархией с обратным переходом. особенно под гостем.
вот /Axapta / Класс / Form Run
кстати, только сейчас заметил, что я неправильно права расставил в иерархии.
там доступ на редактирование всем дан... надо будет исправить...
а!!! ты хочешь из иерархии ссылки сделать на описания, а не в иерархию!
так? Тогда ты прав, так действительно будет лучше....
я то думал про дополнительный маркер...
MazzyMazzy /19.01.2005 18:41/
Не стоит ли подубами о том чтоб сделать иерархию отдельно от wiki? — не будет перегружаться вики, а вики-возможности не нужны... — /Max Belugin
а как это сделать?
я вижу два варианта:
в обоих случаях вместо включения делать ссылку на иерархию: например, у нас есть Класс / Object. В нем мы делаем ссылку:
в http://erpkb.com/AxHierarchy/Class/Object.html содаржатся ссылки обратно на wiki
можно сделать wiki-action для автоматизации ссылок на иерархию по образу и подобию j.php
тогда зачем нам вики? MazzyMazzy /20.01.2005 14:06/
Есть два вида информации – та, которую имеет смысол менять, и та, которую менять смысла нет. Иерархия относится ко второму типу. К первому типу относится описательная информация о классе, его предназначение, особенности и т.д. Т.к. иерархию нет смысла менять, к тому же она будет мешаться в поиске, я предлагаю вынести ее в статический HTML. Например так:
Таким образом пользователи смогут менять описание классов и не смогут менять иерархию – да им это и не нужно.