В чем принципиальная разница между контроллером и директивой?
Можно ли наследовать контроллеры, чтобы на базе одного создавать новый?
Есть ли методы (события) для взаимодействия контроллеров?
Меня вот что волнует: если ограничения к данным накладываются правами доступа, то серверу придется обрабатывать любые сложные запросы. Что можно применить для атаки. Если ограничения делаются программным интерфейсом, то разработка изоморфных компонентов будет зависеть от него (от разработки API). Какой вариант предпочтителен из вашего опыта?
Хм, фактически писать SQL запросы с клиента? Или должно создаваться API строго под проект, которое будет использоваться изоморфными компонентами? Вопрос даже не про derby, а в целом по изоморфным приложениями. В каком месте граница изоморфности?
То есть практичность только в классификации (категоризации)?
Из первых абзацев статьи складывается картина, что администратор совсем не понимает, что за нечто добавляет на сайт. Может, только название или картинку этого нечто знает, а далее пользователи через сравнения определят, что это нечто автомобиль с турбонадувом X78 и болтиком с криволинейной резьбой в фиксаторе магнитных ускорителей. Ну и сотню других свойств :) Вот и задумался, как же через сравнения о товаре будет добавлена исчерпывающая информация, как будут добавлены уникальные свойства?
Хм, выявим о товаре необходимые свойства по похожести, а кто их заполнит значениями? Как с помощью сравнения о фильме будет заполнена информация об актерах, наградах, сборах, трейлер? Можно ещё примеры практического применения?
А где грань между данными и их видом? Ведь подобный подход предполагает объединение данных с их оформлением (видом), а часто нужно разное отображение для одних данных — виды для печати, rss… Со страницами журнального типа ещё терпимо, а как же дела обстоят, например, с товаром? Добавлять товар в каталог созданием его визуальной карточки? Или предполагается хитрая система, которая сама отдельно создаёт объект данных и шаблон под них, если он отличается от уже существующих шаблонов?
На текущий момент Boolive — это инструмент для разработчиков. Ещё отсутствует многообразие готовых «модулей» на разные случаи, их нужно создавать, поэтому первостепенное внимание уделено эффективности разработки. (примечание: под модулями подразумеваются любые объекты). Применяя систему в конкретных проектах, сформируется коллекция готовых решений для обычных пользователей. Документация, видеоролики и другого рода материал подготовим для разных категорий пользователей.
По поводу хранения в mysql. Вариантов перепробовали множество, у всех свои минусы и плюсы. Иерархические отношения хранятся в отдельной таблице, реализуется метод «материализованный путь», разложенный на строки (http://habrahabr.ru/post/138947/). Для самих объектов используется две таблицы, одна для идентификации uri, в другой атрибуты объекта. Одна строка – один объект.Ещё есть таблица для больших текстов с поддержкой полнотекстового поиска. Фактически все объекты в одной таблице. В этом и есть компромисс – получаем довольно простые запросы на сложные выборки с иерархическими условиями –всё работает по целочисленным индексам очень быстро. Но, конечно, остаётся вопрос оптимальности хранить всё в одной таблице, он постоянно обсуждается. Для масштабирования предлагается секционировать таблицу. Но ещё сам движок позволяет использовать несколько хранилищ – мы можем слабосвязанные ветви иерархи хранить в отдельных базах. И да, мы всегда можем внедрит новый тип хранилища на другой субд, главное поддерживать API сохранения, удаления и выборки объектов. Есть где развернуться.
Гибкость у системы разного плана – это не только возможность создавать желаемые структуры, но и свобода выбора, создавать ли сложные, супер детальные структуры или же обойтись простым вариантом? Запускать по очереди виджеты или же напрямую их вызывать? Какое хранилище использовать? Поэтому тут выбор от задач проекта, от его приоритетов и ресурсов.
Необходимость подтвердится, приделаем. Классы ядра являются «мостами» к модулям системы и (или) реализуют функционал в точном соответствии с архитектурными нуждами. Претензии обоснованы только к Mail, который является временным решением.
Можно ли наследовать контроллеры, чтобы на базе одного создавать новый?
Есть ли методы (события) для взаимодействия контроллеров?
Из первых абзацев статьи складывается картина, что администратор совсем не понимает, что за нечто добавляет на сайт. Может, только название или картинку этого нечто знает, а далее пользователи через сравнения определят, что это нечто автомобиль с турбонадувом X78 и болтиком с криволинейной резьбой в фиксаторе магнитных ускорителей. Ну и сотню других свойств :) Вот и задумался, как же через сравнения о товаре будет добавлена исчерпывающая информация, как будут добавлены уникальные свойства?
По поводу хранения в mysql. Вариантов перепробовали множество, у всех свои минусы и плюсы. Иерархические отношения хранятся в отдельной таблице, реализуется метод «материализованный путь», разложенный на строки (http://habrahabr.ru/post/138947/). Для самих объектов используется две таблицы, одна для идентификации uri, в другой атрибуты объекта. Одна строка – один объект.Ещё есть таблица для больших текстов с поддержкой полнотекстового поиска. Фактически все объекты в одной таблице. В этом и есть компромисс – получаем довольно простые запросы на сложные выборки с иерархическими условиями –всё работает по целочисленным индексам очень быстро. Но, конечно, остаётся вопрос оптимальности хранить всё в одной таблице, он постоянно обсуждается. Для масштабирования предлагается секционировать таблицу. Но ещё сам движок позволяет использовать несколько хранилищ – мы можем слабосвязанные ветви иерархи хранить в отдельных базах. И да, мы всегда можем внедрит новый тип хранилища на другой субд, главное поддерживать API сохранения, удаления и выборки объектов. Есть где развернуться.
Гибкость у системы разного плана – это не только возможность создавать желаемые структуры, но и свобода выбора, создавать ли сложные, супер детальные структуры или же обойтись простым вариантом? Запускать по очереди виджеты или же напрямую их вызывать? Какое хранилище использовать? Поэтому тут выбор от задач проекта, от его приоритетов и ресурсов.