у нас trunk — это даже не продакшн, а просто основа кода. из него раз в месяц отделяем release branch который в течении месяца тестируется со всем сторон и потом она же попадает в продакшн; все новые разработки делаются в отдельных ветках, которые по завершению попадают в транк; таким образом минимальный срок тестирования любой новой фишки составляет 4 недели. стандартная release driven парадигма
> Надо отметить, что в SVN, конечно, есть ветки, но сделаны они, видимо, для другого, и поэтому плохо приспособлены для того, чтобы их сливать в trunk.
это вы какую-то фигню написали. вся суть репозитория — в ветках. всем разработчикам сидеть в транке — дурдом. к правилам создания веток хочу так же добавить ветки релизов, как без этого работать мне сложно понять. SVN прекрасно работает с ветками во всех направлениях, дайте мне кейс, кто она с ними не справляется как должно.
Я ничего не имею против оригинала; Просто получается что перевод изряда вон паршивый, ведь написано «всё-таки существующих 7359 МБ часто не хватает даже для базовых нужд.»
1. ограничение на размер письма было до недавнего времени 10 метров, сейчас 25. я этой фишкой всегда пользовался. предположим что в среднем нормальный человек это будет делать раз в месяц. сложив числа получаем 120 метров в год.
2. нормальные смертные этим не пользуются
3. задроты держат аккаунты на сервисах типа getdropbox где нет ограничений на размер файла
4. джедаи держат свои сервера :)
смарти в порядке — просто, например, я ему сообщаю кол-во запросов сделаных к базе, сколько расходовалось памяти, что было найдето в кеше а что нет — банальная статистика
проблема в том, кто на момент создания смарти у меня порой ещё «далеко не всё известно» :)
но вы согласны, что _нужно_ использовать конструктор? а то несколько выше меня в этом пытались разубедить
нет не странно — fetch в коде вызываю только для компиляции писем — там переменные окружения не нужны. все «подготовки блоков» и прочая фигня происходит в шаблоне с помощью плагинов смарти, на этот момент он уже получил все «стандартные» значения
то, что они там публичные — это историческая «проблема», чтобы новые версии Smarty работали в PHP4 :(
а вообще, в первой же главе оф.мануала рекомендуют наследовать класс
относительно геттеров и сеттеров — довольно много ошибок в приложениях именно из-за того что кто-то в команде разработчиков где-то в коде присваивает свои значения переменным объекта, а где-то в другом месте всё начинает косячить несмотря на то, что все assertions ведут себя хорошо… используя getters && setters можно быстро получить весь стек значений, найти место в коде где безобразничали и надругаться над обидчиком.
это вы какую-то фигню написали. вся суть репозитория — в ветках. всем разработчикам сидеть в транке — дурдом. к правилам создания веток хочу так же добавить ветки релизов, как без этого работать мне сложно понять. SVN прекрасно работает с ветками во всех направлениях, дайте мне кейс, кто она с ними не справляется как должно.
в пользу GIT говорит только распределённость.
2. нормальные смертные этим не пользуются
3. задроты держат аккаунты на сервисах типа getdropbox где нет ограничений на размер файла
4. джедаи держат свои сервера :)
«You are currently using 1855 MB (25%) of your 7359 MB.»
Внимание вопрос — какие у человека могут быть _базовые_ нужды, чтобы использовать 7 гигов почты?
docs.php.net/manual/en/migration53.deprecated.php
и бац… вдруг всё перестаёт нормально работать. Как страшно жить!
но вы согласны, что _нужно_ использовать конструктор? а то несколько выше меня в этом пытались разубедить
а вообще, в первой же главе оф.мануала рекомендуют наследовать класс
smarty.net/manual/en/installing.smarty.extended.php
относительно геттеров и сеттеров — довольно много ошибок в приложениях именно из-за того что кто-то в команде разработчиков где-то в коде присваивает свои значения переменным объекта, а где-то в другом месте всё начинает косячить несмотря на то, что все assertions ведут себя хорошо… используя getters && setters можно быстро получить весь стек значений, найти место в коде где безобразничали и надругаться над обидчиком.
Простите, наболело :)
public function display($template,$cacheID){
$this->assignDefaultVariables();
//...other userful stuff b4 display
return parent::display($template,$cacheID);
}
само приложение для генерации любой отдельно взятой страницы в любом случае вызовет только один раз display =)