|
![]() |
#1 |
Участник
|
Цитата:
Максим, а почему это проще/предпочтительнее для разработчика? Может быть я чего не знаю? Можно я повторю вопрос: "кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?" |
|
![]() |
#2 |
Боец
|
Цитата:
Сообщение от mazzy
![]() О! и поэтому программист теперь должен работать не с одним классом, в котором присутствуют все переменные, а с целым набором классов, в котором все равно будут эти же переменные (но разбросанные по коду)? и к тому же через assert/invoke и methodstr?
Максим, а почему это проще/предпочтительнее для разработчика? Может быть я чего не знаю? Можно я повторю вопрос: "кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?" Цитата:
Routing tasks to the .NET Common Language Runtime (CLR) environment.
Цитата:
может, кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?"
Последний раз редактировалось DSPIC; 28.03.2013 в 11:25. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#3 |
Участник
|
Цитата:
![]() |
|
![]() |
#4 |
Участник
|
Цитата:
Зато - не будет переменных и кода, который генерирует интерфейс - не будет макросов и кода для упаковки распаковки Цитата:
и к тому же через assert/invoke и methodstr?
Цитата:
Максим, а почему это проще/предпочтительнее для разработчика? Может быть я чего не знаю?
Цитата:
Можно я повторю вопрос: "кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?"
- программист хочет ускорить работу за счет удобного распараллеливания |
|
![]() |
#5 |
Участник
|
Анекдот:
- Внученька, у меня в молодости была только одна любовь: морячки. Максим, ты заметил, что в утверждении смешал множественное и единственное число? Если переменные (множ. число) будут в (одном) контракте, то это ничем не отличается от существующего подхода. Если каждая переменная (ед.число) будет в своем контракте, то никак нельзя сказать, что переменные в одном месте - они в разных контрактах Ну, Максим... Ну, елы-палы. ![]() почему программист почувствует себя счастливым от этого? автогенерация интерфейсов подходит только для тривиальных случаев. С которыми замечательно справляется и runbase ![]() Именно ради этого все и затевалось? ![]() О! Ты ведешь себя как 1Сники в дискуссиях. Во-первых, чего ты на меня то стрелки переводишь? Во-вторых, а чего ты тему меняешь? Мы говорим о Фреймворке. Я конечно отвечу. Но предупреждаю сразу: категорически отказываюсь обсуждать "проблемы исследования кода" в этой ветке. Примеры: * отчеты, основанные на runbaseReport * идиотские invoke-вызовы в русском модуле "Налоговый учет" * кретинские invoke-вызовы в русском модуле "Расчеты с персоналом" * масса invoke-вызовов в ax2012. конкретных примеров уже не помню. знаю только, что постоянно спотыкаюсь. Примеры, где invoke-вызовы оправданы: * модуль "конфигуратор продукции" пожалуйста, давай в этой ветке обсуждать Framework. если хочешь обсуждать "проблемы с invoke-вызовами" открывай новую ветку. |
|
![]() |
#6 |
Участник
|
Цитата:
Цитата:
почему программист почувствует себя счастливым от этого?
Отсутствующий код не надо читать, не надо разрабатывать, не надо апгрейдить на следующие версии/севиспаки (кстати, сравни сколько надо мерджить в ранбейз по сравнению с SysOperationFramework - фактически только декларацию одной переменной на параметр - метод со всеми причиндалами сам смёрджится за счет слоев). Нельзя забыть добавить переменную в список созраненных. Нельзя случайно написать другой тип у DialogField чем у переменной. Нельзя забыть получить значение поля или поменять при копипасте код, получая значения не того поля. Цитата:
автогенерация интерфейсов подходит только для тривиальных случаев.
![]() Цитата:
С которыми замечательно справляется и runbase
![]() Цитата:
Именно ради этого все и затевалось?
![]() Цитата:
О! Ты ведешь себя как 1Сники в дискуссиях.
Во-первых, чего ты на меня то стрелки переводишь? Цитата:
"проблемы исследования кода" в этой ветке.
- А что сказал папа - Мат пересказывать? - Нет - Ну тогда он промолчал" ок забьем, остаются проблемы переименования - вроде при использовании classStr/methodStr у переименователя есть вся информация о том что надо переименовывать. Цитата:
пожалуйста, давай в этой ветке обсуждать Framework.
Последний раз редактировалось belugin; 28.03.2013 в 18:54. |
|
|
За это сообщение автора поблагодарили: EVGL (3). |
![]() |
#7 |
Участник
|
Цитата:
Сообщение от belugin
![]() Отсутствующий код не надо читать, не надо разрабатывать, не надо апгрейдить на следующие версии/севиспаки (кстати, сравни сколько надо мерджить в ранбейз по сравнению с SysOperationFramework - фактически только декларацию одной переменной на параметр - метод со всеми причиндалами сам смёрджится за счет слоев).
Нельзя забыть добавить переменную в список созраненных. Нельзя случайно написать другой тип у DialogField чем у переменной. Нельзя забыть получить значение поля или поменять при копипасте код, получая значения не того поля. что-то я не увидел такого. Может плохо прочитал. |
|
![]() |
#8 |
Участник
|
![]() Цитата:
См табличку: Dialog Base getFromDialog putToDialog pack unpack | Base functionality implemented by the framework. run Implemented by the base framework. Handles marshaling execution to a CLR session Соответственно нет кода, а раз нет кода - нет проблем. Вообще у меня получился более минималистичный пример: Контракт X++: [DataContractAttribute] class TEST_HelloContract { Name name; } [DataMemberAttribute] public Name parmName(Name _name = name) { name = _name; return name; } X++: class TEST_HelloOp { } void sayHello(TEST_HelloContract _contract) { info(strFmt("Hello %1", _contract.parmName())); } \Menu Items\Action\TEST_Hello
И всё - никаких методов main, dialog, pack, unpack, макросов, extendedTypeStr и прочего. Я немножко наврал - тип таки дублируется у переменной и метода, но хотя бы их совместимость контролируется компилятором. Единственное что, к сожалению, параметры из не попадают в перекрестные ссылки (но никто не мешает их допилить, чтоб попадали). А еще плюс, что по умолчанию у нас есть программный интерфейс для операции - никто не мешает вызвать ее из другого кода без модификаций Последний раз редактировалось belugin; 28.03.2013 в 22:53. |
|
|
За это сообщение автора поблагодарили: mazzy (2), alex55 (1), S.Kuskov (3). |
![]() |
#9 |
Administrator
|
Цитата:
Цитата:
Сообщение от belugin
![]() Глава "SysOperation sample: SysOpSampleBasicController"
... Соответственно нет кода, а раз нет кода - нет проблем. ... И всё - никаких методов main, dialog, pack, unpack, макросов, extendedTypeStr и прочего. ... А еще плюс, что по умолчанию у нас есть программный интерфейс для операции - никто не мешает вызвать ее из другого кода без модификаций - внедренцев, когда они "вводят в строй" нового разработчика. А имеется достаточно большой соблазн купить программиста подешевле, но которого надо "вводить в строй", плюс у некоторых внедренцев существует весьма частая ротация кадров, что приводит к постоянному состоянию "ввода в строй" разработчиков. - клиентов, когда они набирают к себе либо слабых специалистов, либо новичков, но при этом требуют от исполнителя выполнить задачу "здесь и сейчас и быстро". - аутсорсеров / фрилансеров, у которых есть интерес только в своей задаче и которым неинтересно создание системы классов, какого-то большого и красивого кода. Вплоть до того, что решением задачи может быть джоб с пунктом меню на себя. Ну т.е. конечно всем на словах понятно - что чем сложнее система - тем больше требуется мозгов, чтобы ее поддерживать или в ней кодить. И конечно это согласуется с политикой Microsoft в том, что АХ переориентируется на систему уровня SAP. Просто очень хочется отметить слова fed Цитата:
Сообщение от fed
![]() Я бы главную проблему DAX2012 сформулировал так: Разработчики (в широком смысле) в MS не понимали что их продукт, на проектах, будут переписывать люди, у которых значительно меньше времени и значительно шире специализация чем у сотрудников MS.
Все остальное - лишь проявление этой проблемы... Возьмем к примеру пользовательский интерфейс. Его ж кто-то продумывает; есть команда, который этот UI рисует. Вот тут нужно что-то подобное, но для разработчика, чтобы он был мотивирован перейти на новую технологию. Конечно хорошо, когда количество копируемого кода будет меньше. Но при этом в мозгах у разработчика должно быть четкое понимание того, что так будет и так будет проще как писать, так и поддерживать. В частности, поэтому и жуть как полезны перекрестные ссылки.
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#10 |
Участник
|
Ага. Спасибо. Теперь боль-мень понятно что именно добивались.
Хотя твой пример категорически отличается от того, что в книжке. Кроме того, текст с названием метода в параметре menuItem - это еще один вариант пушного зверька. Ну, и у меня: 1. нажатие на кнопку Ок приводит к ошибке (скриншот 1) 2. добавление новой переменной в класс-контракт не приводит к появлению нового элемента в диалоге (см. скриншот 2) 3. изменение типа Name на Description не приводит к изменению Label и StatusText (см. скриншот 2) Подозреваю, что 2 и 3 из-за того, что я нуб и опозорился. Но пока все равно выглядит примерно так: ![]() вполне возможно, что это я чего-то не понимаю. Последний раз редактировалось mazzy; 29.03.2013 в 11:47. Причина: добавил проект |
|
![]() |
#11 |
Участник
|
|
|
![]() |
#12 |
Administrator
|
Цитата:
С т.з. оптимизации времени написания кода - любая технология по программированию проигрывает технологии Copy & Paste Ну т.е. никто никогда не пишет наследника RunBase "с нуля". Все - копируют с уже существующего примера (класса). Т.о: - Программисту без разницы - сколько кода - ему важно подправить в нескольких местах. А в двух или трех - это уже неважно. - Программисту без разницы макросы это или не макросы, если они поддаются копированию и их можно скопировать не думая. - Программист не любит писать 100 раз одно и тоже. Но скопировать код ему гораздо проще, чем создавать с нуля. Поэтому по факту код будет 100 раз растиражирован. Только не написан заново, а скопирован и выполнены мелкие правки. - Программисты внедренца далеко не всегда задумываются о производительности, т.к. отладка происходит на условиях, оторванных от жизни (в лучшем случае - есть демо-данные; в худшем - они сами из головы выдумываются этим же программистом). Все высокие разговоры о том, что код нужно не копировать, а делать единым и потом наследовать разбиваются о жестокую реальность, в которой заказчик не хочет тратить лишнее время на причесывание кода, а разработчики не могут / не хотят (нужное подчеркнуть) заниматься этим причесыванием, ибо незамотивированы (а чем мотивировать, если даже в этой ветке нет явного ответа на вопрос Почему?) В конце концов - будут или наследники RunBase или контракты или еще какие-то фишки - все сведется к инструкции для начинающего: Откопируй такой-то код и внеси тут изменения сюда и сюда.
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#13 |
Модератор
|
Цитата:
Сообщение от sukhanchik
![]() Вот тут есть одна очень маленькая, но ключевая деталь.
С т.з. оптимизации времени написания кода - любая технология по программированию проигрывает технологии Copy & Paste Ну т.е. никто никогда не пишет наследника RunBase "с нуля". Все - копируют с уже существующего примера (класса). Т.о: - Программисту без разницы - сколько кода - ему важно подправить в нескольких местах. А в двух или трех - это уже неважно. - Программисту без разницы макросы это или не макросы, если они поддаются копированию и их можно скопировать не думая. - Программист не любит писать 100 раз одно и тоже. Но скопировать код ему гораздо проще, чем создавать с нуля. Поэтому по факту код будет 100 раз растиражирован. Только не написан заново, а скопирован и выполнены мелкие правки. - Программисты внедренца далеко не всегда задумываются о производительности, т.к. отладка происходит на условиях, оторванных от жизни (в лучшем случае - есть демо-данные; в худшем - они сами из головы выдумываются этим же программистом) Образец мышления поколения Copy-Paste приведен прекрасный: один раз слажали, в двадцать мест скопировали, через год обнаружили. Чешем репу. Вывод? Очевидный - СИСТЕМА Г###О!
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#14 |
Участник
|
|
|
![]() |
#15 |
Участник
|
|
|
Теги |
ax2012, runbase, runbasebatch, sysoperation framework |
|
|