Monstra MySQL ? (Страница 2 из 4)

Вот смотря на все те многие плагины что для WP так ли надо им мускул ?

Плагины которые можно легко реализовать для Монстры
1) Плагин новостей. для t-cms их два или более.
2) Плагины различных редакторов! а их много и каждый можно сделать для монстры.
3) Галереи.
4) Голосовалки и рейтинги.
5) Плагины с различными полезными шорткодами. Добавляющие какие то новые фичи при работе с контентом.
6) Смотрим какие плагины реализованы например для WP http://wordpress.org/extend/plugins/
  -  Images тоже например: http://wordpress.org/extend/plugins/tags/images

p.s.
DokuWiki например на файлах http://ru.wikipedia.org/wiki/DokuWiki

вообщем не вижу смысла в ближайшем будущем бросать эту ветку.

Зачем себя ограничивать файлами, если можно не ограничевать?
Все можно сделать с использованием файлов - тут больше вопрос в удобстве и производительности помоему

как скажете

Но даже в случае небольшого сайта MySQL будет быстрее ИМХО

Было-бы очень не плохо чтобы в 1.2.0 добавился хелпер для работы с базой, а так-же стандартные настроки для подключения к базе

host
user
password
database_name

подключение к базе совсем не обязательно, но если уж какой-то мод работает с базой он обращается к примеру Mdb::sQuery($query), то сам класс проверял бы подключение к базе, если нет, то устанавливал его.
При таков варианте, не тратилось бы время на подключение, если оно не нужно (а это порядка 5 сотых секунд при новом подключении, и 5 тысячных при постоянном (mysql_connect и mysql_pconnect)).

Получилось бы так, сайт работает без базы - мускул не пользуется, работает с базой - пользуется, тормозов в роботе не добавит от подключения одного только класса для работы с базой. Его кстате можно сделать простым таки. Мой http://forum.monstra.org/ru/topic/49/ka … i-khelper/ занимал всего пару киллобайт, но позволяет довольно удобно работать с базой.

P.S.
Awilum - мускул действительно нужен, и не когда-то, а именно сейчас, так как хотел плагин репозитория написать, а с xml-ками - фигня какая-то (5 связанных таблиц минимум выходит), а хотел просто реализовать методами самой cms, что-б не тыкать в плагин хелперы и доп функции. Управление CMS должно быть централизовано...

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

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

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

если вы хотите иметь нативную поддержку мускуля, то Avilum придётся переписать класс по работе с Table и прочем, чтобы вы вообще не замечали с чем вы работаете физически. А такая задача равнозначна по объёму с написанием новой цмс, о чём Awilum и сказал ранее.

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

Я как-раз и говорю что хелпер нужен, только статический, не нужно в каждом модуле объект создавать...
И еще - просто хочу чтобы таковой был в стандартной поставки, ато Вы со своим хелпером мод напишете, а я со своим, кому-то понадобятся моды оба, и вообще черти-что получится. Он должен быть один, а значит в стандартной поставки от Awilum, вот почему я хочу что-бы именно он его туды полжил))

Это же кто додумается из шаблона в базу то лезть? ппц какой-то...
А вообще db::query() - чем плохо? объект один и он статический, никакого лишнего кода  собственно

1 - гарантирует что он один (и иначе быть не должно!) ,
2 - доступен в любом месте (это тоже хороше, у кого мозгов хватит в шаблоне юзать, тот сам себе буратино),
3 - простота использования (не нужно кода для создания объекта), простое обращения

хотя любой вариант приемлем, но в этом не нужен доп код для создания объекта, он статический и сам себя контроллирует и создает соединение при первом же обращении к нему. Простота вот и все.

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

<?php defined('MONSTRA_ACCESS') or die('No direct script access.');
class Mdb{
    //Ссылка на соединение с базой
    public static $mdblink = false;
    //Состояние соединения
    public static $connect = false;
    /**
     * Protected constructor sience this a static class
     * 
     * @access protected
     */
    protected function __construct(){
        //protected initialization
    }
    /**
     * Проверяет соединение с базой данный, если такового небыло, соединяет
     * в случае ошибки останавливат работу скрипта и выводит номер ошибки
     * должен использоваться только внутри класса, но никто не запрещает пользовать извне
     */
    public static function connect(){
        if(!Mdb::$connect){ 
            require('mdbconfig/config.php'); //Тут массив с настройками - лучше было-бы чтобы были в объекте "Options"
            Mdb::$mdblink = mysql_pconnect( $mdb['host'], $mdb['user'], $mdb['password'] ) or die('<code>Error: <b>mdb_001<b/></code>');
            mysql_select_db($mdb['database']) or die('<code>Error: <b>mdb_002</b></code>') ;
            mysql_query("set names utf8");
            Mdb::$connect = true;
        }
    }
    /**
     * Функция для обработки запросов удаления или изменения в базе данных (UPDATE or DELETE)
     *
     * @param type $query
     * @return type $count (колличество затронутых строк в базе данных)
     */
    public static function uQuery($query){
    Mdb::connect();
    mysql_query($query);
    $count = mysql_affected_rows();
    return $count;
    }
    /**
     * Функция для обработки запросов вставки строки в таблицу (INSERT)
     * 
     * @param type $query
     * @return type $id (ID созданой записи)
     */
    public static function iQuery($query){
        Mdb::connect();
        mysql_query($query);
        $id = mysql_insert_id();
        return $id;
    }
    /**
     * Функция для обработки запросов выборки из таблиц базы данных (SELECT)
     *
     * @param type $query
     * @return type $result (В случае успешной выборки возвращает двумерный массив выбраных строк, в случае ошибки - возвращает false)
     */
    public static function sQuery($query){
        Mdb::connect();
        $result = false;
        $res = mysql_query($query);
        if($res) while($list = mysql_fetch_array($res)){
            $result[] = $list;
    }
    return $result;
    }
}

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