а чё не

- controllers
- models
- templates
-- js
-- css

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

Вендор, это поставщик. Права сторонних производителей нужно уважать
А если серьёзно, то пользователю фреймворка не стоит лазить в фреймворк, чтобы добавить какой то дополнительный компонент к фреймворку, полученный на стороне.

Ведь у нас задекларирована очень легкая расшеряемость.

Ну тут иерархия. Фреймворк может обслуживать несколько приложений. Каждое приложение может обслуживать несколько сайтов.

Все они должны иметь независимые настройки в пределах своей компетенции.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Как это противоречит моему предложению? Для пользователя фреймворк - это такая же внешняя зависимость, место которой в vendor'е.

Разумеется, пользователю вообще не стоит лезть в код фреймворка (как и в код любой другой подключаемой библиотеки, которой так же и является abc). И как на это влияет то , что он расположен выше vendor или нет?

А как же безопасность? Зачем файлы, которые не должны быть доступны из вне держать в web root

Для того и разделение. В код abc нечего лазить. Вообще эта папка для него табу. Только в пользовательскую конфигу. Её кстати забыл отобразить, сейчас добавлю. Но если захочется поставить что-то стороннее, в дополнение к фреймворку, а не к приложению, чтобы сразу на все, то как? Распаковываем в vendor и конфигурируем фреймворк согласно новым указаниям.

Должна быть легкая расширяемость. Очень легкая.

Почему web root? Корневая директория сайта, это www. Это хост, просто так удобнее стартовать. У многих локальные сервера настроены так my-site/www

А там можно как угодно сконфигурировать. Верхние папки хоть в корень, хоть выше, от возможности площадки зависит.

С композером подумаем что делать. Это не проблема.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

как и vendor. Посмотри на фреймворк с точки зрения пользователя - для него он такая же зависимоть как и любая другая библиотека.

Корневая директория сайта - это ничто иное как web root, и к ней имеет доступ веб-сервер.

Этой проблемы можно избежать если не возносить свой фреймворк выше других библиотек (конечно же имею ввиду выше в файловой системе )

Разница есть, и она огромна. В вендор можно поставить целый ZEND фреймворк, и это не будет противоречит концепции. Вендор - набор сторонних решений. Вот поставил в него SMARTY. В папку vandor/smarty/ нечего делать. Кроме конфиг. А в сам вендор кто запретил?

По сути abc тоже вендор, но он основной и объединяющий. Потому и отдельно.

Может только её назвать vendors... Вкорее всего так. Спасибо за наводку.

Разве? Первое слово web, значит это корень сайта. А корень площадки выше. В root может располагаться несколько хостов. Вот так:

Вкурсе как устроены шареды? Можно раздать доступы по иерархии. Если мне дали доступ только к vhost1.com то он и будет корнем. Выше никак я не попаду. Ни по FTP ни по HTTP.

Вот и получается иерархия. В root сидят программисты, у них доступ везде. На каждом сайте свой верстальщик, он выше своего хоста не попадет. Ну и извне только к вьюшкам доступ.

Но если сконфигурировать иначе, то можно папки abc, application и vendors поместить в корень сайта. Тогда это будет индивидуальный фреймворк. Ну допустим на одной площадке несколько владельцев и у всех разные пристрастия.

Получается очень гибкая структура. Можно по разному. Можно общий фреймворк в рут поставить, а приложения по veb root разнести. Тогда вендорами будет один прогер заведовать, а приложением другой. Вариантов много.

Кстати, гибкость не указал в спецификации, а с неё и начал СПС за еще одну наводку.



_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Такое не делалось даже на той древней CMS на которой я когда-то делал магАзины. Создается папка Lang и подпапка например RU и через константы, в файл например lang.php, значения констант на русском. Зачем дублировать шаблон.

В сессию добавляется язык сайта, например RU и соответственно меняется путь к файлу lang.php.

А еще и высоких, толстых, кривых, горбатых? Видел я подобное, ужос.

Ну или базу дергать ради статичного текста. Есть ли смысл?

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Кстати, zf себя не обособляет и лежит рядом со всеми либами http://framework.zend.com/manual/2.0/en/re....structure.html (директория называется library вместо vendor)