Каких функций у бандла не хватает?

Question

[Алексей Павлов]

Написал новый бандл для управления настройками сайта LexxpavlovSettingsBundle (репозиторий, packagist).
Предназначен для хранения настроек приложения (служебные емейлы, настройки блоков сайта, контакты, т.п.).

Возможности:

• Умеет получать настройки из базы - как отдельные настройки, так и группу связанных настроек.
  
• Умеет кэшировать данные.
  
• Конфигурится через Сонату или вручную.
  

Будет ли вам полезен такой бандл? Что можно было бы добавить в него, чтобы сделать его полезнее?
Также прошу желающим провести Code Review. Станем вместе умнее! :)

Что я подразумеваю под настройками:
- глобально включить/выключить комментарии у записей
- количество записей в списке
- текст акции на главной
- емейл для отправки служебных писем или заказов
- контакты, которые отображаются в шапке сайта

То есть всё то, что может понадобиться на нескольких страницах, и может быть изменено клиентом, а не программистом.

Answer 1

[Сергей Протько]

Будет ли вам полезен такой бандл?

нет.

https://github.com/lexxpavlov/LexxpavlovSettingsBu... - все очень плохо судя по всему. Я видимо не понимаю зачем вообще нужен бандл и что это делает в сущности.

Просмотрев дальше - еще больше не понимаю зачем все это нужно. Удачи вам с этим.

Comments

[Алексей Павлов]

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

[Сергей Протько]

Алексей Павлов: ясно... не интересно. Вот если бы оно позволяло часть конфига хранить в базе и управлять оными... было бы возможно интереснее. Хотя всеравно нет.

[Сергей Протько]

Алексей Павлов: ну мол я имею в виду что бы это все интегрировалось с симфоневским конфигом а не предоставляло еще одну прослойку. Хотя может быть так даже и лучше.

Answer 2

[WarGot]

Как я понимаю к тебя настройки хранятся вертикально, т.е. одна запись и под каждую настройку своё поле. Или за счёт связи на category они горизонтальными становятся ?
Обычно делают
настройка 1 - значение настройки
настройка 2 - значение настройки
настройка 3 - значение настройки

site_url - wargot.com
seo_desc = 'bla bla bla'
seo_keywords = 'bla, bla, bla, bla'

Кстати где внешняя связь с Settings на Category ?

Comments

[Алексей Павлов]

Честно говоря, не очень понял, что значит "горизонтально" и "вертикально" в этом контексте.
Одна настройка хранится в одной записи в БД, соседние настройки друг с другом напрямую никак не связаны, только через категорию. То есть, если есть три настройки (как в примере в ответе), то будет создано 3 строки в таблице в БД. Настройки могут быть вообще без категорий, категории нужны только для удобного группирования и для извлечения нескольких настроек за один запрос.

>Кстати где внешняя связь с Settings на Category?
Не вижу в этом смысла. Не вижу ни одной причины, зачем в настройке иметь ссылку на категорию. К тому же, я старался убрать из методов возврат сущностей, они не нужны для цели получения настроек.