[php ненужно] Риторический вопрос

Так везде это. Думаешь в .Net лучше?

«Что бы заюзать пару простых функций - качаем библиотеки. Качаем и качаем...»

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

Еще скажи, что у дивов, которые ты двигал свойства не в css были. При чем тут php, изначально значит неправильно сделали.

> Так везде это. Думаешь в .Net лучше?

Для меня не модель MVC под вопросом. Мне абсолютно неясна тяга к ней похапешников. Может я какие новые дельфиобразные IDE, прослоупочил? Но возится с этим трешем руками - полный идиотизм. Вот собственно и возник вопрос «Зачем»? Просто настолько популярно, что мне начинает казаться что я чего-то не понимаю или не замечаю.

Я тоже нередко сталкиваюсь с такой ситуацией, когда разрабы делают что-то «по-модному», но в итоге получается через задницу, хотя и с применением «модного» и «полноценного». Они это называют жертвой в пользу полноценности и модности. Я это называю яростным желанием пропускать этап проектирования продукта и просто раздолбайством.

> Еще скажи, что у дивов, которые ты двигал свойства не в css были.

Причём тут css? В css вложенность блоков не меняется.

>Для меня не модель MVC под вопросом. Мне абсолютно неясна тяга к ней похапешников.
Я что-то не понимаю? Что может быть проще чем, работа с базой+интерпретация результатов+шаблон?

> В том же drupal блок можно передвинуть особо не мучаясь

Это не drupal. Но и drupal, мягко говоря тот ещё маразм.

Ну давайте все размажем по тысяче инклудов безызвестных и в магических директориях вроде «utils», удобно ведь с ОО, вопрос в реализации

>Это не drupal. Но и drupal, мягко говоря тот ещё маразм.
Может и маразм, но приличных аналогов Views и CCK я нигде не видел. Где еще можно делать страницы с произвольным образом сгруппированными записями произвольной структуры за считанные минуты?

> Я что-то не понимаю? Что может быть проще чем, работа с базой+интерпретация результатов+шаблон?

Реализация.

Объект БД->Объект данные->Объект Пользователь->Объект тема->Объект ещё ченибудь и такого онанизма на целую UML схему, размазанного по куче каталогов, почти не поддающемуся анализу без IDE, и всё это на интерпретируемом языке? Это называется просто?

В православном Zend Framework есть «папочка» views, в которой валяются *.phtml файлы, их то и нужно было бы править.
А что может быть проще, чем заюзать родной php-шный Zend Framework?

> всё это на интерпретируемом языке?

Было бы на java, например, там еще с десяток интерфейсов с классами родилось ну и в зависимостях какой-нить GWT прилетел

> Где еще можно делать страницы с произвольным образом сгруппированными записями произвольной структуры за считанные минуты?

Вот именно про «считанные минуты» - не надо.

>Объект БД->Объект данные->Объект Пользователь->Объект тема->Объект ещё ченибудь и такого онанизма на целую UML схему, размазанного по куче каталогов, почти не поддающемуся анализу без IDE, и всё это на интерпретируемом языке? Это называется просто?
Ну вы с умлянанистами не общайтесь. В той же symfony обычно идет обычная ORM, в контроллере достаются данные из базы через orm, и кладутся в переменные контроллера через this. Которые потом передаются в шаблон и в шаблоне используются по имени. Где здесь сложность то?
П.С.
Я сам в проекте основную массу кода пишу через vim, сложностей особых не доставляет.

>Вот именно про «считанные минуты» - не надо.
Я не гоню. Там можно через браузер используя CCK создать произвольный тип статей. А потом через views описать как их показывать, фильтры там и прочее.
http://www.master-live.ru/views_nivo_slider.html вот нагугленный урок. Там все по шагам описано.

> в которой валяются *.phtml файлы

Да и насколько я помню. Они являются темплейтами, которые очень тяжко относятся к смене иерархии объектов. А прямое создание в них объектов минует кэширование которое хоть как-то спасает это ноповоротливое Г.

> Я сам в проекте основную массу кода пишу через vim, сложностей особых не доставляет.

Из всех php-шных фреймворков, какой можно назвать более менее легковесным?

>Да и насколько я помню. Они являются темплейтами, которые очень тяжко относятся к смене иерархии объектов. А прямое создание в них объектов минует кэширование которое хоть как-то спасает это ноповоротливое Г.
Товарисч, вы на какой технологии сами то разрабатываете. А то немного непонятно с чем сравниваете. Это же просто фреймворк, там может быть включено кэширование в БД, которое кэширует отдельные запросы на уровне БД. И может быть кэширование каждого шаблона(с уже загруженными данными). И нет никакой разницы в способах попадания данных в шаблон.
П.С.
И объекты не надо создавать в шаблонах, для этого есть контроллеры.

>Из всех php-шных фреймворков, какой можно назвать более менее легковесным?
F3. Только я не понимаю в чем смысл легковесности. Они итак едят намного меньше тех же рельсов.

> Товарисч, вы на какой технологии сами то разрабатываете.

Я вообще не из этой оперы, просто знаю PHP, когда-то возился с вордпрессами и немного рублю в RoR. Просто иногда приходится подтирать за молодёжью, когда нарисовывается перспектива потерять клиента.

$this->view->message = 'Page not found';

<h1>An error occurred</h1>
<h2><?php echo $this->message ?></h2>

> Они являются темплейтами, которые очень тяжко относятся к смене иерархии объектов.

О какой иерархии идет речь?

> Они итак едят намного меньше тех же рельсов.

Легковесные по структуре. За исходники которых можно засесть в начале недели, и к концу, иметь представление о внутренней структуре.

>Я вообще не из этой оперы, просто знаю PHP, когда-то возился с вордпрессами и немного рублю в RoR. Просто иногда приходится подтирать за молодёжью, когда нарисовывается перспектива потерять клиента.
Посоветуйте молодежи прочитать хотя-бы одну книгу конкретно по технологии которую они используют. Уменьшит количество костылей на порядок.

>Легковесные по структуре. За исходники которых можно засесть в начале недели, и к концу, иметь представление о внутренней структуре.
Ну совсем уж малым кодом большой проект не описать. А в современных фреймворках много чего есть. Из фреймворков лучше всего написанны Zend, Symfony, CakePHP, Yii. А из простых с нормальным кодом - kohana. Но если будете делать крупный проект, то все равно то что в крупных фреймворках придется заново писать.

> О какой иерархии идет речь?

Magento это же вроде zend? Вот там вытянуть скажем продукты по какому либо критерию в пользовательский дашборд, можно было либо нарисовав создание кастомной выборки в темплейте и это не попадало в кэш. Либо страдать хернёй создавая новый объект «кастомная категория» и это всё чтобы взять селект из базы и прогнать выхлоп через темплейт? Вот мне и непонятно это все руками делают или есть какие-то средства автоматизации?

> Может ЛОР подскажет, что я упускаю из виду?

The computer industry is the only industry that is more fashion-driven than women’s fashion. © Larry Ellison, Oracle, Sept 26, 2008

> Ну совсем уж малым кодом большой проект не описать.

У нас есть один фрилансер, правда дорогой. Так вот магазин уровня магенты он делает за 2 недели и очень дорого. При этом конечно же дешевле наши местные бакланы, которые две недели натягивают кастомную тему на магенто. Так вот проекты этого чудика (ну странный он немного), при равных возможностях весят где то около полу-метра в исходниках и просто летают, а всего-то зюмель+похапэ без всякого MVC. Я сильно сомневаюсь что он некий «тёмный гений».

Не так плох php, как те, кто его используют >_< При грамотном проектировании описанной ситуации возникнуть не должно было.

PS. Вы предпочитаете писать все лапшекодом (привет, Mantis)?

> привет, Mantis

А что это? Слышал про это, но что-то гугель говорит про багтрекер.

>У нас есть один фрилансер, правда дорогой. Так вот магазин уровня магенты он делает за 2 недели и очень дорого. При этом конечно же дешевле наши местные бакланы, которые две недели натягивают кастомную тему на магенто. Так вот проекты этого чудика (ну странный он немного), при равных возможностях весят где то около полу-метра в исходниках и просто летают, а всего-то зюмель+похапэ без всякого MVC. Я сильно сомневаюсь что он некий «тёмный гений».
Как вы думаете, использует ли он какой-то фреймворк, если при скорости работы стенографистки 500 символов в минуту, на этот код потребовалось бы 2 рабочих дня непрерывного печатания? Да и сомневаюсь я, что у него нет MVC. Не весь же код у него лапшой идет, иначе бы при натягивании темы был бы серьезный геморой.
Плюс magento - это шаблонное решение. Естественно при его допиливании надо соблюдать какие-то внутренние правила, если хочется получить фишки. Я не думаю, что в код того фрилансера можно внедрить изменения намного легче.

>Magento это же вроде zend? Вот там вытянуть скажем продукты по какому либо критерию в пользовательский дашборд, можно было либо нарисовав создание кастомной выборки в темплейте и это не попадало в кэш. Либо страдать хернёй создавая новый объект «кастомная категория» и это всё чтобы взять селект из базы и прогнать выхлоп через темплейт? Вот мне и непонятно это все руками делают или есть какие-то средства автоматизации?
Это такой же Zend, как ЛОР - java se. Там нагородили кучу кода, чтобы поддерживались всякие категории товаров и вычисления цены. И я не доганяю пока почему создание кастомной категории для продуктов кастомной категории является страданием херней.

>А что это? Слышал про это, но что-то гугель говорит про багтрекер.

Именно он. Исходники там полный АдЪ. Весь дизайн в php файлах, причем в одном файле уживаются еще логика и запросы к БД...

> Как вы думаете, использует ли он какой-то фреймворк

Что-то своё с самописным плагином для толи нетбинса то-ли идеи (он когда-то через коллегу её покупал). Просто судя по тому, что он не только для нас работает, я сомневаюсь, что он две недели сидит и тупо строчит код.

Надо будет посмотреть его проекты повнимательнее.

MVC - великолепная модель, просто некоторые начинают своё изучение программирования именно с неё, вот и получается дурдом.
Я до использования фреймфорков 5 лет кодил функциональщиной, потом уже 3 года с объектами и только в этом году открыл для себя фреймворки (при этом обнаружил, что уже сам для себя написал MVC, соврешенно о не зная о такой технологии, т.е сделал велосипед)

>Для меня не модель MVC под вопросом. Мне абсолютно неясна тяга к ней похапешников.

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

желаю тебе провести полгода в колупании потрохов вордпресса и мантиса

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

Попробуй разработать свой «PHP» тогда поймёшь. Вроде бы, уже вполне взрослый человек а всё ещё задаётся детскими вопросами. Надобно, однако, эмпирировать уже, однако.

ну, mvc разные бывают. Я их тоже дико ненавидел, пока не увидел symphony и yii framework. Особенно yii. Вот это пример, каким должен быть mvc фреймворк.

Технологии они проблемы не создают. Их создают криворукие прыграмисты.

про насколько больной проект ты говоришь? :) При правильно структурированной системе каталогов и правильно сделаной архитектуре, проблем быть не должно.

>При правильно структурированной системе каталогов и правильно сделанной архитектуре проблем быть не должно.

Во-во. И архитектура такая называется MVC :) MVC — это всего лишь ещё один уровень абстракции, применяемый для облегчения труда программиста. Не знаю, что конкретно ты имеешь в виду под «правильно структурированной системой каталогов», но эта система наверняка тоже имеет своей целью ввести ещё один уровень абстракции.

про насколько больной проект ты говоришь? :)

Он был неизлечим. Там даже классы не использовались, а функций было, вроде, две на несколько тысяч строк кода.

> Вроде бы, уже вполне взрослый человек а всё ещё задаётся детскими вопросами.

Детскими. Ок. Задача web-аппликуха. Три группы пользователей с ролями «заливающие», «проверяющие», «смотрящие». Первые закидывают типизованный файл, вторые проверяют его корректность и дают/недают статус валидности. Третьи смотрят на то кто когда залил и результаты переработки. Надо объяснять почему тут оверхеды не нужны?

Кажется разобрался. По-ходу, тут и наши балбесы наумничали и я дотупил. Но один фиг. Лучше пользовать OO в более предназначенных для этого языках нежели PHP.

>Это называется просто?

Простота - критерий гениальности. А дебилы городят заборы из костылей

>Почему php-шники так аццки вцепились в OO и этот грёбаный MVC?

Потому что быстро и удобно.

Подправлял тут один проектик... чтоб два блока передвинуть пришлось поковырять 5-6 объектов

Значит проект такой. И без ООП вряд ли было бы лучше :D

Про скорость разработки интересно было бы узнать как это «быстро делается»?

Ну, скажем так, обжитая объектная+MVC модель позволяет за вечер писать столько, сколько когда-то на голых функциях без чёткой структуризации за 2-3 дня писалось и потом ещё столько же отлаживалось. А когда, год спустя, нужно правку внести, в объектной (опять же, в широком смысле) модели просто берёшь и вносишь, исправляя пару строк, в процедурно-размазанной - сперва час разбираешься, где нужно исправить, потом час вносишь исправления с проверками, потом через день-два всё опять исправляешь, потому что, опять же, никаких юниттестов и прочего...

>Мне абсолютно неясна тяга к ней похапешников

И тут PHP не при чём. Всегда удобно, когда у тебя в гастрономе продают колбасу, в метро занимаются перевозками, а в бижутерии лежат всякие серьги и браслеты. А если тебе в поисках пункта оплаты мобильного приходится идти не в пункт оплаты, а в институт связи - то это не хорошо :)

ты готов дать гарантию того, что завтра не появится ещё 2 роли, 3 типа файлов и 6 юзкейсов? А так же, что если они появятся, то удачно впишутся в не ООП код.

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

Где еще можно делать страницы с произвольным образом сгруппированными записями произвольной структуры за считанные минуты?

У меня, наверное :D

Что-то типа такого?

class my_cool_page extends bors_paginated
{
    function title() { return 'Это страничка с товарами производителя '.$this->brand()->title(); }
    function main_class() { return 'my_cool_class'; }
    function where() { return array('brand_id' => $this->id()); }
    function order() { return '-name'; }
    function auto_objects()
    {
        return array(
            'brand' => 'my_brand(id)',
        );
    }
}

>Это называется просто?

Угу. Потому что в крупном проекте (да и в среднем) все связи в голову просто физически не поместятся. Так что без объектов (выделенных сущностей, не важно по какому принципу) и их чётких API проект просто невозможен. Если же у тебя есть некие выделенные инкапсулированные независимые структуры без сайд-эффектов, то работать много проще. И, о чудо, такие структуры обычно называются объектами :D