Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
А как залогинется в системе?
я что-то нажала и все сломалось
Очень не хватает demo доступа в админку.
А так похвально, я тоже использую свою CMS для создания Web сайтов.
А так похвально, я тоже использую свою CMS для создания Web сайтов.
А в чем прикол показывать страницу логина?
Я тоже могу такую запилить за полчаса…
Демо-доступ в админку был бы интереснее.
Открытый демо-доступ для желающих, к примеру по логину/паролю demo/demo
Я тоже могу такую запилить за полчаса…
Демо-доступ в админку был бы интереснее.
Открытый демо-доступ для желающих, к примеру по логину/паролю demo/demo
И мне плиз скиньте пароль от админки, гляну
Попытался залогиниться, ничего не вводя:
Error code: 500 WELD-001304: More than one context active for scope type javax.enterprise.context.SessionScoped
После этого всегда получаю "Internal server error", как у первого комментатора.
Можно попробовать.
Извините за занудство, но что вы хотели донести этим постом? На хабре, наверное, каждый пятый в свое время писал свою CMS. Кода нет, описания решения интересных технических проблем, возникших во время разработки тоже. Уверен, с опытом более 10 лет вы могли-бы написать что-то более интересное про эту разработку, а не просто заявить о том факте что у вас все благополучно получилось.
Впрочем в тексте в самом начале я писал про цель данного поста. Ничего страшного, я повторюсь. Смысл в том и есть почему до сих пор существует тенденция среди программистов написать свою CMS?
Потому-что бесплатных решений нет с функционалом который позволит собирать сайты как в конструкторе. Все мы знаем ущербность тех билдеров которые есть в Wordpress или Drupal. Плюс ко всему этому добавляется сложная концепция хранения данных, где объекты имеет жесткие структуры, и чтобы их менять нужно собирать новую версию продукта. Да и не особо user friendly управление данными в этих CMS.
Вторая сторона смысла, это развитие программиста как профессионала, она больше психологическая. Что делать когда понимаешь что хочешь сделать продукт от и до, и выдвинуть его на рынок.
Ну и по поводу написать что-то про разработку, я с вами согласен. Это мой первый пост, но есть огромное желание продолжить писать, тем более как вы отметили, мне есть что написать.
А про то что всё благополучно получилось, это вы ошибаетесь, я в тексте об этом не писал. Наоборот все только начинается. В конце есть итог чего я имею. Дальше только развитие и переработка.
Потому-что бесплатных решений нет с функционалом который позволит собирать сайты как в конструкторе. Все мы знаем ущербность тех билдеров которые есть в Wordpress или Drupal. Плюс ко всему этому добавляется сложная концепция хранения данных, где объекты имеет жесткие структуры, и чтобы их менять нужно собирать новую версию продукта. Да и не особо user friendly управление данными в этих CMS.
Вторая сторона смысла, это развитие программиста как профессионала, она больше психологическая. Что делать когда понимаешь что хочешь сделать продукт от и до, и выдвинуть его на рынок.
Ну и по поводу написать что-то про разработку, я с вами согласен. Это мой первый пост, но есть огромное желание продолжить писать, тем более как вы отметили, мне есть что написать.
А про то что всё благополучно получилось, это вы ошибаетесь, я в тексте об этом не писал. Наоборот все только начинается. В конце есть итог чего я имею. Дальше только развитие и переработка.
Свою первую «CMS», а точнее пару скриптов для инклюдов меню, футера, хедера и всего что только можно инклюдить сделал чуть ли не лет 20 назад, посмотрев на PHP-Nuke (и испытав неимоверное отвращение от его логики). И так как альтернатив ему либо ещё не существовало, либо они тоже не зашли. Решил доплыть на своём велосипеде. Так и «плыву». С джумлой, дле, вордпресс и прочим сдружиться у меня не получилось. Боюсь моей CMS всё же быть :(
Хотелось бы услышать советы как не про**** 3 года ещё одной жизни?
— Есть какие-нибудь качественные материалы по архитектуре CMS?
— Без каких фишек современная CMS не способна существовать? (авторизация через сторонние сервисы, 2FA, поддержка 128 символьных паролей из KeePass, встроенный модуль SEO, человеко-читаемые урлы и т.п и т.д). Мало того что я не знаю, что есть из того без чего жить нельзя. Так ещё и есть шансы всё не реализовать. Люди тратят годы… Что необходимо для этого самого Minimal Viable Product?
Я одиночка и за спиной нет команды… К сожалению даже намёков на то, как написать свою CMS в статье я не увидел :( И походу единственный вариант прочитать код существующих CMS. Вот только на это тоже три года уйдёт… А так как они все берут корни из PHP-Nuke, то и читать такое желания ноль.
P.s — Жду demo пароль :)
Хотелось бы услышать советы как не про**** 3 года ещё одной жизни?
— Есть какие-нибудь качественные материалы по архитектуре CMS?
— Без каких фишек современная CMS не способна существовать? (авторизация через сторонние сервисы, 2FA, поддержка 128 символьных паролей из KeePass, встроенный модуль SEO, человеко-читаемые урлы и т.п и т.д). Мало того что я не знаю, что есть из того без чего жить нельзя. Так ещё и есть шансы всё не реализовать. Люди тратят годы… Что необходимо для этого самого Minimal Viable Product?
Я одиночка и за спиной нет команды… К сожалению даже намёков на то, как написать свою CMS в статье я не увидел :( И походу единственный вариант прочитать код существующих CMS. Вот только на это тоже три года уйдёт… А так как они все берут корни из PHP-Nuke, то и читать такое желания ноль.
P.s — Жду demo пароль :)
Кинул в личку пароль. Хорошие вопросы, но боюсь ответы на них получатся объемными и в комментарий все не уместить. Лучше я напишу ответы в следующем своем посте.
Кратко об MVP, по сути это тот функционал который отражает вашу ключевую идею, без как либо деталей в реализации.
По поводу «я одиночка», я в этом вижу проблему. Я один, вы один, и еще куча программистов как мы работают на своей задачей. У меня есть один из пунктов в статье, что я бы хотел сформировать сообщество таких как мы. Хаб людей энтузиастов программистов. Вариантов реализаций много, но по факту нет.
Кратко об MVP, по сути это тот функционал который отражает вашу ключевую идею, без как либо деталей в реализации.
По поводу «я одиночка», я в этом вижу проблему. Я один, вы один, и еще куча программистов как мы работают на своей задачей. У меня есть один из пунктов в статье, что я бы хотел сформировать сообщество таких как мы. Хаб людей энтузиастов программистов. Вариантов реализаций много, но по факту нет.
Если нет четкого понимая того, что вы хотите увидеть, может не стоит пока что свою CMS писать?
Рекомендую сначала присоединиться к разработке какой-нибудь open source разработке, изучить архитектуру. Когда вы будете писать код вы сами увидите где плюсы, а где минусы
Рекомендую сначала присоединиться к разработке какой-нибудь open source разработке, изучить архитектуру. Когда вы будете писать код вы сами увидите где плюсы, а где минусы
Странное замечание. Но я как раз вижу проблему, и все подходы что я использовал в реализации своей CMS, я многое позаимствовал из других проектов с которыми приходилось работать. Именно выбирая то что мне казалось удобной реализацией.
@SubarYsn, мой ответ был не на ваше сообщение, а на сообщение OZR
Я немного про другое. Есть «модель Кано». Кано говорит, когда мы говорим об удовлетворении потребителя, мы должны дать себе отчет, что у потребителя есть желания (требования) трех уровней.
1 уровень – требования «по умолчанию», требования о которых потребитель никогда не говорит, но он это имеет в виду всегда. Если к вам пришел клиент и хочет купить автомобиль, он не обсуждает, что у автомобиля 4 колеса, руль, крыша, сиденье, тормоз и т.д. В его сознании все это само собой разумеющиеся, неотъемлемые части того, что он называет автомобилем. И если мы под этим словом понимаем что то другое, то горе нам, сделка не состоится. И конечно он не будет покупать автомобиль с 3-мя колесами, потому что в его сознании он всегда с 4-мя. Требования по умолчанию очень важные требования, т.к. производитель не всегда понимает эти требования, так же как потребитель. И одна из задач производителя – докопаться до этих требований, выудить их у потребителя, то что для него есть «само собой разумеющееся». Если мы не удовлетворяем требованиям «по умолчанию», ни о чем другом и речи быть не может. Это не интересная игра, потому что мы её всегда проиграем. И проблема в том, что клиент по доброй воле об этих требованиях никогда не говорит.
Начнём с самого начала. Наш пользователь или клиент ещё не знает о нашем существовании. Он заходит в условный Яндекс. Вводит какой-либо поисковый запрос. И если у нас нет (1) модуля под SEO и человеко-читаемых урлов. Мы проиграли. Они даже не зайдут на наш сайт. Без разработки этой функции писать CMS нет смысла. Допустим к нам всё же зашли и хотят попробовать наш продукт и (2) зарегистрироваться. Это второй критически важный пункт. Среди миллионов сайтов процесс регистрации наверное уже задолбал просто всех. Есть пользователи, которые пользуются централизованными учётными записями, аля гугл или вк. И если нет возможности входа через эти сервисы. Скорее всего они не войдут. И даже не попробуют. Другая часть пользователь решает эту проблему через базы данных паролей. Я например генерирую пароль через KeePassXC и обычно он выглядит как-то так — ``5òÝ´ûs§±Z¿á_ÁÍ÷*èóô×GÃý?Çe6CÓ4ñ¾QrýôwtÐeõ×Ë~ôG÷j-\Y{ècï)µ©ñüè¤Îk¨kd-@½?¶x-©ÎPïίÛbPñ±£Ê'±°9doÝPô-3vÈp$Ù2úÀp[C[«G6XgH;ÊÙÊ{TRÒcM — Если сайт скажет пароль слишком длинный или в нём неправильный символ. А скорее всего сайт вообще ничего не скажет. Это провал. Мы теряем пользователя. Он не зарегистриуется и просто уйдёт. На другой миллион сайтов.
И подобные детали имеют первичное значение. Без реализации которых писать собственную CMS не имеет смысла. Сколько ещё есть таких моментов? Я не знаю. Мы люди разные. Но ещё точно есть адаптивный дизайн для людей с мониторами 4к, либо мобильными планшетами. Обычно сюда же входит поиск по сайту. Это всё то, что обычный, средний человек без малейшего понимания в компьютерах и сайтостроении считает само собой разумеющимся. А под чётким пониманием обычно — это хочу здесь кнопочку, а вот тут раздел. И тут картинку. Возможно даже с ТЗ. А про техническую мишуру с паролями и регистрацией мало кто задумывается.
И вот именно здесь и начинается всё самое вкусное, интересное, сложное и непонятное. Какие проблемы были. И как они решались? Есть проблема. Есть несколько вариантов решений. У этого такие плюсы и минусы. У другого другие плюсы и минусы. Я выбрал реализацию из CMS N1356, т.к оно мне понравилось больше, чем в других.
Надо понимать, что мало кто действительно пишет свою CMS. Как и мало кто пишет свою операционную систему. Их может быть и пишут. Но в процессе учёбы, по-фану. И пару недель. А потом начинается ад. И как следствие выбирается WordPress.
И вот я хочу узнать с чем же действительно придётся столкнуться. Назовём это краткой теорией CMS. Что же на самом деле надо почитать про создание веб-сайта и его архитектуры, за исключением модель-вью-контроллер? Автор сделал акцент на стеке технологий. И вот мне совершенно не интересно, почему же такой странный выбор — Java. По большому счёту всё равно на Java/PHP/GoLang/NodeJS или используется на фронте Angular/Vue/React. Это изобилие технических инструментов. Страдания, что выбрать Go или Node. Vue или React. MongoDB или PostgreSQL. Это страдания выбора инструментов. В каждом из них будет чуть-чуть по-разному. Надо просто выбрать и сделать хоть на чём-нибудь. Всё равно выбор будет ошибочным и эти страдания продолжатся на всю дальнейшую жизнь продукта (а с учётом гиперраспространения языков программирования… Где всё разное. И пересечься сложно даже на выборе технологий).
По архитектуре ядра ос можно посоветовать хотя бы Таненбаума. А там уже и по линуксу чего только нет. А что с CMS? Материалы либо совсем детские. Либо старые. Либо вот как вот этот. Прочитать было интересно и воодушевляюще. Но бесполезно.
Когда-то давным давно у меня не было выбора. Есть html4 и php… Есть PHP-Nuke и свой велосипед. У меня не было знаний по сайтам и я просто сделал какое-то УГ, из головы, без теории и понимания каких-либо проблем. После чего я не программировал много лет, свои дела, другие области. А это полусамописное модульное убожество на инклюдах каким-то образом живёт до сих пор. И сайт живёт до сих пор. И им пользуются. Если бы я выбрал PHP-Nuke, сайт бы не выжил. Но это было тогда.
Сейчас. Автору респект. Писать свою CMS при наличии WordPress и прочих. Это как минимум смело. И цена этому годы…
И вот написал я всё это… И почти передумал писать CMS :( И WordPress не хочу… Ещё этот долбаный зоопарк с иллюзией выбора аля голанг или нода… Реакт или вью. У меня был долгий перерыв. И вновь сайтами я заинтересовался аж месяца 3 назад. И в текущей реальности у меня даже есть сомнения стоит ли вновь заниматься. В интернете все заказы под уже готовые CMS… Да большинство людей БОИТСЯ делать сайты не на WordPress или OpenCart. Это же как обслуживать их?
То что сделал автор — маленький подвиг. А я весь день вновь думаю про свою CMS.
И даже скажу почему. Все до единого проекты в которых я был, построенные на базовых решениях, придуманных кем-то. Рано или поздно входили в стадию, где невозможно выйти за рамки ограничений этого самого базового продукта. Не важно, в каком он месте. Он будет. И на этом моменте сайт начинает чахнуть и увядать. Разработчики ядра CMS или форума. Там они пилят ядро. И на клиентов обычно уже плевать. И их решения не оспариваются, ведь они так видят. И сторонних разработчиков на изменения уже не найти, ведь есть «идеологически верный путь». А если уйти в сторону. То начинается ещё один форк, который превращается в поддержке своего самописного поверх ядра. И тут опять замкнутый круг. Ядро обновляется, у тебя всё рушится. Так что своя CMS — это в каком-то плане выход.
— Я тут случайно «войну и мир» нафлудил. По факту вся суть поста в модели Кано первого уровня по отношению к CMS. Спасибо, кто дочитал и извиняюсь перед теми, кому это пришлось почему-то читать ))
1 уровень – требования «по умолчанию», требования о которых потребитель никогда не говорит, но он это имеет в виду всегда. Если к вам пришел клиент и хочет купить автомобиль, он не обсуждает, что у автомобиля 4 колеса, руль, крыша, сиденье, тормоз и т.д. В его сознании все это само собой разумеющиеся, неотъемлемые части того, что он называет автомобилем. И если мы под этим словом понимаем что то другое, то горе нам, сделка не состоится. И конечно он не будет покупать автомобиль с 3-мя колесами, потому что в его сознании он всегда с 4-мя. Требования по умолчанию очень важные требования, т.к. производитель не всегда понимает эти требования, так же как потребитель. И одна из задач производителя – докопаться до этих требований, выудить их у потребителя, то что для него есть «само собой разумеющееся». Если мы не удовлетворяем требованиям «по умолчанию», ни о чем другом и речи быть не может. Это не интересная игра, потому что мы её всегда проиграем. И проблема в том, что клиент по доброй воле об этих требованиях никогда не говорит.
Начнём с самого начала. Наш пользователь или клиент ещё не знает о нашем существовании. Он заходит в условный Яндекс. Вводит какой-либо поисковый запрос. И если у нас нет (1) модуля под SEO и человеко-читаемых урлов. Мы проиграли. Они даже не зайдут на наш сайт. Без разработки этой функции писать CMS нет смысла. Допустим к нам всё же зашли и хотят попробовать наш продукт и (2) зарегистрироваться. Это второй критически важный пункт. Среди миллионов сайтов процесс регистрации наверное уже задолбал просто всех. Есть пользователи, которые пользуются централизованными учётными записями, аля гугл или вк. И если нет возможности входа через эти сервисы. Скорее всего они не войдут. И даже не попробуют. Другая часть пользователь решает эту проблему через базы данных паролей. Я например генерирую пароль через KeePassXC и обычно он выглядит как-то так — ``5òÝ´ûs§±Z¿á_ÁÍ÷*èóô×GÃý?Çe6CÓ4ñ¾QrýôwtÐeõ×Ë~ôG÷j-\Y{ècï)µ©ñüè¤Îk¨kd-@½?¶x-©ÎPïίÛbPñ±£Ê'±°9doÝPô-3vÈp$Ù2úÀp[C[«G6XgH;ÊÙÊ{TRÒcM — Если сайт скажет пароль слишком длинный или в нём неправильный символ. А скорее всего сайт вообще ничего не скажет. Это провал. Мы теряем пользователя. Он не зарегистриуется и просто уйдёт. На другой миллион сайтов.
И подобные детали имеют первичное значение. Без реализации которых писать собственную CMS не имеет смысла. Сколько ещё есть таких моментов? Я не знаю. Мы люди разные. Но ещё точно есть адаптивный дизайн для людей с мониторами 4к, либо мобильными планшетами. Обычно сюда же входит поиск по сайту. Это всё то, что обычный, средний человек без малейшего понимания в компьютерах и сайтостроении считает само собой разумеющимся. А под чётким пониманием обычно — это хочу здесь кнопочку, а вот тут раздел. И тут картинку. Возможно даже с ТЗ. А про техническую мишуру с паролями и регистрацией мало кто задумывается.
И вот именно здесь и начинается всё самое вкусное, интересное, сложное и непонятное. Какие проблемы были. И как они решались? Есть проблема. Есть несколько вариантов решений. У этого такие плюсы и минусы. У другого другие плюсы и минусы. Я выбрал реализацию из CMS N1356, т.к оно мне понравилось больше, чем в других.
Надо понимать, что мало кто действительно пишет свою CMS. Как и мало кто пишет свою операционную систему. Их может быть и пишут. Но в процессе учёбы, по-фану. И пару недель. А потом начинается ад. И как следствие выбирается WordPress.
И вот я хочу узнать с чем же действительно придётся столкнуться. Назовём это краткой теорией CMS. Что же на самом деле надо почитать про создание веб-сайта и его архитектуры, за исключением модель-вью-контроллер? Автор сделал акцент на стеке технологий. И вот мне совершенно не интересно, почему же такой странный выбор — Java. По большому счёту всё равно на Java/PHP/GoLang/NodeJS или используется на фронте Angular/Vue/React. Это изобилие технических инструментов. Страдания, что выбрать Go или Node. Vue или React. MongoDB или PostgreSQL. Это страдания выбора инструментов. В каждом из них будет чуть-чуть по-разному. Надо просто выбрать и сделать хоть на чём-нибудь. Всё равно выбор будет ошибочным и эти страдания продолжатся на всю дальнейшую жизнь продукта (а с учётом гиперраспространения языков программирования… Где всё разное. И пересечься сложно даже на выборе технологий).
По архитектуре ядра ос можно посоветовать хотя бы Таненбаума. А там уже и по линуксу чего только нет. А что с CMS? Материалы либо совсем детские. Либо старые. Либо вот как вот этот. Прочитать было интересно и воодушевляюще. Но бесполезно.
Когда-то давным давно у меня не было выбора. Есть html4 и php… Есть PHP-Nuke и свой велосипед. У меня не было знаний по сайтам и я просто сделал какое-то УГ, из головы, без теории и понимания каких-либо проблем. После чего я не программировал много лет, свои дела, другие области. А это полусамописное модульное убожество на инклюдах каким-то образом живёт до сих пор. И сайт живёт до сих пор. И им пользуются. Если бы я выбрал PHP-Nuke, сайт бы не выжил. Но это было тогда.
Сейчас. Автору респект. Писать свою CMS при наличии WordPress и прочих. Это как минимум смело. И цена этому годы…
И вот написал я всё это… И почти передумал писать CMS :( И WordPress не хочу… Ещё этот долбаный зоопарк с иллюзией выбора аля голанг или нода… Реакт или вью. У меня был долгий перерыв. И вновь сайтами я заинтересовался аж месяца 3 назад. И в текущей реальности у меня даже есть сомнения стоит ли вновь заниматься. В интернете все заказы под уже готовые CMS… Да большинство людей БОИТСЯ делать сайты не на WordPress или OpenCart. Это же как обслуживать их?
То что сделал автор — маленький подвиг. А я весь день вновь думаю про свою CMS.
И даже скажу почему. Все до единого проекты в которых я был, построенные на базовых решениях, придуманных кем-то. Рано или поздно входили в стадию, где невозможно выйти за рамки ограничений этого самого базового продукта. Не важно, в каком он месте. Он будет. И на этом моменте сайт начинает чахнуть и увядать. Разработчики ядра CMS или форума. Там они пилят ядро. И на клиентов обычно уже плевать. И их решения не оспариваются, ведь они так видят. И сторонних разработчиков на изменения уже не найти, ведь есть «идеологически верный путь». А если уйти в сторону. То начинается ещё один форк, который превращается в поддержке своего самописного поверх ядра. И тут опять замкнутый круг. Ядро обновляется, у тебя всё рушится. Так что своя CMS — это в каком-то плане выход.
— Я тут случайно «войну и мир» нафлудил. По факту вся суть поста в модели Кано первого уровня по отношению к CMS. Спасибо, кто дочитал и извиняюсь перед теми, кому это пришлось почему-то читать ))
Все прочитал, есть моменты с которыми не согласен (речь о деталях реализации для MVP, и 3-х колесном автомобиле), но в целом имеет место быть. В жизни всё так и есть. Спасибо за столь подробный коммент.
То что меня подтолкнуло написать свою CMS, это конечно «дубовые» реализации существующих CMS, хотелось уйти от этих рамок, своего рода соревнование с самим собой, смогу ли я сделать то, что я хотел бы использовать. Ту CMS мечты, с которой можно вздохнуть полной грудью.
То что меня подтолкнуло написать свою CMS, это конечно «дубовые» реализации существующих CMS, хотелось уйти от этих рамок, своего рода соревнование с самим собой, смогу ли я сделать то, что я хотел бы использовать. Ту CMS мечты, с которой можно вздохнуть полной грудью.
ВордПресс платформа для которой есть 100500 плагинов, просто уберите всё что вам не надо и добавьте то что надо, если то что есть не совсем то что вам надо то всегда можно доработать чужой код своим напильником и очень редко придётся пилить что то своё с новья.
Вы же не обязаны пользоваться всем что ВордПресс предоставляет, ВордПресс загрузит любой ваш плагин, это всё что он умеет делать. Ещё он из коробки умеет посты добавлять, умеет картинки к посту цеплять, а всё остальное наносное, от всего остального можно отказаться, всем остальным можно не пользоваться, и это открытые исходники, вы всегда можете заменить реализацию на свою.
Вы же не обязаны пользоваться всем что ВордПресс предоставляет, ВордПресс загрузит любой ваш плагин, это всё что он умеет делать. Ещё он из коробки умеет посты добавлять, умеет картинки к посту цеплять, а всё остальное наносное, от всего остального можно отказаться, всем остальным можно не пользоваться, и это открытые исходники, вы всегда можете заменить реализацию на свою.
Согласен, но там нет того что я хотел бы видеть. К примеру реализация REST-интерфейсов, надо под каждый сервис писать PHP-класс. В Drupal хоть можно через Views все в админке сделать.
Проблема номер 2, как создать каркас объекта из админки? Я говорю сейчас о объектах в базе данных.
Проблема номер 3, как заверстать купленный HTML-шаблон на Envato в логику данных из админки Wordpress? Я имею ввиду чтобы натянуть дизайн страниц из шаблона на логику данных.
Проблема номер 4, как сделать файловое хранилище через админку? Ну окей, это есть, но это на файловой системе, я использую mongodb для хранения картинок и файлов.
Проблема номер 2, как создать каркас объекта из админки? Я говорю сейчас о объектах в базе данных.
Проблема номер 3, как заверстать купленный HTML-шаблон на Envato в логику данных из админки Wordpress? Я имею ввиду чтобы натянуть дизайн страниц из шаблона на логику данных.
Проблема номер 4, как сделать файловое хранилище через админку? Ну окей, это есть, но это на файловой системе, я использую mongodb для хранения картинок и файлов.
Я написал свою CMS, но вам ее не покажу.
тоже жду пароль)
Интересно посмотреть что внутри, можно данные для входа?
В тексте есть упомянание об изменениях в стеке, может расскажете к чему идете сейчас?
Пока в поисках. Я ожидал уже что нашел, но попробовал и понял что это не совсем то что хотел. Но все же я поделюсь своими опытами.
1. На данный момент в приложении я использую MongoDB и слой работы с данными написан с использованием Weld CDI. Я бы хотел переписать все на Spring Data в интерграции с MongoDB. Тем самым выкинув все этот самописный код. Я думал что проблема которая возникает с SessionScope связана с моей имплементацией, но последние пару дней после эксперементов и фиксов, я понимаю что в этом плане там написано все замечательно. И все подозрения падают на работу этого AJAX-фреймворка ZK Framework. Далее пункт 2 о нем.
2.ZK Framework этот фреймворк очень удобен в плане шаблонизации. Можно легко брать статично свёрстанный HTML и вставлять во view и уже подключать java-бины и спокойно связывая UI с работой бекэнда. Причем все управление данными на бекэнд и синхронизацию UI берет на себя этот фреймворк. Тем самым легко разделить зоны ответственности работы в приложении. Вообщем принцип похож на JSF. Но есть в этом подходе минус, то что генерация CSS и JS от фреймворка происходит каждый раз при запросе страницы. И время загрузки страницы увеличивается, что визуально раздражает, — страница не имеет сложной структуры, а приходиться ждать секуду задержки. Разработчики позиционируют использования фреймворка как onepage-дизайн. В таком подходе он работает быстро. Потом еще был грустный факт что в последней сборке от ZK Framework'a я нашел небольшой баг, не кретичный, но добавил желание этот фреймворк не использовать больше. Я вместо него сейчас исследую Vaadin Flow 14. В целом неплох, но разработка UI сложнее и дольше.
3. У меня есть самописный слой на JAX-RS(REST API), хочу этот слой заменить на GraphQL. Тем самым упростив получение объектов разных структур лишь изменив параметры запроса.
4. Напоследок нужно изменить приложение клиента которое через REST достает данные из MongoDB, собственно сам результат сборки страниц в CMS это и работа этого приложения. Оно также использует ZK Framework. Хотелось бы использовать только клиентскую технологию, что-то типа ReactJS. Но пока в этом не уверен что это решение лучше.
Как-то так, буду рад услышать ваши размышления на этот счет.
1. На данный момент в приложении я использую MongoDB и слой работы с данными написан с использованием Weld CDI. Я бы хотел переписать все на Spring Data в интерграции с MongoDB. Тем самым выкинув все этот самописный код. Я думал что проблема которая возникает с SessionScope связана с моей имплементацией, но последние пару дней после эксперементов и фиксов, я понимаю что в этом плане там написано все замечательно. И все подозрения падают на работу этого AJAX-фреймворка ZK Framework. Далее пункт 2 о нем.
2.ZK Framework этот фреймворк очень удобен в плане шаблонизации. Можно легко брать статично свёрстанный HTML и вставлять во view и уже подключать java-бины и спокойно связывая UI с работой бекэнда. Причем все управление данными на бекэнд и синхронизацию UI берет на себя этот фреймворк. Тем самым легко разделить зоны ответственности работы в приложении. Вообщем принцип похож на JSF. Но есть в этом подходе минус, то что генерация CSS и JS от фреймворка происходит каждый раз при запросе страницы. И время загрузки страницы увеличивается, что визуально раздражает, — страница не имеет сложной структуры, а приходиться ждать секуду задержки. Разработчики позиционируют использования фреймворка как onepage-дизайн. В таком подходе он работает быстро. Потом еще был грустный факт что в последней сборке от ZK Framework'a я нашел небольшой баг, не кретичный, но добавил желание этот фреймворк не использовать больше. Я вместо него сейчас исследую Vaadin Flow 14. В целом неплох, но разработка UI сложнее и дольше.
3. У меня есть самописный слой на JAX-RS(REST API), хочу этот слой заменить на GraphQL. Тем самым упростив получение объектов разных структур лишь изменив параметры запроса.
4. Напоследок нужно изменить приложение клиента которое через REST достает данные из MongoDB, собственно сам результат сборки страниц в CMS это и работа этого приложения. Оно также использует ZK Framework. Хотелось бы использовать только клиентскую технологию, что-то типа ReactJS. Но пока в этом не уверен что это решение лучше.
Как-то так, буду рад услышать ваши размышления на этот счет.
Спасибо за ответ!
Меня больше инетерсовал выбор для фронта, так как несколько лет назад я видел как ZK используется в одном продукте, и как-то не впечатлило (только внешне, как устроено внутри не видел). Поэтому мучаюсь выбором между Angular+Material (есть небольшой опыт) и Sencha (тут побольше опыта, но платно).
Посмотрев ролик, стало интересно как устроен конструктор. Вы брали что-то за основу или это свое?
Меня больше инетерсовал выбор для фронта, так как несколько лет назад я видел как ZK используется в одном продукте, и как-то не впечатлило (только внешне, как устроено внутри не видел). Поэтому мучаюсь выбором между Angular+Material (есть небольшой опыт) и Sencha (тут побольше опыта, но платно).
Посмотрев ролик, стало интересно как устроен конструктор. Вы брали что-то за основу или это свое?
Конструктор полностью свой. Реализация очень простая. В приложении клиента есть view в котором подключен Java-класс который принимает на вход два параметра по GET, это id-сайта и id-страницы по REST я достаю из MongoDB список виджетов, по сути название файла который по include во view будет подключен. По аналогии CSS и JS также. Всё файлы храню в MongoDB. Сейчас есть задумка и на файловой системе хранить.
Перенес комментарий в ветку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рождение одного проекта или как написать свою CMS