# Delphinum (17.11.2016 / 12:48)
AlkatraZ, в объект конфигурации еще можно положить логику, которая будет верифицировать файл конфигурации и сообщать на раннем этапе программисту о том, что у него в конфигурации что то не задано или
Отличная и правильная мысль.
Но я не приводил подробности...
на самом деле у нас используется не стандартный /ArrayObject, а его расширенная версия. в виде Zend\Stdlib\ArrayObject
Основное отличие: просто так не получится перезаписать свойство объекта, оно теперь (после первого объявления) защищено. Иными словами: кривой модуль не сможет порушить системный конфиг.
Защита от дурака.
разумеется. серьезный хакер это обойдет, но у нас не об этом речь.
AlkatraZ, ну вообще достаточно будет запустить твои примеры в IDE и будет видно, зачем у класса конфигурации такой длинный коммент-блок с непонятными @property. Да и зачем кого то агитировать, пусть народ сидит на блокнотах, если им так удобно.
AlkatraZ, если уж вы пользуете Zend, то может обратите внимание на
Zend\Config? Если вы планируете сделать ваши конфиги независимыми от формата (PhpArray, Ini, Json, Xml, Yaml) при загрузке и записи в файл, то крайне удобное решение будет, в остальном ничего особенного, просто реализация конфигураций системы в объектно нотации и рекурсией.
P.S. на днях распишу конкретно этот пакет в своем бложике с примерами использования и внутренностями, можно будет оценить и решить, надо ли оно вам, или ваш простенький объект вполне справится с задачами.
# Delphinum (17.11.2016 / 12:57)
AlkatraZ, если уж вы пользуете Zend, то может обратите внимание на Zend\Config? Если вы планируете сделать ваши конфиги независимыми от формата
Он у меня давно и успешно
используется в mobiCMS (и будет использоваться в релизе).
Однако. в рамках JohnCMS я на данный момент посчитал лишним использование столь тяжелого пакета.
AlkatraZ, ну по большому счету я вижу в этом пакете только две плюшки:
1. Умение пакета читать и писать во все популярные форматы
2. Метод get с параметром $default, который вернет дефолтное значение конфигурации, если оно не задано в файле
В остальном, если таковое не нужно или нужно частично - да, проще реализовать свой миникласс
AlkatraZ, нам надо будет в мобик забрать zend/acl очень удобный и простой
# Delphinum (17.11.2016 / 12:57)
Если вы планируете сделать ваши конфиги независимыми от формата (PhpArray, Ini, Json, Xml, Yaml)
А вот это я изучал очень долго, упорно и с "биением галавой апстену"...
===
Чтоб понять суть, давай порассуждаем...
Для пейсаталей фреймворка действительно: они не знают. что взбредет на ум конкретному пользователю. Но у нас то не фреймворк, а конечный продукт, где мы можем определиться с каким-то форматом и сделать его (в наших рамках) стандартом.
При изучении форматов, надо абстрагироваться от всех излишеств и
попсы, которая на нас прет отовсюду...
В чем заключается попса?
Да элементарно...
JSON - это стандарт для JS и в рамках нативного РНР (если на то нет конкретных требований) его применять нежелательно, ибо идут накладные расходы на парсинг.
То же касается и YML и любого другого формата, отличного от Phparray
Аргументирую:
Апологеты YML (ту бишь фанаты Симфонии) с пеной у рта доказывают, что мол формат прост и понятен.
Тут я не могу оспаривать, YML действительно относительно прост.
НО!
Если вы пишете на РНР, значит отлично знаете, что такое массивы.
ну а тогда, чем вам плох
данный конфиг и чем он "непонятнее" YML, тем более, что в случае РНР действуют все автоподстановки и другие ништяки...
# Koenig (17.11.2016 / 13:08)
AlkatraZ, нам надо будет в мобик забрать zend/acl очень удобный и простой
Тут я еще изучаю целесообразность.
Многие помнят, что на
http://mobicms.info я публиковал мануал и API для нашей собственной системы авторизации: там была реализация RBAC -> ту бишь дальнейшего развития ACL.
Да, знаю, что у ZEND есть своя реализация и ACL и RBAC, но пока далеко не уверен, что мы ее будем использовать, есть свои, более подходящие для конкретной ситуации разработки.
однако не исключаю и других вариантов.
AlkatraZ, я согласен с тем, что в PHP проекте нужно использовать PhpArray в качестве конфига, более того, во всех моих новых проектах я именно так и поступаю, ибо - почему нет? Умение пакета читать и писать различные форматы конфигурации конечно полезная фишка, но я думаю вам оно не нужно, вряд ли вы будете менять формат конфига, хотя раньше у вас конфиг был в базе, а теперь в файле )) Из плюсов для вас, в использовании данного пакета я вижу только один - это готовое решине, его можно просто взять и использовать. В остальном не вижу причин переходить на него вместо того, что у вас уже есть. А предложил я его на рассмотрения для того - может с ним не знаком и заинтересуешься, может у вас есть какие то скрытые задачи, о которых я не знаю, и которые могут быть решены этим пакетом.
