Иван Артамонов: index.php не убирают, а скрывают, но в любом случае все урлы по которым физически на сервере ничего не существует, он редиректит на точку входа index.php, который лежит в корне. Соответственно, какую страницу сайта вы бы не открыли, ваш current path всегда будет равен директории где лежит index.php т.к все страницы вашего сайта динамические и физически их не существует на сервере (они все генерируются через index.php). Соответственно на любой динамически сгенерированой странице сайта (через index.php) все ассеты будут резолвиться относительно этого current path. Я мог бы вам показать, что именно так это и работает и я уверен в этом на 100%, но мне лень тратить своё время и разворачивать для вас демо, чтобы что-то вам доказать. Достаточно понять, что ваш веб сервер всегда обращается к файлу index.php, какую страницу сайта вы бы не открыли, если у вас одна точка входа, незвисимо от того, видите ли вы index.php в урл или нет. И соответственно все картинки без начального слеша будут отдаваться относительно директории того файла, к которому вы обратились, а это index.php для любой страницы вашего сайта.
Про тестеров я вам уже не раз писал. Если у вас есть специально обученный человек, которому не жить как приспичило тестировать каждую ветку в отдельности, то он может скачать эту конкретную ветку себе на дев машину и делать там всё, что он хочет не заморачивая голову остальным. Но вообще в крупных компаниях тестировщики работают не так, они плевать хотели на все эти ваши ветки, они ничего в них не понимают. У них есть чек-листы и именно по ним они проверяют конкретный билд, который собирается выйти в релиз. Это не ветка и не одна фича, это то, что уже реально готово выйти на продакшн как next version. Если тестеры заворачивают этот билд, то разработчики правят то, что тестировщиков не устраивает и выкатывают новый билд. И для таких вещей есть stage. Ваша проблема в том, что вы сами же придумали себе проблему, а теперь пытаетесь героически её решить.
На этом всё. В дальнейшую дискуссию не вступаю, поскольку мне больше нечего сказать, по вашей теме.
GhostSt92: согласен, что жесть. Но вы же сами видите, что автору зачем-то нужно чтобы все ветки были доступны с удаленной машины, чтобы тестеры ходили по ним своими браузерами и что-то там тестили и другие варианты он принимать не желает. Я уже не однократно писал человеку, что разработчик сам тестирует фичу и что если уж автор хочет что-то там тестить руками или как-то еще, то может master выкатывать не сразу на prod, а не stage и делать это там.
Иван Артамонов: вы ошибаетесь. Полный 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: не лить бизнес-логику в контроллер и дублирования не будет. Он должен валидировать пользовательский ввод и возвращать результат работы модели. Больше ничего. Валидация и возвращаемый результат у вас будут отличаться у бека и фронта. Никакого дублирования.