Al-x
-
Публикации
1326 -
Зарегистрирован
-
Посещение
-
Дней в лидерах
1
Сообщения, опубликованные пользователем Al-x
-
-
По поводу ничто не вечно, согласен. Однако API дает хоть какую-то гарантию что модуль будет работать при обновлении движка в ближайшие несколько версий... А также с развитием самого API проще доработать интеграцию модуля под новое API нежели каждый раз перековыривать файлы движка...
Это было бы справедливо, если модуль был бы независимым и не вмешивался в работу движка. Был бы на его основе, но имел свой функционал. А тут всё иначе, поэтому будет худо.
-
То есть чтобы можно было потом обновлять движек и не бояться что модуль перестанет работать...
такой гарантии никогда не даст даже разработчик при любом апи и структуре движка. Реализовать вашу идею незвисимо можно, только если и модуль делать полностью независимым. Невозможно полностью написать независимый модуль. Дело в том, что вам в любом случае потребуются наипростешие функции и какая-то база (платформа и т.п.). Так вот эта самая база точно так же никогда не будет одинаковой, т.к. технологии меняются сверх быстро и старые подходы начинают не работать. При чём именно на базовом уровне.
И я ещё молчу, что в апи практически нет ничего, чтобы позволило существенно облегчить написание модуля (заметьте, я даже не говорю о совместимости)
-
kodges,
путаете АПИ с подключаемыми модулями.
-
Хочу ещё сделать версию под PHP5 попозже.
а что это даст?
-
IT-Security,
пожалуй так повелось, что мне пока АПИ применять необходимости нет. Однако я вижу, что ты делаешь не малую работу, поэтому решил просмотреть файл и возможно какие-то мои рекомендации тебе покажутся полезными. Всё это конечно ИМХО и все мои критически замечания - на самом деле всего лишь форма изложения.
1. change_user_name
где обработка $new_name? От АПИ будет реальная польза не только когда оно будет делать простые инсерты в БД, но и когда оно будет выполнять всё то, что делает движок. В противном случае - толковый разраб будет вынужден городить все эти проверки за пределами АПИ (придётся каждую версию отслеживать изменения в движке и менять свой код), а не толковый - будет пихать в базу всё без проверки (и АПИ для него не даст никакой пользы).
Не обязательно, чтобы модуль возвращал текст ошибок, он может возвращать только их номера или клычи массива языкового файла.
2. change_user_password - тоже самое для пароля.
3. change_user_email - тоже самое для email
4. external_auth - а где контроль бана по ип и по нику? Опять придётся всё делать за пределами АПИ. А если не делать - АПИ выдаст разрешение аутентификации для стороннего модуля, хотя реально пользователь забанен, и ведь даже не передаст никаких флагов, уведомляющих об этом сторонний модуль. Тут потребуется либо новый запрос, либо писать свой модуль проверки авторизации.
5. external_auth - тоже самое, что и для пунктов 1-3 для полей пароля и ника. Ну хотя бы
! preg_match( "/[\||\'|\<|\>|\"|\!|\?|\$|\@|\/|\\\|\&\~\*\+]/", $_POST['login_name'] )
6. external_register - тоже самое про проверки валидности входных параметров
7. send_pm_to_user - ......
8. load_from_cache. В этой функции я затрудняюсь что-либо утверждать, т.к. не владею полной информацией, но мне кажется, что делать три обращения к файлу кэша смысла нет. Зачем проверять сначала его существование, потом таймаут (а если он на 0 - сразу возвращаем ложь, или бесконечный [очень большой] - нет смысла проверять).
9. edit_config - мне кажется необходимо внести запрет на изменение некоторых ключевых параметров скрипта. Той же самой версии, отключение кэша и т.п. (надо смотреть конфиг и искать там критические параметры, которые нельзя разрешать менять сторонним модулям)...Номер версии точно, т.к. он может потом доставить проблем при апгрейде (Только не спрашивай меня - кто захочет его изменить - у нас много умельцев
).Относительно кэша.
Что больше всего заставляет парится при работе с ним в дле?))) Мало опций это ещё пол беды. Вторая половина - куча входных параметров, которые нужно много где прописать.
Мне кажется лучще бы было сделать следующим образом (взято из собственных разработок и сейчас вполне доволен).
Допустим, мне надо получить кэш. Если его нет - выйти, создать и сохранить.
Инициализируем кэш:
$c_id = $this->sc_filename('all_posts', '-1', false, md5($sql['where']. (string)$this->request['page']), true, 0);
(можно без $c_id, это опциональный элемент. У меня прописаны везде this, т.к. я его использую как extends)
Получаем $this->sc_get($c_id);
Если его нет - ставим флаг сохранения.
$this->sc_saveact(true, $c_id);
Если вдруг передумали сохранять - $this->sc_saveact(false, $c_id);
Почему ставим флаг сохранения, а не сохраняем: потому что кэш может работать и с многомерными массвами. Допустим: array('users', 'tags'), и в ходе работы надо проверить существование всех из них - если кого-то нет - сохранить весь файл. И не нужно прописывать бесконечные if (users - нету || tags - нету || и т.п.), ведь задача - облегчить работу программисту, чтобы было меньше ошибок и написание шло быстрее.
Ну и где-то в конце вызвать $this->sc_save(); независимо от того - надо сохранять или нет. Лично у меня это вообще сделано так:
function __destruct(){
$this->sc_save();
}
(только на 4 пхп не прокатит)
Преимущество такого подхода в том, что:
- параметры прописаны только один раз
- нет необходимсоти таскать данные вне пределах кэша. Иногда у меня в классе установка параметра кэша прописана в одном методе, получение в другом - сохранение в третьем. И мне не нужно таскать всюду эти данные кэша. $c_id в данном случае должен иметь доступ для его ручного назначения.
- к одному файлу кэша никогда не обратятся дважды. Название файла сохраняется в мд5 и проверяется при инициализации. Если уже есть - выдаётся только идентификатор.
Есть правда и недостаток у такого подхода. Иногда получаются конструкции типа
$this->CACHE[$c_id] .= $tpl->result['navigation'];
или
$tpl->result['navigation'] = $this->CACHE[$c_id];
Дело в том, что нельзя потом делать так unset($this->CACHE[$c_id]), т.к. потом кэш нужно сохранить.
Но если подумать - это можно обойти, разрешив сохранение данных сразу в шаблонизаторе.
-
$dle_api->_TIME
ИМХО - константами это надо делать. и ИП тоже
-
$list = explode( ",", $row['Order'] );
foreach ( $list as $daten ) {
$fav_list[] = "'" . $daten . "'";
}
$list = implode( ",", $fav_list );
$fav_list = ''; // То самое обнуление
$favorites = "(" . $list . ")";
а зачем всё это? в одну строку же пишется:
$sql = "SELECT id, title FROM " . PREFIX . "_post where id in ({$row['Order']})";
При условии, что $row['Order'] всегда заполнено.
Плюс.... не буду утверждать наверняка, но может это можно и через один запроса сделать. Нужно почитать по mysql, может там сразу можно разделить $row['Order'] и там же отправить её как параметр на объединение. ПО крайней мере на 5 наверняка можно.
-
IT-Security,
ок, извини, может я что-то недопонял) в общем буду писать модуль, на месте разберусь детально)
-
В любом случае все админские модули работают только для людей, у которых есть доступ в админку.
с новыми настройками доступа, доступ в админку имеет не только группа администраторов, а любая назначеная главным админом. Поэтому в данном случае это значимо. Т.е. у человека может быть доступ в адмнку, он может, например, редактировать новости и ещё какой-нить раздел, но не иметь возможности заходить в раздел настроек ...... ну и т.п.
-
Поэтому в проверках смысла не вижу
а разве данная настройка не может использоватся для установки доступа к скрипту разным группам пользователей? Например, установить к определённому модулю группы, которые могут производить его модерацию. А в последствии, чтобы админ из админки мог менять права доступа. При этом ведь никакая инсталяция модуля не ведётся.
-
IT-Security,
можешь ещё добавить такую вещь, чтобы в $perm всегда по умолчанию присуствовала 1, если оно не равно all?
а так же проверку, чтобы эти права мог менять только админ или хотя бы пользователь не ниже той группы, что сам есть? (т.е. главный редактор может снять или добавить группы модераторов, но свою группу и группу админов сменить не может)
Думаю, это вполне обосновано и не лишне. В крайнем случае - возможность отмены фильтра
-
Ато сейчас большой мод пока установиш, уже утро наступает
ага, я пока их писал - не успевал замечать как семестры летали))))
-
Вижу у тебя разный стиль кавычек)
да, теряю случайно) Хотя существенной роли это не играет)
а что делает код - непонятно без комментовавтоматическое построение запросов. Можно указать таблицу и поля (и ещё всякие доппараметры) и на выходе получить запрос. Я описание не делал, потому что тут всё достаточно просто.
мне привычнее видеть запрос целиком и не в одну строчку)По сути дела да, это привычнее, но иногда возникает необходимость создавать запросы с разными входными параметрами. И чтобы по 20 раз не кавырять строку исходного запроса - проще нужным переменным названачить нужные значения. В общем кому как удобнее.
Мой первый приведённый код - пример того, где проще строить запросы через автоматическое построение, нежели катать ручками.
$this->db->clear_query(); //сброс значений входного массива параметров$this->db->sql['type'] = 'si'; // типа запроса
$this->db->sql['from'] = PREFIX . '_notifications'; //таблица
$this->db->sql['fields'] = "user_id, date, text, status, type, randomcode"; // поля, которые вставляем
$data = $this->db->safesql(serialize($data)); // не важно....
foreach($this->pm_user_data as $user_id => $user){
$user[0] = ($user[0] == '1') ? '0' : '1'; // не важно....
$this->db->sql['sfields'][] = "{$user_id}, '{$this->date}', '{$txt}', {$user[0]}, {$savedtype}, '{$this->hash}'"; //значения полей, добавляются в цикле
}
$this->db->query();// выполнение запроса
Вообще конечно кому как удобнее, просто мне приходится не редко создавать запросы с разными входными параметрами и уже порядком надоело думать какую бы запятую не пропустить и т.п.) Хотя это ИМХО.
-
aDolph,
правда, а каким ещё способом то для простых запросов?
Александр Медведев,
в принципе какой-то query builder нужен, но только в редких случаях, например что-то вроде
$this->db->clear_query(); $this->db->sql['type'] = 'si'; $this->db->sql['from'] = PREFIX . '_notifications'; $this->db->sql['fields'] = "user_id, date, text, status, type, randomcode"; $data = $this->db->safesql(serialize($data)); foreach($this->pm_user_data as $user_id => $user){ $user[0] = ($user[0] == '1') ? '0' : '1'; $this->db->sql['sfields'][] = "{$user_id}, '{$this->date}', '{$txt}', {$user[0]}, {$savedtype}, '{$this->hash}'"; } $this->db->query();У меня сделана такая штука:function build(){ switch ($this->sql['type']){ case 's': if (is_array($this->sql['fields'])) $fields = implode(',',$this->sql['fields']); else $fields = $this->sql['fields']; $query = 'SELECT ' . $fields . ' FROM '.implode(',',$this->sql['from']); if (count($this->sql['where'])) $query .= ' WHERE '.implode(' AND ', $this->sql['where']); if (($c = count($this->sql['order'])) > 0){ $query .= ' ORDER BY '; if (is_array($this->sql['order'])){ for ($i = 0; $i < $c; $i++){ $query .= $this->sql['order'][$i].' '.$this->sql['by'][$i].', '; } $query = substr($query, 0, -2); } else $query .= $this->sql['order'].' '.$this->sql['by']; } if ($this->sql['limit'] > 0) $query .= ' LIMIT '.$this->sql['start'].','.$this->sql['limit']; break; case 'i' : $sql_val = array_keys($this->sql['fields']); $query = 'INSERT INTO ' . $this->sql['from'] . ' ('.implode(', ', $sql_val).') values (\''.implode('\', \'', $this->sql['fields']).'\')'; break; case 'si' : $query = 'INSERT INTO ' . $this->sql['from'] . ' ('.$this->sql['fields'].') values ('.implode('),(', $this->sql['sfields']).')'; break; case 'u' : $sql_val = array(); foreach($this->sql['fields'] as $name => $data){ $sql_val[] = $name."='{$data}'"; } $query = 'UPDATE ' . $this->sql['from'] . ' SET '.implode(', ', $sql_val); if (is_array($this->sql['where']) && count($this->sql['where'])){ $sql_val = array(); foreach($this->sql['where'] as $name => $data){ $sql_val[] = $name . ((count($data) > 1) ? ' IN (\''.implode ('\',\'',$data).'\')' : '= \''.$data[0].'\''); } $query .= ' WHERE ' . implode(' AND ', $sql_val); } break; case 'd' : $query = 'DELETE FROM ' . $this->sql['from']; if (is_array($this->sql['where']) && count($this->sql['where'])){ $sql_val = array(); foreach($this->sql['where'] as $name => $data){ $sql_val[] = $name . ((count($data) > 1) ? ' IN (\''.implode ('\',\'',$data).'\')' : '= \''.$data[0].'\''); } $query .= ' WHERE ' . implode(' AND ', $sql_val); } break; } return $query; } function clear_query() { $this->sql = array("type"=>'s', "fields"=>array(), "sfields"=>array(), "from"=>array(), "where"=>array(), "order"=>array(), "by"=>array(), "limit"=>0, "start"=>0); } ............... if ($query == "") $query = $this->build(); ...............Если нужно кому - можно искользовать.
-
IT-Security,
попробуй включить в апи метод сопоставления старого массива авторизации админки с мембер_ид. Не могу на 100% утверждать, что кому-то пригодится, но всё возможно, пару месяцев назад было актуально для быстрой адаптации модов...
-
Можно конечно устроить общую базу для всех модулей, но если я правильно понял, то при взламывании одного из модулей можно будет попасть и на другие?
учитывая, что каждый второй выкладываемый модуль под дле имеет уязвимости, то нет, вы не правы)))
форум, фотогаллерея, чаттакие модули врядли будут писать новички. А вот мелкие фичи, что в большом количестве прикручиваются к самому сайту - возможно)
-
cтабильную работу да
только при условии активной поддержки апи. Без поддержки можете даже не мечтать о стабильности)
-
В свое время пытался писать класс комментариев, что бы был похож на комментарии в ДЛЕ и имел тотже функцыонал, но после нескольких обновлений ДЛЕ бросил это дело.
аналогично - комментарии, защита от флуда, постраничная навигация, модуль загрузи файлов, работа с категориями. Выходит обновление ДЛЕ и хоть вешайся...
-
Все ныли и плакали, что так трудно писать простейшие модули под DLE - им даёшь решение, на которое гробишь своё ЛИЧНОЕ время - а они даже не могут протестировать и высказать пожелания.
я об эту стену бился полтора года. И наверное и дальше бы бился, если б не было обстоятельств, заставляющих иначе смотреть на некоторые вещи.
Я подожду до версии 0.1, если активность будет такая же, то разработка API будет завершена на 0.1, так как писать его для самого себя смысла я не вижуДелать это надо в первую очередь для себя. Получаешь от этого удовольствие - пиши. Не получаешь - не пиши
Сейчас ТЫ сам ЗАДАЁШЬ вектор, по направлению которого должно идти ДВИЖЕНИЕ и РАЗВИТИЕ. Остальные могут только согласится с тобой или не согласится, пойти или не пойти. Т.е. если ты считаешь, что можешь сам разработать систему АПИ, удовлетворяющую всем требованиям и нуждам других - пожалуйста. Медленно и верно ты достигнешь результата. Тогда возможно активность и возрастёт, т.к. люди поймут что это такое и с чем его едят. Но никто не может гарантировать этого, тем более с dle.сразу видно видно человека, который работает для себя любимогоНу по большому счёту, вы тоже работаете для себя в первую очередь. Получаете от этого творческое удовлетворение и деньги.
Просто в зависимости от подхода - у вас и вашего оппонента будет разный размер аудитории по результатам работы.
-
celsoft,
либо не хватает моих знаний ява-скрипт, либо я что-то ещё не понял. Но
причине неизвестности имен полей и их количестваПочему нельзя взять все инпуты и textarea формы, которая выводится при редактировании. Использовать для этого ява-скрипт. По крайней мере я такое делал и всё прекрасно работает. Правда я не профи в ява-скриптах, может там какие-то проблемы совместимости с броузерами...
Или имеются ввиду проблему с неизвестностью того, какое поле нужно редактировать, так? А если все доп поля выводить при бр.Или добавить в доп поля опцию, которая определяет можно ли выводить поле для редактирования при бр.
-
celsoft,
ясно) Значит я его более расширенно принимал.
Тогда я честно говоря тоже не знаю что добавить. Работа с движком крутиться не только вокруг информации о пользователе, и новостях.
Даже на примере данного:
$dle_api->take_news ($cat=X, $limit=N);Получение N новостей в массив из категории X. При выборке не накладываются групповые ограничения!
И опять же где гибкость... А если нужно из разных категорий - запрос на каждую....
В общем что-то я тут не догоняю
-
IT-Security,
самое первое, наверное, всё-таки вывод комментариев, при чём как пользовательская часть, так и админка. В принципе более менее приближенный вариант есть, могу скинуть. Функции рейтинга. Функции навигации (как для пользователей, так и для админки.) Это я тоже могу скинуть - есть вариант, который позволяет испольовать навигацию во всех вариантах.
Я буду переносить API с одной версии на другую и высылать Stable релизы Владимиру.Класс загрузи файлов. Хотя данная вещь весьма специфическая. Я за год написания разных галерей и всевозможных загрузчиков только месяца два назад наконец закончил базовый abstract класс, который стал удовлетворять всем разнообразным требованиям. Вообще в такого типа модулях есть важный момент - оставить разработчику возможность доработки.
Попробовать включить в систему модуль универсальной установки, с бэкапами, проверки целостности залитых файлов.
Набор функций для работы с дизайном админ-панели. Потому что пока там натыкаешь эти тд и тр, где что открывается и закрывается....
Расширить кэширование, с возможностью создания подпапок кэша, плюс нормальные функции его очистки.
Подумал, что если в таблицу dle_comments добавить mod_id и чуть-чуть поправить в dle выборку комментариев, то можно получить унифицированность в комментариях.интересно, как оно на нагрузке скажется. Я пока на своём сайте делил их по разным таблицам, однако при глобальной выборке придётся юнион ол использовать.
-
сделать разным ник и логин главного админа.
к примеру надо чтобы при логине в админку "admin", отображался ник "Igor" (или любой другой ник).
зачем: чтобы не палить логин в админку.
можно использовать группу пользователей.
Или редактируй скин админки, убери просто ник.
-
Не скажу точно. Там снизу есть примеры
[Разработчикам модов]
в Готовые Моды, Хаки, Локализаторы, Советы
Опубликовано:
нет, я думаю можно. По крайней мере в 83. Там появилась возможность передавать в качестве параметров текст новости прямо из шаблона. Всё остальное можно так же реализовывать. Правда для данного модуля я считаю этот медот вырезанием гланд через попу, ну да ладно - моё мнение. Единственное в чём вас, kodges скорее всего надурили - в том, что к этому какое-то отношение имеет АПИ
Чисто формально его можно вызвать и через него попасть в среду скрипта, однако это лишь вход в движок и АПи никак не контрлирует сам движок. Более чем уверен, что модуль использует и прямые функции движка.
Покажите мне, где я написал, что не реализуемо?))) Только надёжности не так много, как на это возлагается
Да и Апи слабо катит.
Кстати, для развития дела можете описать, что именно было бы не плохо иметь в АПИ.