Веб-приложение и презентационный сайт

scorpion-ds

Новичок
Есть веб-приложение на SF2 с довольно специфичный функционалом, с доступом после авторизации, будет еще расширятся по меньшей мере 3-4 месяца.

Есть задача прикрутить к нему посадочную страницу (авторизация в системе должна происходить и через нее тоже, кроме родной авторизации), разделы с помощью по самой системе и другая полезная информация, задача стоит встроить это все в эту систему, хотя бы в виде HTML страниц (правится будут по "FTP"), это в понимании клиента, технически, если уже делать, то некий простой бандел со страницами.

Мое же предложение, сделать все это на отдельном движке, к примеру WP, авторизацию с посадочной делать кросс доменной, то есть авторизация будет происходить не в WP, а сразу в системе (в общем, то уже детали), мои аргументы такие:
  • веб-приложение со своим функционалом не должно быть перегружено функциями (информационными страницами), которая по сути ей не требуется;
  • сейчас функционала страниц нет вовсе, он не предполагался ранее, это просто закрытое приложение, добавить в него связанные HTML страницы (это словами клиента), с возможностью редактировать только через "FTP", это какой-то изврат;
  • этими информационными страницами будут заниматься совсем другие люди, без серьезного опыта программирования, я не хочу кого зря допускать к git проекта;
  • куда удобней поставить какую-то CMS и делать там любое дерево сайта, чем создавать некие HTML страницы, которые тем не менее должны работать на SF2;
  • подумываю туда же перевесить оплату тарифных планов, сама же система будет только отслеживать сроки действия тарифов (но тут я еще не совсем уверен)

Аргументы клиента:
  • так проще;
  • не понятно зачем из-за посадочной страниц и несколько страниц помощи ставить какую-то CMS;
  • самой системе придется работать на суб-домене;
  • именно так работают другие системы, вроде различных CRM (я кстати с этим не согласен)

У клиента есть свои разработчики, ребята вроде нормальные, но фактически без опыта программирования вообще, тем не менее они своему руководству выдвигают свое виденье ситуации и нам приходится доказывать свою правоту.

Подскажите, кто прав?
 

WMix

герр M:)ller
Партнер клуба
я не хочу кого зря допускать к git проекта
html'ки выкинуть в отдельную папку за проектом, остальное все наживное...
простые тексты (типа cms) это простенькая табличка или папка и wysiwyg строится тоже легко.
CMSка вариант, конечно, но появятся другие проблемы по складыванию 2х проектов в единое целое, (в смысле не совсем чтоб просто поставить).
на счет проще ли htmlки рисовать и по ftp админить, сложно сказать, если только с точки зрения дешевого персонала..
 

scorpion-ds

Новичок
html'ки выкинуть в отдельную папку за проектом, остальное все наживное...
простые тексты (типа cms) это простенькая табличка или папка и wysiwyg строится тоже легко.
Макет там довольно сложный, если все запихнуть в wysiwyg, то править его будет очень тяжко, а если его ставить для каждого текстового блока, то проще поставить CMS.

CMSка вариант, конечно, но появятся другие проблемы по складыванию 2х проектов в единое целое, (в смысле не совсем чтоб просто поставить).
Ну главное, что бы движок видел сессии системы, которая будет на суб-домене, что показывать статус авторизации, я думаю это не сложно будет реализовать. И я как раз не хочу их складывать в единое целое, пусть живут по отдельности.

на счет проще ли htmlки рисовать и по ftp админить, сложно сказать, если только с точки зрения дешевого персонала..
Ну им кажется, что там только посадочная страница, но оказывается, что есть страницы с помощью, инструкции по оплате (требования платежных сервисов), различные контактные формы.
 

WMix

герр M:)ller
Партнер клуба
пусть будет без wysiwyg,
тебе ли не всеравно, если это html?

есть рута /html/*.html которая вызывает некий экшин htmlAction() который заходит в папку, находит файло и выкидывает наружу, в противном случае 404.
 

AnrDaemon

Продвинутый новичок
Клиент не прав. Прикручивать к проекту функционал, несущественный для функционирования проекта - это идиотизм и трата его собственных денег на чёрт знает что.
 

AnrDaemon

Продвинутый новичок
пусть будет без wysiwyg,
тебе ли не всеравно, если это html?

есть рута /html/*.html которая вызывает некий экшин htmlAction() который заходит в папку, находит файло и выкидывает наружу, в противном случае 404.
Ты рассуждаешь как технарь, для которого поправить десяток строк в HTML не проблема.
Для тебя не проблема, для меня не проблема, а девочка, которая будет набивать контент, наделает такого ужаса, что… лучше даже не начинать.
 

WMix

герр M:)ller
Партнер клуба
а ты считаешь, что каждая страничка должна делаться программистом?
для меня как раз это проблема, я буду генератор лучше писать чем хтмлки верстать, пускай девочка мне пофиг..
 

fixxxer

К.О.
Партнер клуба
Вордпресс можно прикрутить просто в качестве админки для контентных страниц, на служебном субдомене, прикрытом хотя бы basic auth (чтобы было пофигу на эксплоиты).
А дальше - есть от такой клевый плагин https://wordpress.org/plugins/json-api/, с ним уже разные варианты - интеграция, генерация статики итд.
 

scorpion-ds

Новичок
Вчера обсуждали варианты, основная идея сейчас такая:
Ставим вспомогательный сайт, который будет обслуживать посадочную страницу и страницы помощи, при этом страницы помощи будут грузится в самое приложение ajax запросами, так что плагин fixxxer, может очень даже пригодиться (вот только он не обновлялся более 2 лет, но возможно это не имеет значение). То есть в самом приложении будет только справочный центр, сам по себе не содержащий ни какой информации, но по запросу он будет ее подгружать.

Остался вопрос на каком движке делать этот справочный центр:
  • SF2 + Sonata: более гибкое решение для дальнейшего развития, очень конечно не хочется ставить Sonata (в самом приложении от нее отказался), но разрабатывать свою админку это дольше, а там есть и CRUD симпатичный и медиа-библиотека;
  • WordPress: для управления контентом решение удобное, если проблема ответа от него в формате JSON без особых костылей решаема, то вполне нормальное решение.
 
Сверху