Иван Артамонов: вы ошибаетесь. Полный url это domain.com/index.php/catalog/product и всё что после index.php это не папки, а обычная строка, так называемый роут. Картинку ищет не браузер, а веб-сервер и делать он это будет относительно той директории, которую вы ему укажите для домена domain.com. Если у вас
server {
server_name domain.com;
root /home/www/domain;
...
}
то src='logo.jpg' это /home/www/domain/logo.jpg всегда независимо, что у вас написано после index.php.
Иван Артамонов: не работал, у нас если кто-то желает потестить руками, он может выкачать ветку себе на дев машину и делать это там. По поводу относительных урлов, нужно просто начальный слеш убрать src='img/logo.jpg'. По поводу абсолютных и динамических нужно позаботиться и сделать так, чтобы оно работало как на дев машине, так и на тестовой и на продакшн. Скорее всего вам нужно будет запускать приложение в нескольких окружениях типа dev, test, prod и каждому рассказать как собирать абсолютные урлы. Это в любом фреймворке есть. Но как сделать наилучшим способом, я не знаю, думать нужно :)
Иван Артамонов: вебсервер всегда резолвит домен в определенную директорию. Поэтому вам не нужны домены на тестовой машине. Нужно просто каждую ветку собирать в отдельной директории на тестовой машине и вместо branch.company-dev.com будете обращаться как company-dev.com/branch. После коммита в удаленную ветку автоматически собирайте билд проекта в директории с названием ветки и в этой директории у вас будет лежать отдельная копия сайта. Тестировщик заходит на company-dev.com и видит все директории (сборки проекта) существующие на данный момент, щелкает по нужной директории и перед ним открывается сайт, который можно потестить руками. При сносе удаленной ветки сносите директорию с сайтом и копию базы к нему.
Иван Артамонов: чем вас не устраивает вариант, после коммита в удаленную ветку автоматически собирать билд в директории с названием ветки, тогда ветка my-cool-feature будет доступна по адресу http://ip.add.re.ss:port/my-cool-feature ? Зачем вам нужен какой-то треш с доменами?
rustler2000: вы придираетесь к терминам. Это как если я буду придираться, что comet это всё то, что вы описали дальше. Ну ок, пусть будет NRT. Я не говорил, что это не реализуется на php. Я говорил, лишь что мало смысла на нем это делать, как и строить вебмагазины на node.js.
rustler2000: не вижу смысла делать http сайт на node.js когда есть PHP и удобная модель позволяющая не думать об утечках памяти. И наоборот, делать ws сайт на PHP, когда есть node.js. Глупо делать что-то на определенной технологии, только потому, что вокруг неё много шума.
Дело в том, что для многих php это дверь в мир программирования. Книг по архитектуре в контексте php до недавнего времени не существовало. Ни одной популярной книги, которая мазолила глаза бы всем нет и сейчас. Большинство php разработчиков даже не понимают, какие преимущества дает ООП над процедурным. Зачем все эти паттерны. И их можно понять, ведь они пишут примерно то, что выше. Процедурщину завернутую в классы. Почти все книги по архитектуре написаны в контексте java. Мало, кто из php разработчиков их читал. Поэтому так много спагетти на php, а не потому что нет сложных манипуляций с данными. Вот и всё.
Adamos: мне ничего. Я к тому, что в документации к фреймворку об этом не пишут. Даже намека не делают. Очевидно, что большинство будет делать, так как написано в мануале к фреймворку. В итоге и получается, что модель эквивалентна таблице в базе данных или еще какое уродство. Так делает большинство.
NikolayAlb: чтобы был смысл применять паттерны, должна существовать доменная модель. К сожалению, в php это редкость. Фреймворки вносят путаницу в понимание, что же такое модель. В итоге никакой доменной модели не получается и бизнес-логика гуляет по всему проекту. В такой ситуации невозможно применить никакой паттерн. Нет инкапсулированной группы классов, решающих бизнес задачу. Всё разбросано по всему проекту. Применть паттерн просто не к чему. Я рекомендую вам читать книгу по DDD от автора Вон Вернон, чтобы понять, что такое доменная модель. И попробовать запрограммировать что-нибудь используя архитектурные принципы из книги. Вы с удивлением обнаружите полезность многих паттернов.
NikolayAlb: стратегия позволяет изменить алгоритм, не изменяя сам объект, который этот алгоритм использует. Например создавать отчет в разных форматах.
Декоратор позволяет динамически расширять поведение объекта бесконечное количество раз. Например создать основу для пиццы, а затем добавить колбасы, лука и помидор. В разных вариациях. Каждая добавка увеличивает стоимость пиццы. Это работа для декоратора. Без него, вы утоните в спагетти коде при решении этой задачи.
nepster-web: не лить бизнес-логику в контроллер и дублирования не будет. Он должен валидировать пользовательский ввод и возвращать результат работы модели. Больше ничего. Валидация и возвращаемый результат у вас будут отличаться у бека и фронта. Никакого дублирования.
Нужно видеть реальную задачу. Не понятно, что вы хотите сделать. В любом случае, данные в объекте храниться не должны, для данных есть хранилища (база/файл/удаленный сервис и т.д.). Из данных собирают объект или вложенную иерархию объектов (агрегат). Скорее всего, то что вы хотите хранить в $this->data можно разложить на дочерние объекты, которые будут жить внутри класса Class.
Нет. REST не устанавливает никаких требований к контроллерам. Он предъявляет требования к формату запроса/ответа, но не накладывает никаких ограничений на возвращаемые данные из контроллера. Что конкретно по вашему в этом подходе противоречит рест?
то src='logo.jpg' это /home/www/domain/logo.jpg всегда независимо, что у вас написано после index.php.