DleAPI v2.0

[IgorA100 90]

Тема API жива или... ???

[xMandrake 0]

Жду с нетерпением вторую версию

[maxvel0007 0]

Пора вам платный раздел открывать

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

А ТУТ ВСЕ ПОМОГАЮТ ДРУГ ДРУГУ !!

А ты только и хочешь разжиться на других !!

К сожалению из-за большой нагрузки я не успел скинуть релиз Владимиру в срок.

А кто такой Владимир ??? если можно скинь мне адрес, если это не DSV ?!?!?!?!?

Изменено 21 апреля 2011 пользователем maxvel0007

[Critical Error 155]

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

А ТУТ ВСЕ ПОМОГАЮТ ДРУГ ДРУГУ !!

А ты только и хочешь разжиться на других !!

maxvel0007,

Да уж, товарищ, смекалки вам явно не хватило обратить внимание на то, что zgr состоит в группе Клиенты, а из этого следует то, что он официально является покупателем скрипта! Это во-первых. Во-вторых, борзо себя ведете вы по отношению к пользователям. В-третьих - от вас, многоуважаемый, я не видел никакой помощи на формуме. Так что не надо "ля-ля"...

А кто такой Владимир ??? если можно скинь мне адрес, если это не DSV ?!?!?!?!?

Не буду врать не знаю, что такое DSV. Но скажу вам по секрету, вы ж только никому, окЭй ?! Владимир

[dayser 0]

ужас) все гавкаются, а ведь каждый может для себя дополнять api функции, ничего сложного не вижу, главное научится собирать правильные функции. А там всё будеть чики пуки)

[blide 0]

Нужно сделать такую фичу. Единую таблицу для комментариев. То есть в таблицу добавить поле type, которое будет будет разным для разных типов комментариев. Модуль новостей - type=news, модуль блогов type=blogs и т. д. И естественно реализовать выборку, добавление и удаление комментов.

[IgorA100 90]

Я так понимаю тема API умерла?

А так все хорошо начиналось

[ATHF 33]

Может celsoft или IT-Security дадут официальный ответ будет ли дальше развиваться API ?

[flake 25]

добавьте возможность задавать "meta - title / description / keywords"

[Compton 34]

АПИ нужно для удобной разработки и поддержания модулей.

API (в том виде, в котором он предоставлен в DLE), не достаточно для удобной разработки и поддержки модулей. В самой системе должна быть некая архитектура для подключения модулей. Что такое идеально расширяемый код? Это код (ядро приложения), который не нужно править при подключении какого-то стороннего модуля. Насколько мне известно, в DLE с этим проблемы.

[celsoft 6 077]

Насколько мне известно, в DLE с этим проблемы.

Какие именно у вас с этим проблемы? http://dle-news.ru/extras/online/index.html?modules_include.html

[Compton 34]

celsoft, да уж... Инклудить php скрипт внутрь шаблона, это вы называете расширяемостью? Или в чем фишка, я наверно не просек. Я не знаю даже что вам посоветовать.. Почитайте на досуге, что такое проектирование, архитектура приложения.. Про паттерны проектирования почитайте, ага. MVC/HMVC - замечательная вещь (хотя в случае с DLE врядли поможет). Про модульность почитайте. Да что там говорить, если даже API для вашего движка написали сторонние разработчики. Это вам ни на что не намекает? Ммм, а с чего обычно начинается ваше общение с теми, у кого возникли проблемы с DLE?

После чего у вас стала появлятся данная проблема? Возможно ставили какие то сторонние модули или модификации?

Ага, милый мой, поставил кривой модуль в систему - гуляй, не мои проблемы.

А почему криво поставил? Да потому, что, чтобы расширить функционал DLE и поставить модуль, нужно править как минимум несколько файлов. И, внимание, даже engine.php! Я так понимаю этот файл подразумевался ядром системы? Содержание вашего "ядра системы" - это вообще отдельный разговор.

Как-то не практично:

case "deletenews" :

  include ENGINE_DIR . '/modules/deletenews.php';

  break;

case "comments" :

  include ENGINE_DIR . '/modules/comments.php';

  break;


case "stats" :

  include ENGINE_DIR . '/modules/stats.php';

  break;


case "addnews" :

  include ENGINE_DIR . '/modules/addnews.php';

  break;

Зачем это в ядре?

$db->query( "DELETE FROM " . PREFIX . "_subscribe WHERE news_id='{$_GET['post_id']}' AND user_id='{$_GET['user_id']}'" );

msgbox( $lang['all_info'], $lang['unsubscribe_ok']);

} else {

msgbox( $lang['all_info'], $lang['unsubscribe_err']);

}

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

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

DLE создан для профита разработчика

Но у меня не было желания потроллить вас и т.д. Я просто дал вам несколько советов, покритиковал. Надеюсь вы это поймете

Peace!

Изменено 2 июня 2012 пользователем Compton

[celsoft 6 077]

Или в чем фишка, я наверно не просек.

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

Про паттерны проектирования почитайте, ага. MVC/HMVC - замечательная вещь.

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

Ага, милый мой, поставил кривой модуль в систему - гуляй, не мои проблемы.

Ессно, если проблемы возникли из-за стороннего модуля, он будет справедливо послан натрибу... Кто виноват в этом?! Клиент, который криво поставил модуль? Сторонний разработчик, который, за неимением интерфейса взаимодействия с ядром и компонентами системы, не предоставил другого варианта подключения модуля (кроме как править файлы модулей и ядра - как же это мило)?

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

Я просто дал вам несколько советов, покритиковал.

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

$db->query( "DELETE FROM " . PREFIX . "_subscribe WHERE news_id='{$_GET['post_id']}' AND user_id='{$_GET['user_id']}'" );

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

[Compton 34]

А вы прочитайте про их тормоза и большую потребность в оперативной памяти

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

и прочий ненужных хлам связанный с этим

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

Концепция MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:

• Модель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.
  
• Представление, вид (англ. View). Отвечает за отображение информации (визуализацию). Часто в качестве представления выступает форма (окно) с графическими элементами.
  
• Контроллер (англ. Controller). Обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции.
  

А вот вы кажется этого и не поняли.

И еще раз об этом:

А вы прочитайте про их тормоза и большую потребность в оперативной памяти

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

Это я понимаю. Только вы не понимаете целей DLE, и его предназначения. DLE это фреймворк, это готовый конечный продукт предназначенный для конечного пользователя.

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

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

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

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

$db->query( "DELETE FROM " . PREFIX . "_subscribe WHERE news_id='{$_GET['post_id']}' AND user_id='{$_GET['user_id']}'" );

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

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

Изменено 2 июня 2012 пользователем Compton

[celsoft 6 077]

Это парадигма, стандарт проектирования.

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

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

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

Бегло прочитав, я долго смеялся. И все же я очень надеюсь, что перед словом фреймворк вы пропустили "не".

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

[Compton 34]

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

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

Использование объектов, классов и паттернов, триггеров и всего остального прочего должно быть оправдано преследуемыми целями

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

[celsoft 6 077]

Если бы паттерны были бы неудобны, стали бы их использовать?

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

Не, ну давайте рассуждать логически...

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

Вы считаете, что код написанный по стандарту, будет работать медленнее чем ваш "линейный" код

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

[celsoft 6 077]

Ответ очевиден. И все же, важна сама архитектура приложения. Сначала думаем, а потом реализуем. А не наоборот.

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

[a1ex 60]

Compton

В ДЛЕ нет ядра, и вряд ли будет. Да и смысла особого нет. Попробуй придумать для чего он нужен, а не просто писать модные слова.

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

[Adobe 111]

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

[Compton 34]

!= MVC

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

текущая архитектура DLE это не обдуманный шаг

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

Товарищ Компот

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

В ДЛЕ нет ядра, и вряд ли будет. Да и смысла особого нет. Попробуй придумать для чего он нужен, а не просто писать модные слова.

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

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

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

Напишите приложение полностью идентичное функциональности DLE на MVC

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

И верность данного выбора подтверждается мировым рейтингом

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

[celsoft 6 077]

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

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

Какая текущая? Которой в нет вообще? Где на сайте вашего проекта хоть слово замолвлено про архитектуру?

Ясно все. Тогда следуя вашей логики DLE тоже нет, это абстрация в паралельном мире. По вашему архитектура может существовать только если сайт увесить графиками и таблицами. Понятно. Ну в таком случае конечно нет.

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

Зачем? CMS такого рода полно, я не буду называть конкретные движки по понятным причинам.

Понятно. Обычное "бла-бла-бла". Вы сами понимаете что смысл всех ваших сообщений сейчас сводится к: "Я умею всех только учить, а когда мне говорять что либо сделать, я умываю руки, потому как дальше графиков и диаграмм я ничего не делал и не умею". Я вас не просил что либо называть, все коробочные CMS мне известны и ни одно построенное на MVC не может сравнится по производительности с DLE при равных функциональных возможностях и равных прочих условиях.

Стоит ли говорить, что почти все популярные фреймворки используют парадигму MVC?

Возвращаемся к самому первому сообщению, DLE не!!!! фреймворк.

За сим разрешите откланяться, ибо данный спор является по сути бесполезным. Вы пытаетесь что либо доказать, не имея практики. Я вам написал ранее три цели которые преследует DLE, и которые разрушает использование MVC модели, это вы никак не опровергли за все время обсуждения, что делает обсуждение бесмыссленным, потому как мы вернулись к начальной точке, когда вы только пишите: "посмотрите другие популярные CMS". DLE не менее популярная CMS а в большинстве случаев наиболее популярная, потому как не стоит забывать что DLE направлен только на русскоязычных пользователей сети, и не имеет мировой языковой поддержки и он платный в отличии от большинства коллег по цеху, а большинство людей законопослушные граждане и предпочитают бесплатный аналог если не планируют вкладывать деньги в свои проекты, а не ставить нулл. И что самое главное и интересное, самая популярная CMS в мире (это не DLE), построено не на MVC модели. И одно дело рисовать графики и диаграммы и пытаться объявить себя учителем, которого должны все слушать, а другое дело это создавать реально работающие проекты.

Поэтому я готов у вас учиться, слушать ваше опытное и экспертное мнение, но только тогда как вы создадите проект лучше, популярнее, функциональнее и главное быстрее DLE. А пока что ваши слова это популизм.

P. S. Не оскорбляйте других пользователей. Вас никто не оскорблял, а своими оскорблениями: "тупой", "типичный школьник" и т.д. Вы ставите себя не выше, а намного ниже.

[Adobe 111]

!= MVC

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

Вы не программист. А тут еще какие то парадигмы, своды знаний пошли

текущая архитектура DLE это не обдуманный шаг

Вы сами в нем не путаетесь?

Даже я в нем не путаюсь Помнится, Celsoft даже пробелы расставлял по всему коду в аргументах, чтобы смотрелось

Товарищ Компот

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

ОЙ, простите меня, если обидел Вас. Вот крест даю, всегда почему то читал Ваш ник как Компот. Думал помру со смеху Как я так мог)

p.s. по аргументам, не хотел просто переписывать то, что было сказано выше, ибо все равно бессмысленно.

Изменено 3 июня 2012 пользователем WebAdequate

[IgorA100 90]

десь смесь из php - html - js и так далее.

Вообще-то да, такое есть, и это не очень красиво и тем более не читабельно в плане кода.

Про архитектуру, MVC и подобное, скажу что не все так плохо в DLE. Взять тот-же phpBB - там вообще жесть, да и есть много еще продуктов достаточно популярных с более запутанным кодом.

Про подключение сторонних модулей - тут банальная нехватка AP и немного автоматизациI, ну НЕЛЬЗЯ назвать полноценным API то, что сейчас есть. Данный API похож на выполненное задание школьника 1го класса (извиняюсь заранее, никого не хотел обидеть).

[a1ex 60]

А кто говорит что это АПИ вообще применимо к двигу? если скрипты ДЛЕ его не используют вообще. Это отдельный класс созданный для упращения работы пользователей, хотя ИМХО не нужный. Ну есть и есть, всеравно не гибкий.

Касательно ООП - реализация на классах увеличивает расход памяти на 20% примерно, вероятно по этому его и не использует, однако в функции то можно было повторяющий код засуную.

Изменено 8 июня 2012 пользователем a1ex