Re: Monstra MySQL ?
Хм, позволяет конечно - xml-ки создавать...
ну так она сейчас и на хмл.
я смысла вашего вопроса не понимаю - любой плагин может любым способом сделать что хочет.
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Хм, позволяет конечно - xml-ки создавать...
ну так она сейчас и на хмл.
я смысла вашего вопроса не понимаю - любой плагин может любым способом сделать что хочет.
Вот смотря на все те многие плагины что для 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
вообщем не вижу смысла в ближайшем будущем бросать эту ветку.
вот и я о том же
Зачем себя ограничивать файлами, если можно не ограничевать?
Все можно сделать с использованием файлов - тут больше вопрос в удобстве и производительности помоему
@to all
Если у вас нет идеи какой плагин сделать ) посмотрите какие плагины существуют для других движком и попробуйте их адаптировать(реализовать) для Монстры.
1) http://wordpress.org/extend/plugins/ реально много плагинов для работы с изображениями и контентом для работы которых вообщем БД не нужна.
2) http://extensions.pivotx.net/ - вот еще одна cms на mysql плагины которой в большинстве не используют mysql
p.s.
Новая Монстра на MySQL - это будет совсем новая Монстра...
Новая Монстра на MySQL - это будет совсем новая Монстра...
как скажете
Я за то, чтобы поддержку XMLDB оставили в Монстре, НО при этом была возможность работать с MySQL/SQLite. На форуме уже была реализация Монстры с Мускулом через Хэлпер. И вот чем вам не нравится такое решение?
Нужен простой сайт-визитка или портфолио? Ваш выбор - XMLDB
Вам нужен простенький сайтик с новостями и планируется большая посещаемость/нагрузка? MySQL
Я за то, чтобы поддержку XMLDB оставили в Монстре, НО при этом была возможность работать с MySQL/SQLite. На форуме уже была реализация Монстры с Мускулом через Хэлпер. И вот чем вам не нравится такое решение?
Нужен простой сайт-визитка или портфолио? Ваш выбор - XMLDB
Вам нужен простенький сайтик с новостями и планируется большая посещаемость/нагрузка? MySQL
Но даже в случае небольшого сайта MySQL будет быстрее ИМХО
да, так и есть, но в случае небольшого сайта, просо со статическими страницами, это будет разница 0.0X секунд, что не страшно, но в случае более менее серьезного, со связанными таблицами (что замечу частое явление, даже на примере блога) будет беда...
Было-бы очень не плохо чтобы в 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 должно быть централизовано...
webengineer любой класс, лежащий в helpers будет подключён автоматически. любой плагин, работающий с настройками подключения, будет равнозначен аналогичному боксовскому.
свой вариант, который уже работает на боевом сайте, я недавно выложил - http://forum.monstra.org/ru/topic/62/pl … y-s-mysql/ . совместно с ним работают ещё три плагина, общающихся с мускулем.
Я тоже хелпер выкладывал, твой смотрел - и как оказалось, мой даже проще в пользовании..
Да я видел, и разраб плагина должен предупреждать, люди, при установке плагина, пожалуйста установите тот-то хелпер и тот-то мод для мускула.
Другое дело, если бы это входило в стандартную поставку, только использование было опционально
У меня где-то еще один валяется класс, только помощнее немного, там кэширование есть и запросы с автоматической конвертацией кодировки utf-8 и cp1251 (писалось спецово для отдельно проекта)
в стандартной поставке за тебя этот хелпер положит Awilum. И это будет единственное отличие.
в моём и твоём хелперах работа одинакова. просто в моём нужно использовать хук и неймспейс, чтобы не было дублирующих подключений к базе в разных плагинах, а использовалось одно ленивое. но никто не запрещает заного инициализировать класс мускуля.
я вообще не понимаю ваших рассуждений уже. вы разберитесь в структуре и организации работы этой цмс, поймите что и как подключается, а потом уже просите стандартную поставку.
на текущей цмс иначе получить поддержку мускуля нельзя.
если вы хотите иметь нативную поддержку мускуля, то Avilum придётся переписать класс по работе с Table и прочем, чтобы вы вообще не замечали с чем вы работаете физически. А такая задача равнозначна по объёму с написанием новой цмс, о чём Awilum и сказал ранее.
класс кеширования в цмс есть. я правда пока не разбирался, можно ли там раздельно на каждый элемент кеша задавать время жизни. если можно, то ничего больше не нужно.
угумс, в структуре разобрался - там XMLDB лежит как неотъемлимый компонент - что конечно ясно, так как сама цмс работает с ним. Я веду к тому, что компонент мускула, не должен быть неотъемлемым, поэтому пихать его в ядро не нужно - вот и все. Переписывать цмс не придется, и если я напишу плагин и выложу его для общего юзания, я не буду тогдя просить - пожалуйста установите хелпер, дабы у вас плагин работал... Так понятно?
включив класс по работе с мускулем в плагин, вы не сможете гарантировать, что этот класс всегда будет доступен другим плагинам.
в данном случае только класс в виде хелпера может обойти эту проблему.
я с этой неприятностью столкнулся уже. в sibase, что я выложил, я поставил приоритет 1 и создал неймспейс для вызова базы в другом плагине с приоритетом 2. однако в его функции main() я не смог подключить базу - возникло исключение "неймспейс" не существует. т.е. более приоритетный плагин ещё не загрузился.
ну и как тут это обойти без хелпера?
Я как-раз и говорю что хелпер нужен, только статический, не нужно в каждом модуле объект создавать...
И еще - просто хочу чтобы таковой был в стандартной поставки, ато Вы со своим хелпером мод напишете, а я со своим, кому-то понадобятся моды оба, и вообще черти-что получится. Он должен быть один, а значит в стандартной поставки от Awilum, вот почему я хочу что-бы именно он его туды полжил))
Я как-раз и говорю что хелпер нужен, только статический, не нужно в каждом модуле объект создавать...
для этого я хук и использую в своём. sibase создаёт объект и подключение. а остальные коннектятся к существующему объекту.
от того, что хелпер положит Awilum, необходимость в создании объектов не изменится. или вы предлагаете включить глобальные переменные, чтобы при включённом пхп можно было в базу залазить даже из шаблона?
Это же кто додумается из шаблона в базу то лезть? ппц какой-то...
А вообще db::query() - чем плохо? объект один и он статический, никакого лишнего кода собственно
в чём отличие вашего db::query() от текущего варианта с хелпером $db->query()?
1 - гарантирует что он один (и иначе быть не должно!) ,
2 - доступен в любом месте (это тоже хороше, у кого мозгов хватит в шаблоне юзать, тот сам себе буратино),
3 - простота использования (не нужно кода для создания объекта), простое обращения
хотя любой вариант приемлем, но в этом не нужен доп код для создания объекта, он статический и сам себя контроллирует и создает соединение при первом же обращении к нему. Простота вот и все.
Хотя это уже разговор больше о реализации. С моей точки зрения - так оптимальней, но наверное из-за того что так я реализовал свой хелпер... Если интерестно - вот код
Error: mdb_001');
mysql_select_db($mdb['database']) or die('Error: mdb_002
') ;
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() выполнить да и другие функции
Давно не заходил на форум и заметил, что монстра стала все стремительней развиваться. Касательно Мускула. Это идея хорошая, но вот разделять монстру на 1 и 2 версию, а следовательно, плагины надо будет писать разные. Это, как по мне, не есть хорошо. Некоторые моменты в монстре реализованы и схожи в реализации с фреймворком Yii. Так вот, а что если мы так же поступим, как там, и позволим монстре при установке выбрать с какой базой работать (в Yii это прописывается в конфиг файле) и создать хелпер (прослойку в yii это Yii DAO в связке с PDO). Для работы с текущей xml базой или при необходимости с mysql,sqlite. Дело в том, что временами удобно заархивировать всю монстру с одного сервера и перенести весь сайт на другой и заменить лишь название сайта в настройке монтры, и - вуаля - все работает. И нет смысла создавать базу для сайта в 5 страниц. И другая ситуация: монстра развивается, и, глядишь, через год на ней с поддержкой mysql можно будет создавать сайты намного больше, чем визитки. WP(WordPress) тоже как бы блоговый движок, но с течением времени никто не помешал написать расширения для реализации интернет-магазинов и многое другое.
P.S. Для тех кому лень читать выше написанное:
1. Оставить одну версию монстры
2. Реализовать поддержку разных БД, в том числе xml как сейчас. При этом чтобы сам хелпер занимался преобразованием запросов под нужную базу.
P.P.S
Т.к. это все потребует много человеко-часов и усилий, можно часть переложить на желающих помочь форумчан. И каждый бы смог привнести свой вклад не только написанием плагинов, но и кусков кода ядра.
Форум работает на PunBB, при поддержке Informer Technologies, Inc