Не замечал тестов в стандартном коде системы, а если бы они были, то их было бы запрещено выполнять.
Сделайте выборку из вьюхи VSEOCLASS с CATEGORY=5. Вот вам тесты в стандарте. Например CL_FDT* — тестовые классы для BRF+.
Или вы имеете ввиду, что в системе нет тестов покрытия?
1) Как указал коллега nmk2002, HowTo настройки смотрелось бы более интересно
2) для меня, как для разработчика, интересен был бы пример использования ЭЦП в своих разработках на ABAP
Сложно прилагать мозг для изучения системы, если официально самостоятельно это сделать нельзя в принципе. Или я что-то пропустил, и уже можно получить тестовую версию системы для самостоятельного ознакомления?
Вот про абап в cloud особенно жизнерадостно было в статье. да. кстати, вот и сама статья scn.sap.com/docs/DOC-41566 (к сожалению, с трубы ссылка не красиво вставляется). Обратите внимание: пишет человек, только что выпустивший на саппрессе книжку «прелести нового абап». Теперь он задается вопросом «а зачем же я ее писал-то?».
Ну и дальше, для решающего «а оно мне надо?», уже следует думать о перспективах системы в целом: это и политические факторы, и направленность вендора на смену принципа с «мы работаем с разными СУБД» на «только haha, только хардкор» и многое другое.
Я искренне удивлен, что этот здравомыслящий комментарий появился только сегодня. Как очень точно подметил коллега на профильном форуме: с появлением «вечернего» абапа, заниматься им стало поздно во всех смыслах этого слова"
Сам язык учится быстро, при наличии заинтересованности у ученика и квалифицированного учителя.Самому платить за курсы можно только родственнику миллионера. При этом, обучаясь в сап за такие-то деньжищи, абитуриент на любые вопросы чуть в сторону от темы курса будет получать ответ «это не является темой семинара, узнать ответ вы сможете на курсе XYX»(прайс вы видели).
Ну и как заметили выше, сам по себе абап никому не нужен. Нужны знания системы в привязке к конкретным модулям.
И это я еще молчу про жизнерадостные статьи на scn с заголовками «сап опять хочет уничтожить абап»
1) К сожалению, мне трудно помочь вам, если вы не способны понять зачем нужны ORM ( Query service это часть реализации ORM в SAP). Попробуйте погуглить, что ли.
3) ADBC — инструмент построения в том числе и динамических запросов
2) Указанные инструменты были перечислены мной в ответ на сообщение AtomKrieg, а не ваше
3) по вашему инструменту я уже все сказал. С моей скромной точки зрения, невозможность юзать журнал использования съедает все мнимые преимущества ваше разработки. Грамотное построение системы программных модулей повторного использования (подпрограммы, ФМ, классы) удобнее, нагляднее и понятнее.
1) мне не нравится не один из указанных подходов. Динамические реализации\вызовы должны быть строго обоснованы. Никакого приличного основания применять описанный в статье подход я не знаю (кстати. забыл про замечательную особенность автогенеренных программ — падение в дамп после 36 генераций в пределах одной сессии. хотя, может быть, в новых версиях пофиксали?)
2) пример использования Query service вам указали выше
3) пример использования ADBC.
1) они менее читабельны в силу отличия от синтаксиса самого языка. А так же по той причине, по которой в языках программирования делают константы: подробный код документирует сам себя. А кроме того, такой подход уничтожает всю прелесть такого инструмента как «журнал использования». Становится очень тяжело понять где же находятся точки изменения переменных в программе.
2) Проверка синтаксиса нужна затем, что бы юзер не любовался на дампы, а мы, как разработчики, обнаруживали ошибки еще на этапе проверки программы. Вот изменилась структура таблицы. Я по журналу использования нашел все места ее использования, и поправил, при необходимости код ее использования. С вашим же подходом — этого не будет.
3) это вы думаете, что не получу. Как верно выше указал Yaruson, в ряде случае вместо бездумного впаивания такого кода, правильнее подумать и использовать что-то другое: начиная от join в его примере и заканчивая готовыми ФМ по чтению стандартных справочников
Я солидарен с Armann. Претензии ровно те же
1) не читабельно
2) динамические вызовы без особой на то нужды — зло (никакой проверки синтаксиса)
3) скорость
Проблема в том, что созданная Вами кнопка в js и созданная в XML view кнопки будут иметь разные ID, не смотря на то, что как кажется Вы их объявили одинаково. В случае XML фреймворк к ID припишет еще и ID самого view, и тогда будет корректно работать код (который используется, в примерах постоянно)
this.getView().byId("MyButton")
а для JS-view в этом разе надо писать
sap.ui.getCore().byId("MyButton")
И только путем неких изысканий удастся узнать, что что бы картина в обоих типах view была одинаковая, в js надо было создавать ID контрола несколько иначе
Все бы хорошо, но между определениями контролов в разных типах view слишком много отличий. Я не нашел исчерпывающий хелп по всем типам описания. Что вдвойне забавно: в описании API как примеры идут js-views, а в мобильный сэмплах- XML-views.
SAP не включил в OpenUI5 библиотеку для рисования диаграмм. Эта библиотека(sap.viz) есть в платной версии(той, которая SAPUI5). Я под капот не заглядывал, но пример использования вот
Сделайте выборку из вьюхи VSEOCLASS с CATEGORY=5. Вот вам тесты в стандарте. Например CL_FDT* — тестовые классы для BRF+.
Или вы имеете ввиду, что в системе нет тестов покрытия?
2) для меня, как для разработчика, интересен был бы пример использования ЭЦП в своих разработках на ABAP
Вот про абап в cloud особенно жизнерадостно было в статье. да. кстати, вот и сама статья scn.sap.com/docs/DOC-41566 (к сожалению, с трубы ссылка не красиво вставляется). Обратите внимание: пишет человек, только что выпустивший на саппрессе книжку «прелести нового абап». Теперь он задается вопросом «а зачем же я ее писал-то?».
Ну и дальше, для решающего «а оно мне надо?», уже следует думать о перспективах системы в целом: это и политические факторы, и направленность вендора на смену принципа с «мы работаем с разными СУБД» на «только haha, только хардкор» и многое другое.
Сам язык учится быстро, при наличии заинтересованности у ученика и квалифицированного учителя.Самому платить за курсы можно только родственнику миллионера. При этом, обучаясь в сап за такие-то деньжищи, абитуриент на любые вопросы чуть в сторону от темы курса будет получать ответ «это не является темой семинара, узнать ответ вы сможете на курсе XYX»(прайс вы видели).
Ну и как заметили выше, сам по себе абап никому не нужен. Нужны знания системы в привязке к конкретным модулям.
И это я еще молчу про жизнерадостные статьи на scn с заголовками «сап опять хочет уничтожить абап»
3) ADBC — инструмент построения в том числе и динамических запросов
2) Указанные инструменты были перечислены мной в ответ на сообщение AtomKrieg, а не ваше
3) по вашему инструменту я уже все сказал. С моей скромной точки зрения, невозможность юзать журнал использования съедает все мнимые преимущества ваше разработки. Грамотное построение системы программных модулей повторного использования (подпрограммы, ФМ, классы) удобнее, нагляднее и понятнее.
Да-да! Именно эта мысль меня посетила при чтении вашей статьи!
2) пример использования Query service вам указали выше
3) пример использования ADBC.
Правда, много интересного есть в стандартной документации?
Вы знакомы с reference и с generic types? С их помощью вполне можно задавать динамические переменные.
2) Проверка синтаксиса нужна затем, что бы юзер не любовался на дампы, а мы, как разработчики, обнаруживали ошибки еще на этапе проверки программы. Вот изменилась структура таблицы. Я по журналу использования нашел все места ее использования, и поправил, при необходимости код ее использования. С вашим же подходом — этого не будет.
3) это вы думаете, что не получу. Как верно выше указал Yaruson, в ряде случае вместо бездумного впаивания такого кода, правильнее подумать и использовать что-то другое: начиная от join в его примере и заканчивая готовыми ФМ по чтению стандартных справочников
1) не читабельно
2) динамические вызовы без особой на то нужды — зло (никакой проверки синтаксиса)
3) скорость
а для JS-view в этом разе надо писать
И только путем неких изысканий удастся узнать, что что бы картина в обоих типах view была одинаковая, в js надо было создавать ID контрола несколько иначе