Форумы портала PHP.SU » » Юмор » c форума dle-news.

 

Короче, раз за разом после таких правок появляется дырки, глюки, и т.д. Ессно, скрипт начинает лагать, тупить, появляются недокументированные возможности и т.д. Недовольный клиент идет именно на форум поддержки DLE, объясняет проблему. Ессно, если проблемы возникли из-за стороннего модуля, он будет справедливо послан натрибу... Кто виноват в этом?! Клиент, который криво поставил модуль? Сторонний разработчик, который, за неимением интерфейса взаимодействия с ядром и компонентами системы, не предоставил другого варианта подключения модуля (кроме как править файлы модулей и ядра - как же это мило)? Или вы, кто не реализовал в своей разработке общепринятых архитектурных решений (заметьте, расширяемость - это основа многих CMS и фреймворков)? Ответ очевиден. Заметьте, у разработчиков считается хорошим тоном рассказать об архитектуре их проекта (к примеру, CMS boolive!). А у DLE есть архитектура? Я сомневаюсь

А вы мне ссылку на страницу кидаете, где написано про "удобное подключение модулей". Нифига оно не удобное. За нежеланием что-то кардинально поменять в движке, вы придумали такой костыль. В идеале - скинул скрипт в папку системы и он заработал при инициализации ядра (почитайте про роутинг, контроллеры MVC, про функцию autoload в частности). В общем список продолжать можно бесконечно. Можно было все это уместить в одном предложении:
DLE создан для профита разработчика
Но у меня не было желания потроллить вас и т.д. Я просто дал вам несколько советов, покритиковал. Надеюсь вы это поймете
Peace!

celsoft:

Скорее всего.

А вы прочитайте про их тормоза и большую потребность в оперативной памяти, и прочий ненужных хлам связанный с этим. Другими словами изучите вопрос досконально, а не поверхностно прочитав модные слова. Есть одна очень замечательная вешь, ни одна CMS построенная на MVC не работает быстрее DLE, и не потребляет меньше памяти и не держит большую нагрузку. При равных одинаковых функциональных возможностях сайта.


Звучит как призыв: "Дайте нам возможность писать кривые модули", чтобы наша "кривизна" не мешала работать сайту, и мы могли бы иметь профит без отладки и тестирования.

Это я понимаю. Только вы не понимаете целей DLE, и его предназначения. DLE это не фреймворк, это готовый конечный продукт предназначенный для конечного пользователя. И его цели: 1. Максимально быстро работать. 2. Максимально меньше потреблять ресурсов сервера. 3. Дать максимально удобную концепцию работы с сайтом и шаблонами для конечного потребителя создающего сайт (вебмастера). А ваши советы рушат все три пунта и направлены только для писателей модулей. Не бывают правильных или неправильных советов в данном вопросе. Бывают полезные советы, а бывают бесполезные. Когда совет идет в разрез с преследуемыми целями, он просто бесполезен. Когда совет позволяет наоборот улучшить преследуемые цели, он полезен.

Я так понимаю это вы на предмет безопасности этот код привели? На две строчки выше глаза поднимите в коде. Или вы это написали с мыслью что под каждую GET переменную нужно вводить ненужную внутреннюю переменную.

Compton:

Причем здесь тормоза? Вы вообще понимаете, что такое паттерн проектирования (MVC в частности)? Это парадигма, стандарт проектирования.

Нет! Нет! И еще раз нет!! Как раз таки, суть MVC в том, чтобы избежать хлама и говнокода.
Концепция MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:


А вот вы кажется этого и не поняли.
И еще раз об этом:

Это уже зависит от конкретного приложения и функционала. Следовательно и методы развертывания здесь другие (отдельный сервер под кэш, отдельный под бд и т.д.). Я опять же не понял, каким образом шаблон проектирования связан с потреблением памяти....

Бегло прочитав, я долго смеялся. И все же я очень надеюсь, что перед словом фреймворк вы пропустили "не". Окей, WP тоже конечный продукт для блога. Я конечно не говорю о том, что без использования кэширования более 1000 запросов к бд это полный писец. Но я не об этом. Разработчикам WP ничто не помешало внедрить интерфейс для подключения плагинов. Что такое плагин? Подключил в админке и все работает. В DLE есть такое? Ну вот)

Неа. Это звучит как призыв к вам: "Реализуйте в своем движке мощный внутренний API и интерфейс подключения плагинов, уничтожив на корню любое желание у сторонних разработчиков писать кривые модули".

И еще вопрос. Во имя чего вы используете ООП в разработке DLE? Потому что это модная фича PHP? Ага, фича. Она, кстати, с каждой новой версией PHP совершенствуется и расшияется. Глупо не использовать такие возможности, как наследование и полиморфизм и т.д. В вашем случае помогло бы решить проблему повторяющегося кода (кстати, это еще одна суть ООП, избегать повторяющегося кода). А вообще, все упирается в проектирование архитектуры. Сначала разрабатывается план, а потому уже по плану все делается. А не сначала код пишу, а потом думаю: а зачем я вообще это делаю? К вашему сведению, на проектирование уходит до 80% затраченного на реализацию проекта времени. Что как бы намекает.


Да причем здесь вообще безопасность? Вы меня не поняли. Просто такому коду в файле, который подразумевался ядром системы, просто не место. Из-за такого и получается путаница.

celsoft:

Вот на этом в принципе можно закончить с вами дискуссию. Вы мыслите догмами из учебников. Стандартов не бывает. Тот кто мыслит стандартами, только и может делать стандартную работу.


Я вам не про код писал, а про хлам в памяти, который нужно разворачивать PHP интерпретатору, для обработки паттернов, объектов, и прочего. Запомните одну простую вешь, то что не делаете вы, кто то или что то делает за вас, в данном случае это делает PHP интерпретатор, и он не за счет воздуха работает. Все ваше проектирование в конечном итоге приводится интерпретатором PHP к линейному коду. А как вы выразились написать "говнокод" можно и на MVC модели, для этого большого ума не нужно. Самый быстрый код, это линейный код. Использование объектов, классов и паттернов, триггеров и всего остального прочего должно быть оправдано преследуемыми целями, а не потому что кто то где то написал MVC это стандарт проектирования. Это полная чушь. Вы сейчас написали чушь, написав что MVC это стандарт, MVC оправдан для написания фреймоворков, потому как фреймворки направлены в свою очередь на программистов, чтобы они могли создавать и быстро расширять свой продукт. MVC в продукте для конечного пользователя это зло, потому как заставляет конечный продукт медленно работать, потому как в нем все настроено на расширяемость, а не на быстродействие. А вы на разные цели пытаетесь надеть один стандарт. Это неправильно.

Безусловно, это опечатка. Цель предложения была что DLE именно не фреймворк.

Compton:

Ну зачем же вы так? Слишком обобщаете сущность понятия "стандарт". PHP - тоже в своем роде стандарт. И тоже накладывает некие ограничения. Тем не менее, является одним из самых популярных языков программирования для web (особенно влюбленные даже дали нам возможность писать оконные приложения, но я сейчас не о грустном ). То же самое MVC - стандарт, предъявляющий к разработчику требования реализовывать задуманное более аккуратно, практично, элегантно. Кстати, он не накладывает никаких "функциональных" ограничений. Разве это плохо? Теперь о поизводительности. Вы считаете, что код написанный по стандарту, будет работать медленнее чем ваш "линейный" код, когда в каждом файле приложения сам черт ногу сломит: здесь смесь из php - html - js и так далее. Мало того, что такой подход не обеспечит высокой скорости работы, так и простому человеку будет весьма попобольно сопровождать такой код. Обобщу: говнокод тоже весьма "стандартизирован" Его легко использовать, но последствия могут быть разными. Теперь попробуйте объяснить что паттерны проектирования влияют на скорость крупным компаниям, с целыми штатами разработчиков. Не, ну давайте рассуждать логически... Если бы паттерны были бы неудобны, стали бы их использовать? Ответ очевиден. И все же, важна сама архитектура приложения. Сначала думаем, а потом реализуем. А не наоборот.



В вашем случае оправдано использование классов? Реальное ООП в вашей системе, я увидел только в сторонней библиотеке Minify и в визивиг редакторе TinyMCE. Более - нигде.

celsoft:

Я говорил не об удобстве, я говорил совсем о другом. Где в моем сообщении вы прочитали слово неудобно?. Вы делаете неверные выводы из того что пишу, видимо на основе того что вы их поверхностно читаете.


Нет смысла. Я вам про фому, вы мне про ерему. Напишите приложение полностью идентичное функциональности DLE на MVC, а потом мы поговорим о логичности. После тестов производительности. Вы оперируете теорией, я оперирую практикой.


Я не считаю, я знаю.

Опять таки архитектура приложения != MVC, архитектура может быть какой угодно, а также "думать" != MVC. Думать нужно исходя из цели, что важнее и что приоритетней. Я вам уже написал что приоритетней для DLE. Непонятно с чего вы взяли что текущая архитектура DLE это не обдуманный шаг? Это осознанный и обдуманный шаг, который не просто продуман в теории, а проверен в "боевых условиях". И который я считаю наиболее подходящим для DLE. И верность данного выбора подтверждается мировым рейтингом http://w3techs[dot]com/technologies/[dot][dot][dot]feengine/all/all и рейтингом по рунету [url]http://itrack[dot]ru/research/cmsrate/ [/url]

a1ex:
Compton

В ДЛЕ нет ядра, и вряд ли будет. Да и смысла особого нет. Попробуй придумать для чего он нужен, а не просто писать модные слова.
Однако я соглашусь что некоторые вещи мог бы celsoft и вынести в функции хотя бы. Слишком много одного и того же кода. Зачем копипастить? кинул в функцию и забыл.

WebAdequate:
Товарищ Компот так написал, как будто тут никто не знает что такое MVC и зачем оно нужно. Хотите и я Вам скажу что на создание, изменение, высвобождение объектов требуются больше ресурсов, а это время. Товарищ либо тролль, либо переигрывает.

Compton:

Можно было и буквами написать.


Какая текущая? Которой в нет вообще? Где на сайте вашего проекта хоть слово замолвлено про архитектуру? Вы, не бось, шутите сейчас.. Да, чет возьми, откройте же код своего движка и посмотрите на него! Вы сами в нем не путаетесь? Я сомневаюсь.


Товарищ ВебНеАдекват, сами вы Компот! У вас, вероятно, вообще не оказалось аргументов для ответа, но как это обычно бывает, надо же вставить словцо! Весьма "остроумно" при этом было исказить мой ник. И таки нет, я не тролль. Посмотрите же, с чего начиналось это обсуждение. Я не писал конкретно про то, что MVC надо использовать везде и всегда. Я писал про архитектуру приложения, что таковая должна быть еще до того, как сам код системы будет написан. И поверьте, если бы она была, то в сети не возникало бы срачей по поводу: "поставил модуль на DLE - завалил систему ...". Ну, вы поняли. Погуглите штоле, я не знаю.


Товарищ, у меня нет слов.. вы вообще понимаете, что из себя представляет ядро? Вероятно, что нет, иначе бы не писали такую чепуху..


Дык, я о том же. ООП в помощь, и никаких функций.


Зачем? CMS такого рода полно, я не буду называть конкретные движки по понятным причинам. Стоит ли говорить, что почти все популярные фреймворки используют парадигму MVC? Но я таки хочу напомнить, что суть моей критики не заключалась в повсеместном использовании какого либо стандарта, я таки говорил об архитектуре. А на каких стандартах построена сама архитектура, это уже не суть! Если она есть, то это всяко поможет в будущем. Избежать говнокода в системе и предоставить удобные возможности для масштабирования.


Это уже отдельный разговор. Вы и сами прекрасно знаете, что большая часть сайтов на DLE - говносайты варезной тематики, созданные школотой на нуленных версиях. Без обид, это факт. А почему так? "Потому что просто! И шаблонов много!" - (типичный школьник)