Если бы хостеры ещё поддержали. А то ж клиенты часто скупедяи страшные. Рулят какой-нибудь крутой компанией и при этом утверждают, что на VPS у них денег нет. Вот и приходится сидеть на самом убогом тарифе какого-нибудь левого хостера. На ПХП. Перловцам в этом смысле хорошо — он всё-таки часто входит даже в самый убогий тариф.
Ну просто в тему. Я в принципе терпимо умею использовать jquery и всякие-там фреймворки а-ля Zend, но… Когда пишу вместе с коллегами — использую то, что нужно для командной разработки. Когда на фрилансе — юзаю чистый JS и свои мини-фреймворк со своим же шаблонизатором. Просто потому, что мне так удобнее. Я пишу один, заказчику пофиг — так чего бы не пописать в удовольствие так как нравится? Ну правда я ещё обычно закладываюсь на возможности расширения и изменения. Это самое главное. Собственно, по этому критерию скорее и можно оценивать качество. Чистый JS и чистый PHP — это не всегда плохо.
Не всегда. Я бы с первого раза не стал такого утверждать. Главное найти подход. Некоторым надо граматно намекнуть, что у тебя больший опыт и учить его не покладая рук. Они будут благодарны. Других тупо прессануть. Будут дуться, но потом их тоже можно поучить и вывести в адекват. Черезвычайно упёртых дарований не так уж много, просто многим как раз нужен нормальный руководитель.
Прочитал вместе со всеми комментариями. Так и не понял, зачем огород городить. Не понятно в чём выигрыш. Технологии развиваются довольно логично. Нужны богатые клиентские приложения — появляется Flex. 90% того, что можно было выжать из ява-скрипта (по-моему) выжали в ExtJS. Генераторы JS на разных серверных языках тоже плодятся как грибы, чтоб не писать ни одной строчки на JS вообще (видимо подход, обратный вашему). Если вам и того и другого недостаточно, то пора писать свои клиенты на той же Яве, а не мучить браузер.
Ну и маленькая добавочка. Вы там пишите, что не испольуете особенностей конкретной БД. Как раз сегодня с колегой дискутировал на подобную тему, только относительно языков. Универсальность — это конечно здорово, но в большинстве случаев не используя преимущество той или иной базы или языка вы затрудняете сами себе разработку и, в большенстве случаев, колечите производительность.
Ну это традиция скорее. Я ничего против MVC не имею, но если есть возможность делать так, как удобнее мне, то я делаю как удобнее мне. Страха призрака MVC, душащего по ночам нерадивых программеров у меня нету.
Вопрос риторический? Мне в модели и дескрипшен не нужен. Что ж его теперь из базы не тянуть? Просто у меня такой подход. Все управленческие функции возлагаются на модель. База служит грудой информации, шаблон — местом втыкания информации. Для всего остального есть модель. Такой вариант мне удобнее всего.
Повторюсь, в случае необходимости я могу работать по другому, навтыкав в базу foregin key'ев в режиме cascade и терпя использование верстальщиком вольностей Smarty. В случае, если мне объяснят, зачем это нужно. Ну или если это просто критично для командной разработки.
Отличная новость! Если Django станет возможным использовать и в бюджетных проектах — буду грести в эту сторону. А то сейчас народ по большей части хочет «как у всех на PHP». Но расхвалить Django не составит труда, а вот с бюджетным хостингом пока туго.
Хе-хе. Тогда надо ещё и сканер на комп ставить, а то у меня и в pdf много интересных книжек лежит. Ну а уж про манагеров с сапёром и пасьянсом я вообще молчу.
В чём нарушение? Три разных набора символов и там и там дают 3 разных результата. С тем же успехом можно сказать, что '', '=', '!=' — три разные сущности.
В принципе можно такую раскраску запихать как в шаблонизатор, так и в модель. Я предпочитаю всё делать на уровне модели. Опять таки какая разница, где писать "$i % 2?…: ..."?
Да, я очень не люблю «шаблонизаторы» вида include 'template.php' и все их подвиды. Пока меня ещё никто не убедил, что в таком подходе есть какие-то преимущества.
Гм. Не знаю как по студиям, а по фрилансу сейчас народ просто взбесился в хорошем смысле слова. Может ищут где подешевле или ещё чего, но ко мне последнее время просто ломятся сайты заказывать.
Не оценю. Какая нафиг логика в шаблоне? Заполнено поле — вывести, не заполнено — не выводить. Всё. Нечего тут сравнивать с логикой в модели / конроллере. Там она сколь угодно сложной может быть. И, по крайней мере, нормальный шаблонизатор никогда не позволит «подхачить» юному дарованию и преопределить, например, сессионную переменную (как это позволяет тот же Zend_View). Понятно, что за такое надо руки отрывать, но перед этим придётся ещё несколько часов побится головой об монитор, чтобы найти такую шутку. В топку такое удовольствие.
Про шаблоны. Вот радости-то написать {% if a eq b %} вместо {% ifequal a b %}. Попробуйте относится к ним как к if с прилепленным оператором. )
Опять таки ни разу ещё не встречал задачи, с которой бы не справился Django-шаблонизатор. Наследование шаблонов, if и for — всё что нужно. В принципе когда доводилось работать с очень хорошими верстальщиками они просто давали разный css для разных типов страниц и всё само перевёрстывалось до неузнаваемости. Но таких мало.
Шаблонизаторы нужны, чтобы бить по рукам тех, кто хочет запихать логику в шаблон. И мне на это обычно никакой производительности не жалко. Лично у меня очень консервативный взгляд на структуру. База должна быть просто свалкой данных. Шаблонизатор должен просто втыкать переменные в нужные места HTML разметки. Этот вариант оптимален. Можно использовать в базе триггеры и отказываться от шаблонов. Но только если это оправдано какими-то соображениями.
Лучший шаблонизатор у Django. Ничего лишнего не позволяет.
Ну и маленькая добавочка. Вы там пишите, что не испольуете особенностей конкретной БД. Как раз сегодня с колегой дискутировал на подобную тему, только относительно языков. Универсальность — это конечно здорово, но в большинстве случаев не используя преимущество той или иной базы или языка вы затрудняете сами себе разработку и, в большенстве случаев, колечите производительность.
Повторюсь, в случае необходимости я могу работать по другому, навтыкав в базу foregin key'ев в режиме cascade и терпя использование верстальщиком вольностей Smarty. В случае, если мне объяснят, зачем это нужно. Ну или если это просто критично для командной разработки.
Да, я очень не люблю «шаблонизаторы» вида include 'template.php' и все их подвиды. Пока меня ещё никто не убедил, что в таком подходе есть какие-то преимущества.
Про шаблоны. Вот радости-то написать {% if a eq b %} вместо {% ifequal a b %}. Попробуйте относится к ним как к if с прилепленным оператором. )
Лучший шаблонизатор у Django. Ничего лишнего не позволяет.