10.04.2011, 15:41 | #21 |
SAP
|
Цитата:
============================
В С++ я бы написал что-то вроде struct { int64 refTable; int refField } myStruct; set<myStruct> myStructSet = ( {Table1, Field1}, {Table2, Field2} ); и получил бы одновременно и контроль типов, и легкость инициализации. ======================== ============================ TYPE: BEGIN OF myStruct, table TYPE integer64, field TYPE integer, END OF myStruct. TYPE: BEGIN OF myStructComlex, key TYPE myStruct, value TYPE myStruct, END OF myStructComlex. TYPE myStructComlexTab TYPE HASH TABLE myStructComlex WITH UNIQUAE KEY key. ============================ |
|
10.04.2011, 16:11 | #22 |
Участник
|
не в тему.
и вы не написали как будет выглядеть добавление нескольких значений в эту хэш-таблицу. если уж речь идет о таблицах, то fed предложил более изящный способ - создать структуру в АОТ. и дальше делать несколько insert'ов. и кода меньше, и проверок больше. а в аксапте прямой аналог вашего кода - map (вариант я не выписывал с способы из-за явно избыточного key) X++: myMap = new(Types::string, Types::class); myMy.add("someKey1", new myPair(table1, field1); myMy.add("someKey2", new myPair(table2, field2); но все равно кода получается слишком много по сравнению с set<myStruct> myStructSet = ( {Table1, Field1}, {Table2, Field2} ); |
|
10.04.2011, 17:31 | #23 |
SAP
|
Цитата:
не в тему.
и вы не написали как будет выглядеть добавление нескольких значений в эту хэш-таблицу. ================ DATA: lt_myStructComlexTab TYPE myStructComlexTab, ls_myStructComlexTab LIKE LINE OF lt_myStructComlexTab. CLEAR ls_myStructComlexTab. ls_myStructComlexTab-key-table = 'TABLE1'. ls_myStructComlexTab-key-field = 'FIELD1'. ls_myStructComlexTab-value-table = 'TABLE2'. ls_myStructComlexTab-value-field = 'FIELD2'. INSERT ls_myStructComlexTab INTO TABLE lt_myStructComlexTab. ================ не совсем понял что значит гемороится с ключами, ядро само контролирует ключ. если вам это не надо то можно тип таблицы изменить на простую. ================ TYPE myStructComlexTab TYPE STANDARD TABLE myStructComlex. ================ это аналог SET. извините за за СПАМ. |
|
10.04.2011, 18:46 | #24 |
Участник
|
Цитата:
а! у вас структура хранится два раза: и в ключе, и в значении (value) хорошо, что есть аналог set. давайте все-таки вернемся к теме. итак - аксапта. контейнеры - статично, просто, без контроля, очень затратно по памяти. класс-классов - полный контроль, но писать блин много. хотя, гуру утверждают, что окупается. (временная) таблица - писать тоже много. но зато хоть какой-то контроль типов. |
|
10.04.2011, 19:45 | #25 |
Administrator
|
А можно уточнить? Что все-таки нужно? Хранить некие константные значения в коде (аналогично моему посту выше) и впоследствии на основе их заполнять некие данные или вести работу с набором переменных данных (например, разноска в ГК и классы LedgerVoucherList, LedgerVoucherTransList).
А то создание всяких коллекций, классов-оберток и т.д. актуально больше не для столько для начальных константных данных, сколько для переменных данных (разноска ГК)
__________________
Возможно сделать все. Вопрос времени |
|
10.04.2011, 19:57 | #26 |
Участник
|
Цитата:
Сообщение от sukhanchik
А можно уточнить? Что все-таки нужно? Хранить некие константные значения в коде (аналогично моему посту выше) и впоследствии на основе их заполнять некие данные или вести работу с набором переменных данных (например, разноска в ГК и классы LedgerVoucherList, LedgerVoucherTransList).
я не очень понимаю в чем выбор между твоими вариантами. да, нужно предоставить программисту (!) удобный механизм для заполнения набора начальных статичных константных данных. чтобы в дальнейшем что-то делать с этими данными. причем, заполнение набора может проводится как в одном методе, так и в нескольких. например, часть добавляется (или убирается) в методах-потомках. |
|
10.04.2011, 20:08 | #27 |
Участник
|
Цитата:
Сообщение от sukhanchik
аналогично моему посту выше)
вот суть: вариант "хранения в коде" сводится к варианту fed - создать таблицу и инициализировать ее в коде. вариант хранения в ресурсах не рассматривался. спасибо. итак - аксапта. есть следующие способы хранения статичного набора начальных данных.
|
|
10.04.2011, 21:48 | #28 |
Administrator
|
Поясню.
1. Задача создания закладки "Номерные серии" в параметрах модуля. Пользователь ничего не вводит, однако ему выводится некая таблица (грид) значений, которые на самом деле хранятся в коде (контейнер контейнеров, классы, временная таблица - неважно). Важно, что при изменении соответствующего куска кода - данные в этой таблице должны меняться. В этом случае мне нравится (в порядке убывания): - вариант таблицы (лучше постоянной - как с номерными сериями) - вариант XML (в памяти) - вариант контейнера контейнеров не нравится вариант класса классов или Set (Types::Class) - т.к. слишком много кода 2. Задача создания разноски в ГК. Тут нет начальных константных данных, однако по входящим данным генерируется некоторый набор записей. Генерируемый набор может быть представлен как набор экземпляров классов (Set Types::Class). Важно - что нам не нужно хранить в классах параметры, т.е. многие параметры входящие В этом случае мне нравится (в порядке убывания): - вариант класса классов (на худой конец Set Types::Class) - вариант таблицы (лучше временной, как промежуточной, хотя может даже лучше и постоянной - т.к. все равно откат произойдет, если не закроется транзакция) не нравится вариант XML (сложность реализации) и контейнера контейнеров / Map / Set / List (нечитабельный код) PS. Упс... ответ уже получен - пункт 1. Но все равно - мнение свое выскажу
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 10.04.2011 в 21:52. |
|
10.04.2011, 22:22 | #29 |
Administrator
|
Не... это плохой пример инициализации. Создается ощущение, что нужно писать много кода в куче в одном месте.
Вот хороший пример: Каждый наследник заполняет только "свою" часть настроек. Пример из жизни. Мы оказываем складские услуги сторонним организациям. Мы используем АХ. Каждый клиент присылает документ об отгрузке / приемке в электронном виде и каждый в своем формате. Задача хранить параметры импорта в разрезе форматов данных (на самом деле еще и в разрезе клиента). При этом параметры у каждого формата могут быть разные (типы разные) и количество их также может быть разным. Создаем механизм, аналогичный номерным сериям. Создаем наследника на каждый тип формата данных. Т.о. в коде у нас создаются записи, каждая из которой отвечает за свой параметр. Какие-то параметры (к примеру, каталог импорта / экспорта) у нас будут общие для нескольких форматов данных => соответствующие строки из метода loadModule можно перенести в родительский класс. Данное решение не учитывает AIF или какие- еще технологии и я не собираюсь обсуждать в этой ветке плюсы и минусы решения поставленной задачи именно такой реализацией. Однако, я хотел привести пример использования на практике идеи закладки "Номерные серии" как пример заполнения таблицы данными из кода.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 10.04.2011 в 22:26. |
|
11.04.2011, 00:41 | #30 |
SAP
|
Цитата:
класс-классов - полный контроль, но писать блин много. хотя, гуру утверждают, что окупается.
|
|
12.04.2011, 12:03 | #31 |
Участник
|
Как мне кажется, вопрос о способе записи статических данных "вообще" в отрыве от способа использования этих самых статических данных - не имеет смысла.
Ну, например, разработчики Axapta может и хотели бы хранить данные о номерных сериях в виде контейнеров, но ведь использоваться-то они будут как записи таблицы. Так зачем же вводить промежуточные структуры, если в конце концов все-равно придется создавать записи? Ну, так сразу и создаем. Т.е. способ дальнейшего использования этих самых статических данных собственно и определяет способ их задания. Все остальные соображения тут же отходят на второй план. Кроме того, меня несколько удивляет акцентирование внимание на контроле типов данных. Это ты сам себе не доверяешь? Ну, в худшем случае, получишь ты ошибку не на этапе компиляции, а на этапе исполнения. Или написанный код предварительно не тестируется? А почему, собственно, надо контролировать только тип и не надо контролировать значение? Ведь тоже возможна ошибка! Т.е. контроль типов не то чтобы лишнее требование, но, скорее, из разряда приятных, но не обязательных бонусов. Есть - хорошо, нет - не очень-то и нужно... |
|
12.04.2011, 12:40 | #32 |
Участник
|
Цитата:
я говорил о наборе пар <таблица, поле> для редактирования query. я предполагал что-то сугубо внутренне-программистское. такое что не дается пользователю. и сам себе не доверяю - особенно если буду добавлять/изменять что-нибудь через несколько месяцев. и не доверяю другим программистам - которые будут добавлять/изменять что-нибудь после меня через некоторое время. а главное - хочу иметь штатный механизм с контролем, который использовали бы другие, а я при добавлении/изменении не запорол бы их работу. Цитата:
Цитата:
Конечно же надо контролировать значение - "скажи как". И мне нравится этот переход на личности: "раз у тебя код не тестируется, поэтому зачем тебе контроль начальных данных?" ============== В контейнерах нет контроля ни типа, ни значения. Я спрашивал - есть ли механизм который контролирует хотя бы тип? Мне ответили - только создавать свои классы (но достаточно трудоемко) Мало того, контейнер уж очень неповоротливая структура (хоть и легкая в использовании) Но в стандартном коде повсеместно используются контейнеры. А какого-то промежуточного/смешанного способа нет - либо контейнеры, либо классы |
|
12.04.2011, 12:57 | #33 |
Участник
|
Я думаю важнее иметь контроль типов не в смысле контроля атомарных типов данных, а в смысле контроля самой структуры данных. Поясню. Например, если форматом хранения является контейнер сложной структуры (контейнер контейнеров), то очень просто можно запутаться в количестве параметров и порядке их включения во вложенные контейнеры. Здесь контроль типов данных нужен для того чтобы помочь разработчику сопоставить значение соответствующему параметру, а не для того чтобы предотвратить потерю точности при преоброзовании real в int.
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
12.04.2011, 13:20 | #34 |
Участник
|
Не смертельная. Учитывая удобство, можно и потерпеть. Особенно если не смешивать record'ы и int'ы в одном контейнере.
по теме: зависит от. контейнеры, Код: container fields;; fields = [[#CustAccount, custTable.custAccount], [#CustId, custTable.accountNum], etc]; for(i=1;i<=conlen(fields);++i){ [bookmark, value]=conpeek(fields,i); excelDocument.insert(bookmark, value, #worksheet); Код: void initQuery(){; query = new Query(querystr(aotquery)); postInitQuery(); //наследники могут делать грязную работу здесь, не перекрывая initQuery() Код: void initQueries(){; for(i=1;i<N;++i) query = new Query(querystr(aotquery)); this.postInitQuery(query); this.addQuery(query);//здесь хук для инициализации легче сделать чем super() в DerivedClass.initQueries() Код: myClass = myClass::construct(/**/); myClass.parmQuery().dataSourceTable(xx).range(...); Последний раз редактировалось mayk; 12.04.2011 в 13:22. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
12.04.2011, 14:41 | #35 |
Участник
|
Цитата:
Это очень показательный пример того, что без знания цели, выбор "идеального" средства - бессмысленное занятие Цитата:
Цитата:
Ведь насколько я понимаю, Вы не ставите задачу проверки значения не потому, что это невозможно "в принципе". Как раз-таки очень даже возможно. Просто Вы понимаете полную бессмысленность этой задачи. Однако контроль типов Вам не кажется бессмысленным. Почему, собственно? Только потому, что это относительно просто? |
|
12.04.2011, 17:58 | #36 |
Участник
|
Цитата:
проекты могут быть импортированы в среду, где таких таблиц нет. другой вариант: дев и продакт системы. в дев таблицы и поля есть, а в продакт еще не перенесли. или вот так: Несколько AOS: синхронность изменения объектов Цитата:
Цитата:
Сообщение от Владимир Максимов
Ведь насколько я понимаю, Вы не ставите задачу проверки значения не потому, что это невозможно "в принципе". Как раз-таки очень даже возможно. Просто Вы понимаете полную бессмысленность этой задачи. Однако контроль типов Вам не кажется бессмысленным. Почему, собственно? Только потому, что это относительно просто?
Последний раз редактировалось mazzy; 12.04.2011 в 18:16. Причина: добавил ссылку на соседнюю ветку. |
|
12.04.2011, 18:17 | #37 |
Участник
|
Я бы может генерил бы на основе таблиц и полей, или классов (метаданных)
XML формы для ввода, что то вроде ASP.net или веб сервис, и не программист мог бы вводить данные с привязкой к метаданным (не по id а возможно символьно) а потом умный парсер, преобразовывал бы стрктуру XML и заполнял бы те данные для которых есть таблицы поля классы, или настроил бы генерить ошибку если не вся структура подгружена, или же частично загружать не выкидывая ошибок. можно было бы сделать веб сервис поставщик данных, на основе того что вводят не программисты. в веб поля которые генерятся на основе дев метаданных. Последний раз редактировалось Evgeniy2020; 12.04.2011 в 18:25. |
|
12.04.2011, 19:41 | #38 |
Участник
|
Цитата:
Сообщение от mazzy
легко. здесь выкладывают проекты.
проекты могут быть импортированы в среду, где таких таблиц нет. другой вариант: дев и продакт системы. в дев таблицы и поля есть, а в продакт еще не перенесли. или вот так: Несколько AOS: синхронность изменения объектов Можно привести еще варианты, когда при вводе констант (статических данных) действительно необходим дополнительный контроль типов этих самых констант? |
|
12.04.2011, 20:22 | #39 |
Участник
|
К слову
Цитата:
В Ax2012 как MFP уже рассказывал все ID выделяються отдельной инсталяцией. То есть tableNum(InventTable) != tableNum(InventTable) на разных машинах в числовых значениях. Это я к тому что в мета данных вне Ах хранить числовые значений не стоит.
__________________
Thx, Ievgenii Korovin| Dynamics Ax SCM| Microsoft Corp| http://blogs.msdn.com/DynamicsAxSCM/ |
|
12.04.2011, 20:53 | #40 |
Участник
|
Цитата:
Цитата:
код цвета, тег html, шрифт, размеры шрифта, GUID, MAC-адрес, ip-адрес, адрес сайта в интернете, параметры границы, размеры окон по умолчанию, avi-файл отображения в progressBar, фигуры для тетриса, список начальных вопросов-ответов для Элизы, а также любые другие константы, например из аксаптовских макросов. тысячи их. |
|
Теги |
как правильно |
|
Похожие темы | ||||
Тема | Ответов | |||
Загрузка начальных данных | 1 | |||
Набор данных на лету | 15 | |||
Прогноз роста базы данных и выбор топологии системы, Как правильно расчитать возможный рост | 0 | |||
Введение в Аксапту | 0 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|