[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Есть специалисты по Yii?
Страницы: 1, 2, 3, 4, 5, 6
DedMorozzz
Ничё твин поработает с фреймворком и поймёт все прелести оных и после за уши не оттянем smile.gif

_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
twin
Чем больше я с ним работаю, тем больше утверждаюсь во мнении, что это все от лукавого.

Вот смотри примерчик совсем маленький. Нужно вывести в поток контент. Что обычно делается в таком случае?

    echo htmlspecialchars($text);
Этого достаточно заглаза. И что мы видим в фреймворке? Да разве же можно так просто! Это же говнокод!!!
Вот как надо:
echo CHtml::encode($text);


А теперь непредвзято, без помпы рассмотрим, что это за хрень.

Залезем в метод и посмотрим, что же там такого сверхестественного:
public static function encode($text)
{
return htmlspecialchars($text,ENT_QUOTES,Yii::app()->charset);
}

Афигеть какое новшество. Преобразовали апострофы и установили кодировку. И ради этого загружать целый класс, который содержит ни больше ни меньше чем 2342 строки!!! Почти 100 килобайт!!! Застрелиться.

Не говоря ничего о прозрачности (это сколько лишней информации нужно держать в голове).

Ради чего? Ради экономии 3 символов? Вот у меня обертка есть, она короче. Так она умеет массивы обрабатывать, есть за что бороться. А это что???

Вот в этом и вся суть фреймворков. Чтобы посадить в саду гортензию мы садимся на шагающий экскаватор. А перед этим еще нужно пару лет поучиться им управлять...

Нет уж, будь спокоен за мои уши. Только по особой необходимости, когда нет выбора. А так я на километр к ним не подойду, к фреймворкам этим.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Invis1ble
twin
ну дык обертка обыкновенная, для гибкости
поведение функции ядра ты никак не поменяешь, а обертку изменить легко и просто

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

paul85
twin, вот и я не понимаю этих фреймворков. Именно с такой же формулировкой. Как по мне, тогда уж изучать Ruby on rails. Ну или DJango, какой-нибудь. Хоть платформа другая, может быть пригодится. А тратить время на изучение каких-то безумных функций, которые, кстати, сплошь и рядом, совершенно нет ни малейшего желания. Даже классы надо называть по-особенному.

Но главное нет ни малейшего ощущения, что это хоть сколько-нибудь удобно или безопасно. А захочется перейти на другой? Там опять все по-новому. Да уж проще свой фреймворк запилить и модифицировать его по мере надобности.
kaww
paul85, если следовать этой логике, то стоит писать сайты на каком нибудь С (хотя иногда это оправдано),а не учить функции пхп, которые тоже "обертка" сишных (:file_get_contents). Так же как и пхп позволяет облегчить такие операции как, например, получение параметров запроса (не рассматриваем сишные библиотеки, это ведь тоже как бы фреймворки), так и пхп-фреймворк служит для автоматизации выполнения каких-то задач.
Цитата (paul85 @ 3.07.2013 - 19:44)
Как по мне, тогда уж изучать Ruby on rails. Ну или DJango, какой-нибудь

, а почему рельсы, это ведь фреймворк который написан на Ruby, как и Django, написанный на python'e?

И по поводу Yii, даже в приведенном twin'ом примере public static function encode($text), видно, что метод имеет не явную зависимость от Yii::app(), что не позволяет использовать отдельно компоненты фреймворка. Посмотрел код - эти ребята очень любят singleton smile.gif
paul85
Цитата
если следовать этой логике, то стоит писать сайты на каком нибудь С

Ну да, это был бы самый лучший вариант. Просто в С очень много проблем пришлось бы решать с типизацией данных.
Цитата
не рассматриваем сишные библиотеки, это ведь тоже как бы фреймворки

Не совсем согласен. Все-таки фреймфорк - это набор библиотек. С этой точки зрения С и есть фреймфорк. Ну отчасти так оно и есть, если его рассматривать как абстракцию над ассемблером, а не как отдельный язык.

ИМХО дело в популярности. Очень врядли PHP в ближайшие лет 5 уйдет со сцены. Осмелюсь предположить, что он даже не уступит место мейнстрима в web разработке.

Цитата
а почему рельсы, это ведь фреймворк который написан на Ruby, как и Django, написанный на python'e?

Я к тому, что если уж забивать голову фреймворком и тратить на это время, то хотя бы попутно изучить другую платформу. Хоть какой-то толк будет, если изучаемый фреймворк прекратит свое существование. Или станет совершенно невостребованным.
DedMorozzz
Цитата (paul85 @ 4.07.2013 - 20:38)
Хоть какой-то толк будет, если изучаемый фреймворк прекратит свое существование. Или станет совершенно невостребованным.

Ну вот ненадо чушь писать. Фреймворк это набор готовых решений. И по сути все фреймворки, так или иначе - похожи.
И даже если в 1н миг исчезнут ве фреймворки, ничего разработчику не мешает самому написать эти готовые решения. Он знает что ему надо и делает, всё просто
Другой вопрос, что каждый раз надо будет велосипеды писать.
И у каждого разработчика "с нуля" имеется набор своих, тех же самых решений, любой фреймворк это стандатизирует, а не миллиард разных велосипедов, делающих одно и то же

_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
Dezigo
Можешь вообще не использовать и отказаться от этих
CHtml::encode($text);
, а писать как ты хочешь.

Если это не ускоряет работу, а наоборот то, это не выгодно.
Главное это структура и набор правил.
killer8080
Цитата (twin @ 3.07.2013 - 20:40)
Вот смотри примерчик совсем маленький. Нужно вывести в поток контент. Что обычно делается в таком случае?
     echo htmlspecialchars($text);

вот буквально недавно сталкивался с проблемой, после миграции с php 5.3, на 5.4, сайт упал, проблема была как раз в таких строчках smile.gif
Пришлось вручную лопатить весь код, и прописывать кодировки.
twin
Цитата (Dezigo @ 5.07.2013 - 10:05)
Можешь вообще не использовать и отказаться от этих
...... , а писать как ты хочешь.

Если это не ускоряет работу, а наоборот  то, это не выгодно.
Главное это структура и набор правил.

Смысл тогда вообще в фреймворке, если писать так, как хочешь...
Весь сакраментальный его смысл как раз в том, что нужно этим правилам следовать.

Допустим, есть правило. Любая модель должна наследоваться от базовой модели. Если я не буду этого делать, значит нарушу правило. Если буду - потащу за собой класс CModel, который потащит CComponent и пару интерфейсов, в общей сложности еще полторы тысячи строк. Фиг с ним, там 80% - комменты, однако потащит же. А мне оттуда ну ничегошеньки не нужно.

Да я не против, если возникают сложности с корпортивным стилем и этикой, то конечно такой свод правил поможет. Но какой ценой...

killer8080
Цитата
вот буквально недавно сталкивался с проблемой, после миграции с php 5.3, на 5.4, сайт упал, проблема была как раз в таких строчках
Пришлось вручную лопатить весь код, и прописывать кодировки.
В армии у нас анекдот ходил. Что срочно нужно сделать ревизию всей техники, так как в соседней деревне телега поломалась.

Это очень слабый аргумент. Я бы сказал - никакой. А если порыться глубже - антиаргумент. Потому что всего предусмотреть нельзя, а фреймворк пытается. И вот для решения какой то экзотической проблемы, которая где то в соседней деревне может никогда и не наступить, мы вынуждены всю жизнь таскать на себе всё, что может в жизни пригодиться. Оно может и пригодится, но бегать с этим... Только тяжко переваливаться, страдая отдышкой и пунцовостью морды.

Вот классический пример фреймворка, примерно так я его себе и представляю. Горе от ума:

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
inpost
killer8080
Идеальный фреймворк:
function myHtmlspecialchars($var) {
return htmlspecialchars($var);
}
function myIntval($var) {
return intval($var);
}

... и так далее тупого перечисления всех существующих функций. Авось одну из них точно так же как и htmlspecialchars решат поменять разработчики... А нам потом весь код всех сайтов переписывать. Браво разработчикам PHP.

Версии 5.4, 5.5 - как такие можно было сделать, это плевок всем программистам в душу.
Особенно радует существования двух абсолютно одинаковых по существую функций, где вторая функция имеет новый подход к реализации, поэтому старая считается недействительной, чего только стоит (грубо говоря):
mysql_query("запрос");
Срочно надо переписать на:
mysqli_query("запрос");
Вместо того, чтобы функционал функции mysqli просто перенести в mysql.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
glock18
Цитата (inpost @ 17.07.2013 - 14:18)
killer8080
Идеальный фреймворк:
function myHtmlspecialchars($var) {
return htmlspecialchars($var);
}
function myIntval($var) {
return intval($var);
}

... и так далее тупого перечисления всех существующих функций. Авось одну из них точно так же как и htmlspecialchars решат поменять разработчики... А нам потом весь код всех сайтов переписывать. Браво разработчикам PHP.

Версии 5.4, 5.5 - как такие можно было сделать, это плевок всем программистам в душу.
Особенно радует существования двух абсолютно одинаковых по существую функций, где вторая функция имеет новый подход к реализации, поэтому старая считается недействительной, чего только стоит (грубо говоря):
mysql_query("запрос");
Срочно надо переписать на:
mysqli_query("запрос");
Вместо того, чтобы функционал функции mysqli просто перенести в mysql.

Улыбнул. Упаси меня такой фреймворк увидеть, в котором нужно в его исходник лезть, чтобы поменять способ экранирования html...

Цитата
mysql_query("запрос");
Срочно надо переписать на:
mysqli_query("запрос");
Вместо того, чтобы функционал функции mysqli просто перенести в mysql.


ну, это как бы разные либы совсем. И использование их тоже отличается, функции разные. Ты ведь не думаешь, что обе они ограничены функциями *_query. К тому же mysql_lib еще доступен в прежнем виде, а то о чем ты говоришь, заставило бы всех свои старые сайты переписывать под новую либу. Интерфейсы то они разные используют
inpost
glock18
в 5.5 считается устаревшим mysql. Или можно ошибки устаревшими отключать, чтобы не ругалось только на определённые функции?

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
twin
Цитата (inpost @ 17.07.2013 - 14:18)
Версии 5.4, 5.5 - как такие можно было сделать, это плевок всем программистам в душу.

Тут ты не прав. Все течет, все меняется. И меняется к лучшему. Что касается htmlspecialchars() - никогда такой проблемы не возникнет, если пользоваться UTF-8, к чему все и ведется. Если юзаешь местечковые кодировки, будь готов к казусам, как killer8080, но тогда и думай заранее и не плачь потом, что фреймворк не помог. Так можно договориться до того, что и var нужно было сделать обратносовместимой конструкцией. Вдруг кто-нибудь на 4 ветке привык писать и не хочет прогресса.

А что касается mysqli_*, так оно и правильно, ибо иначе путаница может возникнуть при миграции.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
inpost
twin
Неужели сложно написать так:
function mysql_query($query,$link) {
return mysqli_query($link,$query);
}

Нет, ну ты то откажешься от такой конструкции, тебе лишь бы отказаться, дай повод)
А сейчас тысячи программистов сидят и переписывают свои коды лишь потому, что захотелось разрабам отключить mysql.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.