упс, проглядел ;) 3 правила это сейчас, если будете расширятся, то понадобится больше. Хотя в любом случае я бы использовал программный роутинг, он имхо гораздо удобнее: все в одном месте, единый интерфейс и не надо потом рыться по шаблонам и коду в поисках нужных линков, если вдруг захочется что-то поменять или расширить.
Мне тоже ни разу не попадались. Когда я был исполнителем я все-таки сам писал и согласовывал ТЗ, т.к. потом меньше потенциальных проблем типа «а мы хотели не так». Это все очень треплет нервы, особенно за день до сдачи. Да и удобней когда функционал и детали расписаны на бумажке в которую посмотреть можно, в голове порой не всё удержишь, благо времени на ТЗ не так много уходит.
Небольшая критика относительно методики ЧПУ. «Такая операция была проведена для всех урлов сайта» — это как, для каждого модуля свое правило в .htaccess? Ссылки генерируются в самом движке «ручками», т.е. уже с применением правил преобразования? Возможно более целесообразно было бы использовать внутренний роутер/ассемблер прямо в ПХП. Советую посмотреть в сторону Zend Framework с компонентой Zend_Controller_Router_Rewrite. Ее достаточно легко встроить без использования обвяза из контроллеров, но в итоге можно получить более гибкий механизм ЧПУ, т.к. все правила по преобразованию будут в одном месте
поздравляю, если это первый сайт, то Вы на правильном пути, и тема мне по нраву ;) Подход для новичка впечатляет, виртуальный плюс в карму, ибо реального шанса нет )
я имею ввиду что при суммах больше 1000 _желательно_ составить договор, для того что бы обезопасить себя самого, а так же и исполнителя. Бухгалтерия во фрилансе не нужна, достаточно справки о доходах и декларацию заполнить раз в год. ТЗ может быть примитивным только для ориентировки по функционалу, но лучше что бы было.
под сайтом я понимаю что-то размещаемое в вебе, неважно. Как правило чаще всего у заказывают именно сайты визитки, те самые 5 страничек. За магазин — другое дело, это уже «сложный» проект (относительно конечно)
имеется ввиду что на данный момент бессмысленно разрабатывать такой подход для закачки, т.к. он не описан в стандартах. Это грабли которые от версии к версии браузеров будет меняться, поддерживается не четко и по большому счету код становится заложником людей которые ту же оперу пишут. Даже учитывая что «плагин недоступен», стандартный загрузчик из 3 полей типа file будет лучше чем грабли с multiple, которые большинство пользователей даже не будут пытаться использовать, они не знают что в выпавшем окошке можно выбрать 2-3 файла а не только один.
интересная ситуация получается, если опера — делать одно, если FF другое, если IE — третье, а то и просто так показывать стандартную форму с обычной загрузки файла. Если все так весело, зачем я должен отказываться от проверенного временем flash-загрузчика и типичной формы с обычным file для ситуаций когда флэша нет? Зачем плодить сущности для такой опреации, если она не гарантировано и не всегда корректно отображается в разных браузерах?
С CSS уже намучились и продолжаем, так зачем те же грабли переносить и на backend
только уже работающему проекту это не поможет. Он все равно ляжет, смотри ты в логи или не смотри. И скорее всего так оно будет даже при правильно написаном коде, где в какой-то функции при сторонней ошибке отдается false, а не кидает эксепшн. Придется добавлять кучу try/catch в самых неожиданых местах, потому что проект писался по документации старой версии пхп, а не по новой. Единственный выход это оставить поддержку старых функций как есть, а новые с исключениями выделить в другой нэймспейс
имеется ввиду число есть число а не объект как в том же Руби, это касается самого ядра и принципов по которым все пишется. Я ничего не имею против того что бы сделать расширение для пхп и использовать дополнительную функциональность, но зачем? В данном ключе сам язык такой какой есть, и если это не нравится, выбираем другой и пишем уже на нем. Хотите объекты везде — берите Java или Ruby, в чем проблема. Видите плюсы в использовании конкретно пхп — используйте его так как он есть, не придумывая велосипед по 10му разу, зачем плодить неразбериху в сущностях, когда эти самые сущности уже давно описаны и используются в контексте языка так, как задумали разработчики. Я не думаю что они не в курсе что можно использовать числа как экземпляры класса «число», и что есть такая вещь как перегрузка операторов и т.д. Просто это не нужно для самого ПХП в большинстве случаев и незачем нагружать и без того гибкий язык лишней для него мишурой
со страрыми версиями кода. Вот обновилась версия пхп на сервере и приложение легло, потому что исключения там не обработаны. И это был бы даже не варнинг, а полное падение всего
С CSS уже намучились и продолжаем, так зачем те же грабли переносить и на backend