Пишу проект, и понимаю, что изобретаю велосипеды.
На этих велосипедах давно уже разъезжают программисты, а я усиленно пилю свой ))
Итак задача:
В целом, приложение - аналитическое представление данных в виде графиков, списков, деревьев, карт.
Работа делится на математическую (агрегирование табличных данных) и графическую (формирование сетки и редактирование свойств размещенных в ней графиков, деревьев, таблиц и т.п.)
Приложение должно уметь сохранять себя в JSON формате в одну строку. То есть серверная часть не предполагает наличия подробного описания для каждого графика, таблицы и пр. в виде отдельных сущностей в БД, все записываться должно в сериализованном виде в одну ячейку одной строки БД.
1) Отсюда сложность с реализацией REST-api для Frontend-приложения.
Возможно, я просто не углублялся и это не проблема для данных движков?
Но у нас нет RESTapi, как сериализованные данные пришедшие с сервера превратить в источник данных (модели) для приложения?
2) Кроме того, приложение это некий редактор, я не очень понимаю как он ложится в концепцию данных движков?
Что он делает: путем перетаскивания (из палитры компонент) в рабочую область добавляются слои в них добавляются компоненты (графики, таблицы и т.п.). Компоненты можно перемещать из слоя в слой, менять порядок размещения в слое и размеры. У каждого компонента есть свой виджет с настройками.
3) И наконец, как все это сериализовать и в последствии восстановить в первозданном виде?
4) Ах да есть же еще и работа с данными и математика. Когда график настроен (заданы измерения и меры) он должен посчитать и отобразить значения. Тут можно сильно не углубляться, вопрос лишь в том, что должна быть возможность писать код внутри каждого представления (график, таблица, итд).
Есть существенное ограничение - ES6 использовать не представляется возможным, пока.
Мне нужно понять какой движок мне больше подходит и как его применить? Вообще стоит ли?
мне кажется и angular и angular2 и react + redux с этим справится легко. Но на angular2 я бы не спешил делать, так как можно попасть в засаду из-за его молодости, а значит малом количестве готовых библиотек. И вообще лучше подходит реакт, ведь для него графики, это повседневные задачи. Я за реакт.
Насчет сериализации - смотрите react+redux.
В редаксе все состояние приложения хранится в одном дереве (json объект). Путем простейших манипуляций вы можете его сохранить и заново восстановить. Но там все больше к ES6: babel и webpack использовать придется.
А насчет 2 и 4 пунктов - это уже относится к вашей реализации. Производить вычисления можно везде, UI тоже можно везде любой (или почти любой) сделать.
В задачах подобного уровня слова "фреймворк", "движок" и т.п. использовать крайне вредно.
У вас в постановке самого задания и подходе к выбору ORM, похоже, полная каша. Отдавать клиентской стороне задачи по сериализации и десериализации — не самая удачная идея. Сперва разберитесь каким предельным количеством алгоритмов и структур данных собираетесь оперирвоать; потом спроектируйте под это БД и API, и только в последнюю очередь занимайтесь поиском "движка".
Реализуется все на том что есть, это не проект с нуля. Каши никакой нет. Есть задача, реализовать все на фронтенде. ORM тут нет, все нужные данные грузятся во фронтенд разными путями и на фронтенде же обрабатываются.
Зачем мне советовать графический движок?
С графиками проблем как раз нет, используем платный JS-движок, никаких d3js
Валентин: d3js - не графический движок, тащемта. Вообще, в целом постановка задачи сигнализирует о неком пробеле в компетенции её выдавшего. Поэтому что бы здесь не посоветовали — выйдет путь костылей и напильников, что есть не хорошо.
Leonid Prokopchuk: Но все же, в основном, для создания красивой графики он используется. Давайте о костылях не будем сейчас, костыли делать или нет мне уже надо будет решать, для начала нужно разобраться.
Средний
