[Разработчикам модов]

[kaliostro_den 2]

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

IT-Security, он дело говорит

Во первых зачем это в дле, дле не работает с сервесами.

Во вторых зачем изобретать велосипед, есть прекрасная реализация работы с сервисами через SOAP в ZendFrameWork

вообще-то это была шутка) никто и не собирался прикручивать его сюда.

[Bagir 3]

вообще-то это была шутка) никто и не собирался прикручивать его сюда.

Не читал весь топик, из - за этого не понял иронии

Может Владимир согласитса на обновления движка, я бы классы переписывать начал, патом бы вынес на общий суд. Может быть они и будут включены в сборку.

[IT-Security 33]

Если Вы хотите помочь развитию DLE, то можете помогать мне с API, так как это компонент, который всегда будет в движке. Другое дело, что версии будут только те, что были на момент выхода дистрибутива.

Вообщем как хотите. Возникнет желание помочь - 683993

[celsoft 5 984]

Первое что вызвало недоумение, зачем ограничивать себя как программиста и писать код на старой версии ПХП, уже ПХП 6.0 находится в бета тестирования, а вы никак не можете на ПХП 5.* перейти.

сразу видно видно человека, который работает для себя любимого . Не програмисты не могут перейти на PHP5, а хостинг провайдеры. DLE это не персональный продукт, предназначенный для одного человека, это массовый скрипт и используется большим количеством людей. PHP5 на серверах хостингов в количественном отношении только недавно перешел отметку в 50%. Примерное соотношение сейчас это 60% PHP5 и 40% PHP4. Хостинг провайдеры до сих пор сейчас дают выбор между php4 и php5. Вы когда нибудь видели чтобы ктонибудь из хостеров ставил php3, я нет. Так вот когда будет также и с php5 будет иметь смысл для массового проекта отказываться от поддержки php4. На данный момент это невозможно, потому что php4 занимает огромную нишу. Я сам за поддержку именно нового,а не старого, заставить пользователя обновить php, очень сложно, это не браузер обновить на новую версию. 98% пользователей скрипта, понятия не имеет что это такое, потому как пользуются скриптом на уровне обычного пользователя.

[Al-x 7]

Все ныли и плакали, что так трудно писать простейшие модули под DLE - им даёшь решение, на которое гробишь своё ЛИЧНОЕ время - а они даже не могут протестировать и высказать пожелания.

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

Я подожду до версии 0.1, если активность будет такая же, то разработка API будет завершена на 0.1, так как писать его для самого себя смысла я не вижу

Делать это надо в первую очередь для себя. Получаешь от этого удовольствие - пиши. Не получаешь - не пиши Сейчас ТЫ сам ЗАДАЁШЬ вектор, по направлению которого должно идти ДВИЖЕНИЕ и РАЗВИТИЕ. Остальные могут только согласится с тобой или не согласится, пойти или не пойти. Т.е. если ты считаешь, что можешь сам разработать систему АПИ, удовлетворяющую всем требованиям и нуждам других - пожалуйста. Медленно и верно ты достигнешь результата. Тогда возможно активность и возрастёт, т.к. люди поймут что это такое и с чем его едят. Но никто не может гарантировать этого, тем более с dle.

сразу видно видно человека, который работает для себя любимого

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

Просто в зависимости от подхода - у вас и вашего оппонента будет разный размер аудитории по результатам работы.

[IT-Security 33]

Отчасти конечно верно, но у меня банально кончаются идеи

[Bagir 3]

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

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

Не программисты не могут перейти на PHP5, а хостинг провайдеры.

Какраз программисты могут заставить двигаться хостеров. Представте если ДЛЕ не будет поддерживать ПХП 4, конечно есть риск потерять часть пользователей, но также вы можете приобрести дополнительных разработчиков, т.е. сторонних модулей станет больше, тем самым привлечет новых клиентов. Пользователи в свою очередь могу выдвигать ультиматум своим хостерам, что заставит двигаться в свою очередь хостинг компании. Почему?! потому что монополии на хостинг нет, а тысячи хостинг компаний бьются за каждого клиента.

Вы когда нибудь видели чтобы ктонибудь из хостеров ставил php3, я нет. Так вот когда будет также и с php5 будет иметь смысл для массового проекта отказываться от поддержки php4.

ПХП3 пропал с горизонта после появления ПХП5, т.е. ДЛЕ перейдет на ПХП5 после выхода ПХП6 и опять будет на шаг позади планеты всей.

[celsoft 5 984]

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

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

Какраз программисты могут заставить двигаться хостеров. Представте если ДЛЕ не будет поддерживать ПХП 4, конечно есть риск потерять часть пользователей, но также вы можете приобрести дополнительных разработчиков, т.е. сторонних модулей станет больше, тем самым привлечет новых клиентов. Пользователи в свою очередь могу выдвигать ультиматум своим хостерам, что заставит двигаться в свою очередь хостинг компании. Почему?! потому что монополии на хостинг нет, а тысячи хостинг компаний бьются за каждого клиента.

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

ПХП3 пропал с горизонта после появления ПХП5, т.е. ДЛЕ перейдет на ПХП5 после выхода ПХП6 и опять будет на шаг позади планеты всей.

Кто то пишет скрипты для себя, кто то для разработчиков, я пишу для конечных пользователей. Может быть в скрипте всегда останется поддержка PHP4, этого я незнаю, все зависит от потребностей самого скрипта, на данный момент, я не вижу необходимости обязательного использования именно PHP5. Нет такой функциональной необходимости. На данный момент разница между php 5 и 4 только одна: в некоторых моментах проще писать код, вот и все. Больше преимуществ нет.

[Bagir 3]

Нет такой функциональной необходимости. На данный момент разница между php 5 и 4 только одна: в некоторых моментах проще писать код, вот и все. Больше преимуществ нет.

Я бы не сказал что разница только в "некоторых моментах писать код". Кроме добовления функцыональности, починки багов и более быстрой работы ядра, также был полностью пересмотрен подход к ООП. Что нам это дало?! Возможность написания правильных классов. Защитить свои классы от не сонкцыонированого доступа к переменным (свойствам) и закрытым функцыям (приватным методам), делать логически понятные классы на основе patterns и многое другое от чего тежело отказатьса

Также из-за своего любопытства хотел спросить у Владимара, какова ваша политика развития движка? Вы планируете вывести ДЛЕ за рамки новостной ленты? Расширенее функцыонала может вывести ДЛЕ на новый уровень. К примеру CMS Joomla, ограниченный по дефолтовым возможностям (куда меньше чем в ДЛЕ). Но для Joomla существуют сотни сторонних модулей. Почему такая заинтересованность у праграмистов? Скорей всего в правельной структуре скрипта, правельно построеной модели MVC, встроенный FrameWork. Думаю это то что надо програмисту для удобной работы.

[Bagir 3]

Извените, не удержался. Хочу представить маленькийй пример правильной реализации класса db

И так начнем, для начала откроем файл mysql.php

if ( extension_loaded('mysqli') AND version_compare("5.0.5", phpversion(), "!=") ) {

	include_once( ENGINE_DIR."/classes/mysqli.class.php" );

}

else {

	include_once( ENGINE_DIR."/classes/mysql.class.php" );

}

Как видим при каждом запуске программы вызываем 3 функцыии для проверки если у нас установленна библиотека mysqli, Опытные програмисты сразу скажут что вместо этой конструкции нужно воспользоватьса "Pattern Factory"

class db {

	public static function factory($adapter, $config) {

		if (include_once ENGINE_DIR."/classes/$adapter.class.php") {

			return new $adapter($config);

		} 

		else {

			throw new Exception ('Driver not found');

		}

	}

}


$db = db::factory($config['mysql_adapter'], $db_config);

Расмотрим наш код, сам класс описывать нет смысла и так все понятно, лучше расмотрим получения объекта на db. Первый параметр берем из массива $config, $config['mysql_adapter'] можно записыват один раз при установки скрипта, таким образом избавимся от лишних проверок. Второй параметр $db_config - это массив с параметрами подключения к БД, посже объясню почему массив, а не константы из фала параметров конфигурации подключения к БД. Далее определяем абстрактный класс описывающий функцыонал наших будующих адаптеров.

abstract class dbAbstract {

   abstract protected function connect($config);


   // дальше описание всех методов и свойств 

}

Мы создали абстрактный класс для написания новых адапторов БД или расширения имеющихся, например если захотим добавить метод каторый будет делать запрос к процедурам или мульти запросы. Далее опишем наш адаптор, для примера возьмем клаcc mysqli.class.php

class mysqli extends dbAbstract {

	//тут описываем рализацию методов и свойств, с использованием библиотеки MySQLi

}

Конечно не забываем ставить уровень доступа public, protected, private. Для чего нужно устанавливать уровень доступа к методам и свойствам? Расмотрим на примере. в ДЛЕевском классе mysqli.class.php переменная $query_num объявлена следующим образом

var $query_num = 0;

это означает что эта переменная имеет уровень доступа public и ее можно изменять из любой точки кода. К примеру новичек не сильно понимающий ПХП и Мускул может сделать в своем модуле запросов 20 и больше, но опытные пользователи быстро могут обнаружить данную небрежность, посмотря на статистику каторую доет ДЛЕ, но тот же не опытный програмист может свисти статистику запросов к нулю

for ($i = 0; $i < 20; $i++){

	$db->query(...);

}

$db->query_num = 0;

вот так это можно сделать. Как это можно предотвратить? очень просто [

protected $query_num = 0;

таким образом мы предотвращаем несанкцеонированый достум к счетчику запросов. Идем дальше. В случаее есль мы теряем соединение с БД класс ДЛЕ пытаетса востоновить соединение

if(!$this->db_id) $this->connect(DBUSER, DBPASS, DBNAME, DBHOST);

Но если я открываю соединения с 2-умя серверами БД, то в случае потери соединения, оба моих объекта будут пытатса подключитса к БД на которой стоит ДЛЕ, что приведет к ужасной логической ошибки, каторую будет тежело обноружить.

И на последок, я бы не советовал писать модули ecommerce на основе ДЛЕ. метод display_error в случае возникновения ошибки просто выведет пользователя из программы. А если мы принимаем он-лайн платеж, а патом записываем факт получения платежа в БД. То какраз в случаее возникновения ошибки записать мы не сможем не чего и не куда.

[celsoft 5 984]

Bagir,

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

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

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

И на последок, я бы не советовал писать модули ecommerce на основе ДЛЕ. метод display_error в случае возникновения ошибки просто выведет пользователя из программы. А если мы принимаем он-лайн платеж, а патом записываем факт получения платежа в БД. То какраз в случаее возникновения ошибки записать мы не сможем не чего и не куда.

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

[Bagir 3]

Первое в таком виде как сейчас, DLE умеет автоматически определять тип БД и не заставляет пользователя думать, что включить и что лучше.

в сваем примери я использовал фабричный метод, каторый берет вид библиотеки для БД из $config. В $config можно добалять елимент с именем библиотеки при установки скрипта и неделать проверки каждый раз.

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

По этому пункту я не совсем вас понял.

Третьте существующий код просто проще и понятней.

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

Четвертое DLE не восстанавливает потерянные соединения, а умеет работать вообще не используя запросов к базе данный, и не устанавливая соединения и не тратя при этом время на установку соединений. При установке соединений с двумя серверами нужно просто объявить новый класс, и конфликтов не будет.

	

		function query($query, $show_error=true)

	{

		$time_before = $this->get_real_time();


		if(!$this->db_id) $this->connect(DBUSER, DBPASS, DBNAME, DBHOST);

		 .....................

строка if(!$this->db_id) $this->connect(DBUSER, DBPASS, DBNAME, DBHOST); явно указывает на то что если $this->db_id не содержит указатель на соединение, то вызываетса соединение к БД с дефолтными параметрами скрипта. Из этого следует если я открываю новый объект $my_db = new db($params_to_other_server);

и по какимто причинам теряю указатель на соединение, то при следущей попытки сделать запрос вызоветса if(!$this->db_id) $this->connect(DBUSER, DBPASS, DBNAME, DBHOST); эта страка и в $my_db->db_id уже будет указатель на БД на катором стоит ДЛЕ.

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

Только если програмист перепишет класс ДБ, но это уже ложитса на плечи пользователей каторые устанавливают модули, надо проверять какие файлы заливаем на сервер.

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

На самом деле у нас стало только на один файл больше и это абстракция класса ДБ, да на ПХП 4 такое нельзя организовать, пользователя не кчему не пренуждаем все происходит автоматически, опять насчет фильтрации не понял. Насчет плюсов я с Вами не согласен. не то что мне так нравитса писать это правила хорошего тона в OOP (не только в ПХП)

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

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

[IT-Security 33]

Насчёт if(!$this->db_id) $this->connect(DBUSER, DBPASS, DBNAME, DBHOST); - изначально у нас в классе ставится false.

Так что это не соединение если потеряно соединение, а всего лишь соединение при ПЕРВОМ запросе.

[celsoft 5 984]

На самом деле у нас стало только на один файл больше и это абстракция класса ДБ, да на ПХП 4 такое нельзя организовать

Так я и о чем говорю, зачем это организовывать, если нет практического преимущества. Кроме как:

Насчет плюсов я с Вами не согласен. не то что мне так нравитса писать это правила хорошего тона в OOP (не только в ПХП)

Ну кто сказал, что только програмирование ООП является правилом хорошего тона, а все остальное детский сад? Правилами хорошего тона считается не чавкать за столом и не ковырятся в носу. Это правила хорошего тона и этикета. А ООП это лишь стиль програмирования, и использоваться должно исходя исключительно из практических соображений, а не переписывание кода, ради самого кода. И 100% когда нибудь DLE перейдет и на минимальные требования php5 и на php6 и т.д., но переход будет обусловлен исключительно практическими соображениями, когда это можно будет сделать только так, а не иначе. Для меня что линейный код, что ООП, одинаково в плане естетического удовольствия от написания кода, у меня нет такого "Вау это круто" от того или иного стиля, поэтому я и полагаюсь только на текущие потребности, и эти потребности позволи DLE быть совместимым и с PHP4 и с PHP5 и с PHP6.

Ладно не будем спорить и засорять тему уважаемому IT-Security, а то мы лишь только флудим далеко не по тематике топика.

[IT-Security 33]

На самом деле интересная тема и думаю есть смысл её вынести в отдельную и назвать "Holywar PHP4 VS PHP5 в DLE"

Мне лично интересно было почитать

Изменено 27 апреля 2009 пользователем IT-Security

[Bagir 3]

celsoft,

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

На счет API для ДЛЕ, идея отличная, но много не попишешь. Это не сервис к каторому требуетса доступ.

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

[Al-x 7]

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

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

[spam 11]

Вообще как я смотрю по активности народа - им это не нужно =)

Все ныли и плакали, что так трудно писать простейшие модули под DLE - им даёшь решение, на которое гробишь своё ЛИЧНОЕ время - а они даже не могут протестировать и высказать пожелания.

Нужно, но ты должен понять есть ряд причин на то что тут мало постят идей.

Первое: 70% потльзователей просто не понимают что такое API и вообще зачем нужен php , соответтвенно они восторженно читают что появилось API, но написать что-то по сути прото не могут

Второе: Те кто понимают не всегда чувтствуют в себе необходимые знания чтоб что-то советовать (банальная неуверенноть в воих силах)

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

Четвертое: Активная лень многих работающих в сети

Пятое: Пока нет говотовых модулей на API, не чего так казать "посчупать" в работе, функционал скромный, а соотеттвенно реального теста нет...

Ну и главное, ты прав API часто путают со снипетами, возможно причина в wordpress, но факт отается фактом, главное чего ждут это легкая установка модулей без необходимоcти их переустановки в случае обновления пока этого нет (при обновлении на 8 версию уже думал что проще новый движек напиать чем обновить ДЛЕ ), а остальное для основной массы вторично.

p.s.

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

Изменено 30 апреля 2009 пользователем spam

[Vitassam 0]

Holywar PHP4 VS PHP5 в DLE

Плюс Адын !

з.ы. Было бы неплохо, если бы архив с бета-версиями API выкладывался в какой-либо публикации на сайте, а не на форуме.

Изменено 2 мая 2009 пользователем Vitassam

[D_Moon 1]

Извиняюсь за нубский вопрос).

Планирую в будущем сделать возможность авторизации через OpenID и возможно даже OpenID провайдер для своих пользователей.

API может как-нибудь облегчить установку и стабильную работу на последующих версиях DLE ?

[spam 11]

Извиняюсь за нубский вопрос).

Планирую в будущем сделать возможность авторизации через OpenID и возможно даже OpenID провайдер для своих пользователей.

Думаю не будет, и я чесно говоря не вижу смысла в openid на дле.

API может как-нибудь облегчить установку и стабильную работу на последующих версиях DLE ?

Установку нет, cтабильную работу да

Изменено 4 мая 2009 пользователем spam

[Al-x 7]

cтабильную работу да

только при условии активной поддержки апи. Без поддержки можете даже не мечтать о стабильности)

[dlehack 14]

понимая что не в тему но раз здесь мы говорим об улучшениях которые необходимы DLE то вот:

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

[kaliostro_den 2]

celsoft,

Хотелось бы видеть хотябы немного событий в коде ДЛЕ. Например такие как OnRegister, OnLogin и любые другие в самых активных местах скрипта, это дало бы намного меньше изменений в файлах при установки тех или других модулей. К тому же такое очень легко реализуется и встраивается в движок.

[keysi_ 0]

Хорошую тему подняли, собственно прочитав на сайте про апи, зарегистрировался на форуме

Но вот, собственно какой вопрос.

Может я конечно буду выглядеть глупо, но мне кажется что проблема в непонимании АПИ еще и в этом. Я не имел опыта работы с АПИ, и подобные вещи обычно пишу к определенному скрипту/сайту своими руками. Но вот что не понятно: ЧЕМ ВСЕ ТАКИ ОТЛИЧАЕТСЯ КОНСТРУКЦИЯ АПИ, от конструкции стандартных КЛАССОВ которые уже присутствуют в дле?

Если непонятно спросил, то я имел виду вот это, (запрос от фонаря):

$db->query( "UPDATE " . PREFIX . "_post SET autor='$autor' WHERE autor='admin'" );

VS

$dle_api->api_query ($admin, $select, $where)

// и в случаее чего все же придется писать sql запрос

Или я может что то недопонимаю?

dlehack, во многом не согласен, но идея интересна, мне допустим нравится как контент разделяется по категориям в Joomla 1.5, хотя все же нынешний метод имеет свои преимущества.

Изменено 6 мая 2009 пользователем keysi_