1

Тема: DLE API - быть или не быть?

Вот сижу, пытаюсь начать изучать ООП и применить это дело к DLE.

Вот допустим мы пишем простенький модуль, выводящий список новостей с разными параметрами, сортировкий и т.п.
Зачем подключать DLE API? Только из-за 3х методов (получение, запись кеша и получение новостей).
Взять тот же LinkEnso, его же можно было и без dle_api написать, зачем же тогда подключать?
Объясните, пожалуйста, несведущему человеку ).

2

Re: DLE API - быть или не быть?

ПафНутиЙ пишет:

зачем же тогда подключать?

Когда пишешь что-то, что должно быть внедрено в чужой скрипт, прежде всего нужно понять логику этого скрипта и ей следовать, чтобы твой код в него правильно вписался. Если это joomla - используй mvc-паттерн и местный фреймворк. В случае DLE мне показалось весьма логичным использование DLE_API. Особенно вот это -

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

Шикарно звучит, не правда ли? В общем-то, факт использования DLE_API в моих модулях - это дань уважения этому, так убедительно написанному, тексту. В теории этот класс должен обновляться при структурных изменениях движка, а модули продолжали бы работать с тем же исходным кодом. Но, на сколько я вижу, разработчик DLE вообще не особо стремится к изменению структуры и совершенствованию кода. Но если всё же API есть, почему бы его не применить?
А вообще, тот API, что можно увидеть у них внутри, гораздо полезне, чем встроенный в движок smile Как и обещал, когда-нибудь сделаю свой DLE_API smile

3

Re: DLE API - быть или не быть?

Да, всё же API использовать "оправданнее" именно из за, хотя бы теоретической, поддержки будущих версий))) Жаль что и API давно не развивается, как собственно и сам двиг, одни лишь украшения.

4

Re: DLE API - быть или не быть?

ПафНутиЙ пишет:

одни лишь украшения.

Именно. Я совсем недавно помогал одному заказчику кое-что поправить в 7 поколении DLE. В базовом php коде вообще мало что изменилось. Хотя технологии шагнули вперед. Так что, нельзя назвать его современным, не смотря ни на какие украшения в виде jquery плагинов))

5

Re: DLE API - быть или не быть?

И всё же опять у меня возникают сомнения по поводу полезности использования DLE_API в процессе написания модуля.

В новых версиях DLE изменилось местоположение храниения некоторых данных новостей.
В итоге через DLE_API нельзя вывести количество просмотров новостей (к примеру) как в 9.5
Вот такой код:

$news = $this->dle_api->load_table (PREFIX."_post", "*", 'approve = 1', true, 0, 10, 'date', 'ASC'); - работает
$news = $this->dle_api->load_table (PREFIX."_post", "*", 'approve = 1', true, 0, 10, 'news_read', 'ASC'); - ошибка, т.к. нету news_read

Как быть? Ведь если не ошибаюсь API не может сразу в 2 таблицы сделать запрос.

6

Re: DLE API - быть или не быть?

JOIN для объединения таблиц

7

Re: DLE API - быть или не быть?

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

8

Re: DLE API - быть или не быть?

Метод load_table() в данном случае подразумевает, что, делая запрос к базе данных, ты знаешь структуру таблицы. По логике вещей он ни к чему не обязывает, т.к. с его помощью можно сделать запрос к любой таблице с любой структурой, и за изменение структуры он не ответственен.
Методы, которые получают саму новость - по-прежнему получают саму новость. Другой вопрос, что в полученном массиве уже будут не все поля smile Но опять таки, по логике вещей эти методы должны получить модель статьи, соответственно, тоже ни к чему не обязывают smile
Но, в итоге, существующий DLE_API - совершенно бесполезная вещь, если его никто не будет развивать.

9

Re: DLE API - быть или не быть?

Я вчера избавился dle_api в модуле т.к. время выполнения модуля после кеширования в !5-7 раз больше такового без использования api. без кеширования - не критично, но тоже больше + увеличение расхода оперативы.
Постараюсь позже оформить статейку с цифрами и замерами, думаю многим будет полезно знать о бесполезности DLE_API в нынешнем виде.

10

Re: DLE API - быть или не быть?

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

11

Re: DLE API - быть или не быть?

Мы уже разговаривали по этому поводу) Саша хочет открытым сделать свой API.
Но сейчас, занимаясь написанием модуля я больше склоняюсь не к api, а к набору методов, потому что подключать api = утяжелять работу модуля, а если тупо скопипастить  нужные методы - будет гораздо удобнее.
Я к примеру так и с делал с методом load_table() - ускорив тем самым работу модуля, не сильно, но как говорится - копейка рубль бережет.

12

Re: DLE API - быть или не быть?

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

13

Re: DLE API - быть или не быть?

Так как обстоят дела с API? есть у кого-нибудь наработки? Самому писать все с нуля не очень хочется..

14 (02.07.2013 16:19 отредактировано ПафНутиЙ)

Re: DLE API - быть или не быть?

sngrl, НИКАК (у меня не сломался капс, именно так и есть, API не развивается уже несколько лет).
И ни в коем случаи не используйте в работе этот "утяжелитель модулей".
Когда я создавал эту тему, как раз писал третью версию модуля blockpro и мне показалось логичным использовать dle_api. Оказалось, что казалось. Сам API то не плох, но на практике его использование жестко утяжеляет мскрипт.
Простейшие тесты выявили увеличение нагрузки в 4 раза (!!!). т.е. время выполнения модуля было не 0.05 сек при полной нагрузке (писал параллельно две версии, с API и без), а  0.2 сек. И это было на начальном этапе разработки модуля.

К тому же зарегистрировать нового пользователя средствами dle_api не возможнов принципе, т.к. там ошибка, тянущаяся ещё с версии 8.5 (!).
Так что если нужно использовать какие то методы из dle_api - смело выдерайте их и используйте непосредственно в модуле, проверено неоднократно.