DleAPI v2.0

[IgorA100 90]

А кто говорит что это АПИ вообще применимо к двигу?

Ну так если что-то (в данном случае АПИ) идет в комплекте с ДЛЕ, то это что-то (АПИ) имеет самое прямое отношение к ДЛЕ. Или я не прав? Это же не сторонняя компонента написанная энтузиастом (Эээммм... вообще-то так оно и есть на самом деле )

скрипты ДЛЕ его не используют вообще

Ибо, если буду использовать, то лучше от этого точно не будет...

[ReactorGate 3]

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

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

На протяжении последних нескольких лет я совершенствую свои проекты и знания в области OOP и скажу,

что от Объектно Ориентировочного Программирования скорость нисколько не снижает, если конечно все правильно использовать.

Методы классов - это всего лишь процедуры и функции. Конечно, используя динамические типы данных в любом случае будет снижаться скорость, но можно же разделить классы на 2 типа, это динамические-компоненты и статические классы-плагины, особенно после изучения MVC мне по душе стал новый для меня паттерн Фабрика, пусть я сам того не зная иногда его использовал.

Я не углубляюсь в дебри, потому что не знаю все вплоть до более низких уровней программирования.

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

[a1ex 60]

За вас это уже сделали NGcms

[vdvseo 1]

За вас это уже сделали NGcms

Это вообще другая CMS и никакого отношения к DLE не имеет.

[a1ex 60]

Да неуж то... Внутрь посмотрите и на бд тоже

[vdvseo 1]

Пусть делает, может что путное выйдет.

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

[Apache.kiev.ua 8]

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

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

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

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

Наверное это вообще ближе к пожеланиям к новой версии, но раз уж зашел разговор про API...

[ReactorGate 3]

Начнем с того, что для выполнения процедур с данными при этом не затрагивая непосредственно все файлы в которых происходит какое-то событие,

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

1. Нашел очень простой и самый глупый вариант регистрации событий с помощью функции call_user_func_array,

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

Вывод: Стоит полностью отказаться от этих функций и самого способа.

2. Посмотрел как это реализовано у фреймворка Yii, автор компонента Диспетчера Omercan Sebboy, (в его блоге можно прочитать на английском хорошие статьи).

Быстро прочитав класс Dispatcher могу выделить основное, у нас есть динамичный массив и в него мы будем записывать Название события, класса, метода и параметры. Странно почему я сразу не пришел к такому методу, может быть потому что автор раскрыл мне глаза.

Вывод: Это единственный способ, который можно использовать для подобных целей.

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

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

[a1ex 60]

Вывод: Это единственный способ, который можно использовать для подобных целей.

Че это? Смотря как будет внутренняя архитектура. (Тем более нужна поддержка PHP4, а этот метод - только на PHP5 работает)

Возможно это специфичная структура, но у нескольких проектом у меня именно такая:

Глобальный объект, который содержит в себе все модули.

Мелкие оъекты модулей составляют массив хендлов в глобальном.

Регистрируем событие в мелком, вызывая функцию глобального, которая отправляет всем мелким объектам это событие, вызвав при этом в них функицю определённую. Вот другой подход.

Хотя ИМХО к чему этот офтоп? реализации не будет или будет но настолько последующих этапах, что и писать то и не стоит

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

[Apache.kiev.ua 8]

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

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

По требованим к софту - "Версия PHP 5.1 и выше" указано при установке, про ПХП 4 вообще ничего нет.

Изменено 11 июля 2012 пользователем Apache.kiev.ua

[ReactorGate 3]

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

Если есть заинтересованные лица в участии проекта по реализации dle на ООП, предлагаю создать отдельную тему и обсуждать возможные и правильные варианты.

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

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

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

который работает полностью на глобальных переменных вида $_SERVER['SITE_ERRORS'].

Но мне один раз и на всегда объяснили, что это не правильно, я не стал вдаваться в подробности, потому что потом сам решил,

что это ни в какие ворота не годится.

Помню в тот же день узнал о классах синглтонах, что далеко меня продвинуло в плане ООП и я узнал о паттерне фабрика.

[a1ex 60]

Мая формулировка Глобального объекта ничего общего с глобальными переменными не имеет. Под глобальным я имел ввиду стержень двига.

Да и ваше понятие отличается от нормального понятия Глобальная переменная. Причем тут $_SERVER, если используется совершенно другое.

НА будущее, не стоит писать умные слова, которые PHP4 не снились, а про фабрику - жрёт сволочь не меренно

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

[Apache.kiev.ua 8]

a1ex, при чем тут ПХП 4, откуда такая привязка именно к этой версии? На каком хостинге сейчас уже нету пятого?

ReactorGate, мне кажется, тема переписывания ДЛЕ полностью на ООП совсем не понравится Селсофту, и продолжать ее придется уже не на этом форуме (что не особо пугает, в принципе, даже интересно).

[ReactorGate 3]

НА будущее, не стоит писать умные слова, которые PHP4 не снились, а про фабрику - жрёт сволочь не меренно

Обычно я пишу только то в чем я уверен, то что я не знаю наверняка не говорю.

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

Скиньте ссылку на статью, которая это освещает я с вами соглашусь.

При чем тут php4 непонятно, хотите его поддерживать?

Чем отличается PHP4 от PHP5? Изменения включают обновление ядра Zend (Zend Engine 2), что существенно увеличило эффективность интерпретатора. Введена поддержка языка разметки XML. Полностью переработаны функции ООП, которые стали во многом схожи с моделью, используемой в Java. В частности, введён деструктор, открытые, закрытые и защищённые члены и методы, окончательные члены и методы, интерфейсы и клонирование объектов.

Нововведения, однако, были сделаны с расчётом сохранить наибольшую совместимость с кодом на предыдущих версиях языка.

Я думаю вам все же стоит перейти на php5, тем более скоро выйдет 6-ая версия и полностью заменит своих предшественников.

ReactorGate, мне кажется, тема переписывания ДЛЕ полностью на ООП совсем не понравится Селсофту, и продолжать ее придется уже не на этом форуме (что не особо пугает, в принципе, даже интересно).

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

Самое главное в проекте это дойти до релиза.

[Apache.kiev.ua 8]

Самое главное (помимо того, чтобы вообще написать его) - чтобы Селсофт не расценил это, как попытку сделать "свой лунапарк, с блекджеком и шлюхами" в обход его авторских прав и т.д.

[ReactorGate 3]

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

Его помощь в реализации была бы кстати, пусть мы знаем как устроен dle его автор знает все по мелочам.