LSVleonmbsавтоматическая генерация интерфейсов - чушь
Во первых эти интерфейсы будут убогими что противоречит нынешним UI/UX трендам.
если задавать кучу настроек и параметров - задание такого интерфейса будет весьма трудоемким что не оправдает суть идеи.хм....не соглашусь. Почему убогими ? Если ГУИ хорошо выполняет свои задачи, то что с ним не так ?
Важный вопрос. Программист может наваять что угодно, но пипл не купит, потому что выглядит как УГ. А другой программист наваяет в сто раз хуже, но при помощи дизайнера выдаст няшную картинку. Вопрос - у кого будет профит? Как минимум на рынке массовых "обычных" (т.е. весьма ограниченных) юзеров профит будет у рисователя картинок.

Суть проблемы - функционал ничто рядом с няшностью (броской вняшностью). Или всё совсем наоборот? Зависит от целевой аудитории. Массовая аудитория покупается именно на вняшность.

Никанор КузьмичМогу предложить к обмену свои познания в оракле (SQL, PL/SQL, APEX). Приму в дар знания по Spring Boot, HTML/CSS/Javascript. Ну и просто так потрепаться тоже можно.
А расскажите, что за хрень этот APEX? На сколько гибко работает? На сколько легко можно отмапить граф классов на произвольный UI? Как валидация организована? Доступна ли множественность отображения типа на UI element? Как переходы делать между кастомными структурами и стандартными элементами UI типа списков, деревьев и т.д.? Можно ли отчёты мышой ваять? Можно ли накидать типы на панель и что бы этот APEX сам все связи просчитал и SQL построил? Можно в генераторе отчётов задавать произвольно связи между клетками и запросами? А потом ещё и связывать несколько таких клеток, как например в случае суммирования (ну и вообще агрегирование, но не только)?

Ну и спрашивайте по своим интересам чего вам там непонятно. Поясню чего сумею.

Агнец за бортомВсё SQL-запросами. Это всё, что нужно было знать.
То есть продолжение старого убогого Oracle Forms? А по рекламе я думал там что-то приличное...

Никанор Кузьмич
Спасибо за детали. Ожидал от этих недоумков много большего к 2017-му году, но они так недоумками и остались...
Никанор КузьмичАутентификация в Spring Boot интересует. Моя благодарность не будет иметь границ (в пределах разумного).
А какая конкретно проблема у вас с этой аутентификацией? Первый же запрос гуглу выдаёт кучу обучалок типа таких - Securing a Web Application , Build a Spring Boot App with User Authentication .

По сути аутентификация ведь есть просто проверка пароля с юзером. Всё остальное есть по сути бизнес-логика, которую каждый ваяет как ему вставляет. И вот этот спринг (точнее его девелоперы) прониклись старыми идеями декларативной разметки ролей и прочих прав доступа. Примерно то же давно реализовано в ежабях. Ну а как конкретно наворотили спринговые девелоперы туманно представляемый ими процесс аутентификации - тут да, тут надо копать их исходные тексты, а то ведь поганцы одной рекламой вместо документации кормят. Документация у них, конечно, есть, но весьма краткая по части глубин реализации, поэтому остаётся только читать ихние обучалки для детей младшего школьного возраста и пытаться по ним что-то понять. Но суть всё равно та же - они вам предлагают готовый механизм, который работает не так как вам надо, а так, как они считают нужным. Собственно и весь спринг есть сборная солянка таких вот изысков, показавшихся кому-то из разрабов удобными. Как по мне, ну его нафиг этот навязываемый вам чужой стиль жизни. Если кому-то нравится извращаться - ну пусть он где-то там в сторонке этим занимается. А вместо этого извращенцы громко кричат на всех углах - мы крутые, скачай, посмотри, это легко! И правда - простейшие задачки делаются легко, но только потому, что под эти задачки давно написана куча кода. А вот чуть в сторону - всё, либо ихние исходники модифицировать (а перед этим с годик в них поразбираться бы ещё), либо заниматься ремонтом миндалин через анальное отверстие (то есть пытаться адаптировать свои потребности под негибкую реализацию).

Я после многолетнего траха со всеми этими изобретателями удовлетворился очень простым набором средств, но большей частью самописных. Зато теперь достаточно одного томкэта и JVM - и хоть космическую программу автоматизируй. А то ведь пока самостоятельно дойдёшь до понимания изливающегося на нас мутного потока интернет-технологий - так ведь и помереть от старости можно. Попробуйте начать всё же с EJB 3.х - по ним документация более вменяемая, ту же JPA на них поймёте, декларативные транзакции, ну и аутентификацию. И этого в общем-то вполне достаточно для очень многих задач. Ну плюс веб, конечно же. По вебу рекомендую GWT и банальные JSP+Servlets. Там всё просто до безобразия, особенно если дописать малость самому.

Хотя если работодатель вам заявляет - хочу сприг - ну что-ж, пилите Шура, пилите. Я тоже на подобных ролях в своё время отсидел.

Никанор КузьмичВ первом методе задаются два запроса. Один возвращает имя пользователя и пароль (для проверки правильности пароля), второй запрос возвращает роли пользователя, которые можно указать во втором методе. Но, как я понимаю, все эти методы отрабатывают на старте один раз, а потом? Например, если в процессе я захочу изменить логику? Или добавятся новые роли?
Ну это же обычные properties (настройки то есть). Настройки читаются один раз и далее применяются до самой смерти программы. А если вы захотите их изменить - добро пожаловать в перезапуск софтины. До перезапуска настройки обычно не перечитываются. Но теоретически в глубинах спринга есть доступ к этим настройкам. Вопрос только - вынесен ли он наружу через API. Здесь нужно джава-доки смотреть по конкретному классу из вашего примера. Если у класса есть сеттеры, значит менять можно. Но далее вас ждёт вторая проблема - где взять экземпляр этого класса. Надо опять в джава-доках искать способы найти этот объект. Можно его закешировать в самом начале, но иногда даже это не помогает - бывают всяческие взаимосвязи и если изменить в одном месте, и не изменить в другом - будет косяк. В общем в полный рост перед вами проблема плохой документации. Хотя может я и придираюсь - посмотрите сами здесь и здесь .

Есть ещё немного с другой стороны заход - все эти properties являются обычными для спринга бинами, то есть обычный (вроде бы) джава класс, но с интересным жизненным циклом. Вся ахинея в спринге именно вокруг бинов построена. Поэтому они там навороченные, сами читаются, записываются, копируются, конвертируются и т.д. Но вот эта вся самостоятельность оставляет вам минимум места для гибкости. Хотя опять же - если найдёте в доках конкретно по вашему случаю описание - наверняка сумеете как-то вывернуться. Только доки там, ещё раз повторюсь, весьма сокращённые и ориентированы на стандартный для малолетних школьников процесс - делай так, только так, и никак иначе, а почему - не твоего ума дело, за тебя умные люди подумали. А на самом деле эти умные люди просто сочинили вариант, который им лично нравится. Но подходит ли он другим - большой вопрос. Но тем не менее - про бины тоже почитайте, может поможет.
Никанор КузьмичВ документации написано, что он должен иметь ровно один параметр (имя пользователя). А если я хочу сделать более сложную логику, чтобы запрос имел пару-тройку параметров?
Дети не должны задавать глупых вопросов. Детям сказано - делай так. Значит нельзя по другому. Так умные девелоперы решили.

То есть вы столкнулись с негибкостью. Оно сделано вот так и всё. Возможно, что альтернативы есть, но опять же - надо просканировать мегабайты всяческих доков и примеров для того что бы альтернативу найти.
Никанор КузьмичЕсть еще куча примеров, где используются классы с именами что-то вроде UserDetailService, какойтотамAuthenticationToken и прочие, но я плохо понимаю вообще, какую задачу там пытаются решить с их помощью.
И не нужно понимать. Задача этих доков заставить школьников делать так, как дяди придумали. Это вообще такая тенденция в мире - винтики должны винтить, а куда винтить - им укажут.

А что бы всерьёз понять - надо исходники качать и побегать по ним месяцев несколько. К сожалению таких деталей в современной документации нет. Это как айфон - нажмёшь на кнопку - зазвонит. А если хочешь большего - ты плохой потребитель.
Никанор КузьмичБольшое преимущество апекса в том, что чтобы приложение хоть как-то заработало, вообще не надо уметь программировать. В тех случаях, когда надо быстро, дешево и сердито, альтернатив ему нет.
Это "дёшево и сердито" было создано лет 20-25 назад. И вот за 20-25 лет НИЧЕГО не изменилось (ну кроме переноса в браузер).
Никанор КузьмичСпринг бут мне насоветовал знакомый джавщик. Я ему рассказал про свою идею, он ответил - "в спринг буте есть всё". Он вроде на джаве давно программирует, но со спрингом не работал, сам только недавно начал изучать, поэтому на все мои вопросы отвечает "ну там же все в доке есть". Вот, мыкаюсь помаленьку.
В принципе, если вы в джаве ноль, то на спринге учиться как-то слишком хардкорно. Надо с чего попроще начинать. Хотя если сумеете прогрызться через идиотскую документацию, да ещё в исходниках покопаетесь - ну тогда возможно всё.

Никанор КузьмичЕще бы найти человека, который уже через все это продрался и сказал бы "не ходи туда" или "вот за этим - ходи, а за этим - не ходи".
Этот человек скажет - ходи на Java форумы по спрингу. Но там тоже народ однобокий - кто какую часть в проекте использует, тот только её и знает (обычно).
Никанор КузьмичВот конкретно в этом случае я бы хотел сначала понять, что именно дяди придумали. Потому что некоторые их задумки меня вполне устраивают (например JdbcTemplate или аннотация RequestMapping). А вот некоторые (как та же аутентификация) я пока недостаточно понимаю, чтобы сказать "да" или "нет".
Дяди придумали так называемые POJO (plain old java object). В чём прикол этих POJO? Очень просто - с ними можно нажать точку на клаве и далее через вываливающиеся списки ходить куда угодно по сколько угодно сложному графу связей. То есть банально упрощается работа со сложными структурами. И вот возведя в идеал простые классы (только сеттеры и геттеры), умные дяди наумничали страшный фрэймворк вокруг наполнения сеттеров реальными данными. Начинали они с XML, потом перебрались в конфигурирование на Java, ну а параллельно решали все насущные вопросы веб- и энтерпрайз-разработки. В результате у них набралась огромная куча функционала, которую они решили назвать "спринг". Но систематизировать кучу дяди не сумели. То есть оно им по сути не надо, потому что они же и так знают, как и что работает. А вот всем остальным приходится продираться через написанную ленивыми дядями документацию. И без внятной документации вы скорее всего убьёте много больше времени на попытку понять что и как по сравнению с банальным написанием того, что вам нужно самостоятельно.
Никанор Кузьмичболее-менее понимаю что-то
Ну я тоже в кулинарии что-то понимаю :)
Никанор КузьмичЧем больше добавляешь гибкости, тем меньше это похоже на конфигурирование и больше на программирование. Выбирать в итоге приходится между N далеко неидеальными системами по принципу "чьи тараканы тебе менее противны".
Да, если вам подход нравится - у вас будет стимул ломать этот хардкор. Но мне такой подход без документации совсем не нравится. Это для любителей проходить квесты с головоломками.

Petro123Спринг появился как альтернатива EJB и JavaEE.
Сейчас ОБА этих направления используются. Поэтому говорить что лучше и что хуже, глупо.
Это как винда и линукс. И спор что лучше.
Спор "что лучше" всегда полезен. Бесполезен только уход в безумный спор.

Ну а EJB и JavaEE во времена рождения спринга действительно выглядели убого. EJB 2.X, а до них были EJB 1.X - вот это реальное убожество. И на таком фоне спринг с их легковесным подходом на основе простых объектов действительно казался интересным. А потом прошло время, JavaEE существенно улучшили, а спринг существенно ухудшился путём вроде бы и полезного создания оптимизированной структуры. Но когда структура сложная, надо её очень подробно документировать, а фанаты спринга на это болт забили (ну да, просто лень, деньги делать надо, а тут какие-то бумажки). То есть господа-ленивцы создали ситуацию необходимости изучения высшей математики без предварительного разжёвывания обычной математики. Ну и постепенно их математика умрёт в забвении.
Petro123тут лучше в профильный топик ЯП, т.к. там будут противоположные мнения.
Наверное да, но гуёвый софт как раз на GWT и Servlets+JSP делается.

Petro123APEX это не forms.
И продукт не плохой по сабжу-теме

Да forms это, только прикрученный к вебу и за 20 лет немного облизанные и причёсанные. Фильтры по столбцу ещё на фокспре писали, и агрегирование и прочие плюшки. Вот только графики добавили, но тут уж извините - фокспро тогда в текстовом режиме работало. Но что интересно - гуёвые приложения именно на фокспре и в текстовом режиме одной мышой уже тогда можно было ваять. Так что граждане ораклисты отстали от жизни лет на 25, а то и на 30.

Petro123Счас мейнстрим клиент делать на JS а бэк на Java.
vaadin, например.

Petro123 Что форм ругали я согласен, но вот на APEX гнать не надо. Я проект на нём делал и говорю что проект достойный.
Аналогов его нету. Тогда об чём разговор?
Вверху скрин. Можно разговаривать конкретно.
VipRoss (вроде) тут свои достижения по автоматической генерации приложений демонстрировал. Ну и другие тоже. Пошире оракла получается. И сравним количество бабла на брата. Отсюда мораль - оракл есть не просто отстой, но даже в отстой не годится.

Никанор КузьмичНо этот подход считается "не труЪ", чтобы было труЪ, я должен выучить javascript, выучить какой-нибудь фреймворк, чтобы потом получить ... что? Какие преимущества даст этот подход?
Да никаких преимуществ. Всё субъективно. Кому-то нравится лабать быстро и не думая. Ну пусть и дальше лабают. Каждый раз будут одну и ту же формочку снова делать. А Java даёт нам АРХИТЕКТУРУ. И вот с ней можно один раз формочку сваять, а потом просто экземпляр создавать. Так что отстой эти все нетипизированные скрипты. Ну а нативный доступ к браузеру и из GWT и из vaadin есть.