Форуми / National / Russian / Вопросы и пожелания к движку

<<<1...5...10...24252627282930>>>

Для юзеров Seditio и новичков

esclkm
#391 02.12.2010 19:26
не знал куда написал. но я вдруг ощутил шок! для mozzila есть плагин wappalyzer - который определяет cms сайта а так же все JS скрипты подштые к сайту. С жумлой, друполом и тд - данный плагин определял без проблем. А вот Seditio и Cotonti ему были не под силу. С последней версии - этот плагин уверенно распознает cotonti - мелочь а приятно
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Perceive
#392 07.12.2010 19:49
Приветствую! Есть мысли, которыми хочется поделиться.

Я долгое время присматривался к движку MODx + в этом году делал один из сайтов, используя куски кода Cotonti. И попробовал применить один из интересных принципов, о внедрении которого можно подумать.

Идея следующая: каждая страница на сайте по своей сути - код, описанный согласно спецификации HTML. У каждой страницы есть набор атрибутов: заголовок, метатеги, тело (текст). Некоторые страницы - это каталоги с дочерними страницами, некоторые - просто описания товаров и т.д. Но браузеру это не важно, для него это просто код. И эту идею можно перенести во фрэймворк. По этому пути начала идти Seditio, упростив всякие блоги до уровня обычных страниц. Но можно пойти дальше. Можно упростить списки (list.php) и в перспективе ввести новый обработчик плагинов.

Как это работает: в примитиве контент представлен в БД одной лишь таблицей страниц, например так:
Идентификатор, Заголовок, Дескрипшн, Ключевики, Текст ссылки на страницу, Заголовок h1, Текст, Это раздел?, Идентификатор родителя, Дата публикации, Шаблон, ...

Двумя полями: Это раздел? и Идентификатор родителя мы убираем необходимость в list.php и получаем простое логическое дерево сайта. Причем, можно даже не вводить признак "Это раздел?". Он используется в технических целях при построении ссылок.

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

Администрировать это дело ещё проще: плагин jquery с возможностью перетаскивания и контекстного меню и структурой сайта можно управлять на одной странице.

Несколько сложнее с плагинами и другими компонентами.
1) Хуки для плагинов никто не отменял. Они продолжают также работать. Но уже только в page.php
2) В MODx кроме плагинов существует отдельная сущность Сниппета (компонента). Они вызываются "из тела страницы". В содержимом страницы указывается, например [[Wayfinder]] и в этом месте происходит вызов компонента, который строит навигацию. В чём главное преимущества от задания в шаблоне просто {SOMETAG} - в том, что сниппету можно передать параметры [[Wayfinder ?parent=25]]. Если это можно как-то использовать в котонти...

Ещё один момент. Я уже писал за его внедрение. Напишу ещё раз: единая точка входа index.php. Я уже не знаю хостингов, которые запрещают htaccess. Этот момент позволил мне в своем сайте реализовать программное построение ЧПУ. Принцип прост: url/page/adress превращается в массив и дальше мы можем удобно работать с любым уровнем, например так:
switch($sys['urlarray'][1])
{
}

Вот как то так :)
Kort
#393 07.12.2010 22:46
Идею страниц-списков во фреймворк нести сомнительно, поскольку: это редко надо, нарушает строгость структуры, не позволяет системно работать со структурой, легко реализуется плагином, в виде штатной фичи (мне кажется) принесет больше вреда, чем пользы.
Применительно к блогам: выводите страницы раздела одним потоком. При этом сохраняется стройная и ясная система разделов и страниц, позволяющая просматривать дочерние подразделы + внешний вид классического блога + возможность навеса архивов и тегов.
SED.by - создание сайтов, разработка плагинов и тем для Котонти
Trustmaster
#394 08.12.2010 01:55
1. list.php мы в Сиене уже "упростили". Точнее сделали дерево категорий глобальным явлением, а отображение классических списков повесили на модуль page.

2. Строить всю структуру исключительно из дерева узлов общего назначения - это не ново. Так Drupal построен с его nodes, например. Если быть кратким, мы всё же не пошли по этому пути, потому что представление контента исключительно в виде дерева узлов - это большой плюс для CMS, но большой минус для CMF, поскольку позволяет админу конструировать контент как из кубиков лего (впрочем, со значительными ограничениями на выбор и соединение этих кубиков), но связывает руки разработчику, который не сможет изобразить что-либо, отличающееся от дерева узлов. Мы в общем-то не отказываемся от страниц и категорий и всех возможностей, весьма обширных, которые они дают. Но и монополию мы им не дали, вместо того развязав руки разработчикам.

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

4. С универсальным загрузчиком index.php мы уже успели побаловаться в альфе Сиены. Кроме дружного и настойчивого "ФИИ!" в ответ от владельцев сайтов и программистов ничего не получили, так что вернули обратно корневые загрузчики.

В общем, от предложенного выше курса мы уже явно отклонились и резко менять направление уже вряд ли будем.
May the Source be with you!
Sergey
#395 08.12.2010 05:11
Надо понимать, что понятие модуля list.php было зачаточным, оно и продолжает пребывать в этом состоянии. Однако, чтобы получить, по настоящему конкурентную систему необходима стройная концепция. То, что этот модуль, становится не самостоятельным, а кусочком другого, не придает стройности новой системе.
Например, у меня имеется, такой плагин regularstructure-v4_205.pdf Его объем программного кода колосален и сравним с объемом кода самой CMS. Конечно, меня устраивает и текущая версия котонти, возможно будет устраивать и новая, надо ждать. Но, концептуальные построения должны быть незыблемы, а если и меняться, то надо вначале доказать, зачем это нужно и какие возможные перспективы, вплоть до радужных это позволяет получить. Пока, я вижу некий механизм апдейта. Что он представляет в некоторых, широко известных системах мы представляем (типа черного экрана), лучше не стало.
www.cotonti.mobi
esclkm
#396 09.12.2010 04:40
все вставили свой ответ) и я вставлю)) на пост Perceive
1. категория. Я категорически простив создания единой таблицы для категорий и для страниц: причины: а. права. - то есть минимальной единице для которой придется распределять права станет страница - а не жестоко ли это? б. плагины - данный функционал в целом реализуем 500-1000 строчным плагином. в. наш опыт - в наших проектах данная необходимость возникала - поэтому и применяли. но была она как необходимость второй категоризагии а не основной. г - мультикат - сейчас возможность создать мультикат для страниц существует - а в предложеном вами варианте она является весьма сомнительной

2. INDEX - я относился к тем разработчкикам - которым нравился единый запускатор. И к тем кто очень хотель упразднения понятиий модуль. плагин - к какомуто одному.

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

P/S/ но вы все же извращенец) скрещивать модикса с котонти)))
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Sergey
#397 09.12.2010 05:46
Конечно, если подходить строго, то таблица категорий это вещь ненужная вообще. Согласно банальной теории множеств, достаточно иметь одну таблицу страниц (элемент множества), тогда имея общий групповой признак как номер элемента (страницы) мы получаем категорию. Экстра поля используем для описания там всяких компонентов множества, т.е. категории. В таблице sed_pages уже все есть, т.е код по полю page_id как личный номер элемента множеств, а поле page_cat, как обобщающий признак этого множества. Следовательно найдя элемент у которого page_id = page_cat мы с легкостью определим страницу с описанием множества (категории). Фактически, будет легко и построить кэш таких удивительных страниц, которые как раз и будут структурой. Что это даст. А это даст возможность применяя множество объединительных полей строить пересекающиеся множества и превратить движок как согласованное математически с теорией множеств. Естественно, что такой кэш можно упрятать в отдельную таблицу (прямую копию sed_pages но только с такими страницами) , которая позволит быстро, не пробегая всю грандиозную таблицу страниц получать правильное представление категорий. Кстати и проблема многоязычности, как-то сама отпадет. Самое удивительное, что при создании новой страницы ставим галочку, что эта категория и все, не надо этих бессмысленных путей, кодов категорий и прочего - не будет ошибок при построении структур категории.
Надо сказать, что я уже делал такую систему на фоксе, она работоспособна и имеет регулярное программное восприятие - не надо лишних функций городить.
www.cotonti.mobi

Відредаговано: Sergey (09.12.2010 05:59, 14 років тому)
Sergeich
#398 09.12.2010 08:46
Sergey, ну т.е. это друпал получается с его таксономией...
Если честно, то лично мне нравится идея страниц-категорий, но что-то мне кажется, такой подход будет довольно прилично нагружать базу и, как следствие, появятся тормоза. Жёсткая структура она тем и хороша, что проста и логична, как шпала :)
3axap
#399 13.12.2010 15:44
Я не по теме. А нельзя по стандарту получить небольшой плагин, в котором можно внести список ников, запрещенных к регистрации? Ну Вы поняли зачем это нужно.
Sergeich
#400 13.12.2010 16:11
по стандарту - это лишнее :)
3axap
#401 13.12.2010 16:46
# Sergeich : по стандарту - это лишнее :)
Ничуть. ДОпустим мой ник, да. Можно написать по русски, а можно на латинице через тройку. Тоже с админом. Регистр, русский, английский.. Не регистрировать же резервных пользователей самому для фильтрации?
Trustmaster
#402 13.12.2010 17:25
Сначала его надо написать, а потом подумать о стандарте. Вообще насчёт "стандарта" мы сейчас очень сильно рассчитываем запустить новый репозиторий для расширений для сиены, который позволит кроме прочего собирать свою коробку с котонти онлайн.
May the Source be with you!
jcrush
#403 13.12.2010 18:31
Кстати собирать свою коробку очень даже актуально, особенно для веб студий.
SEO блог: http://blog.stfw.ru/
esclkm
#404 13.12.2010 22:42
помоему наиболее неактуально - для веб студий))) а актуально - для жадных людей которым жалко 500 кб трафика
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Trustmaster
#405 14.12.2010 00:25
Не скажи, речь о том, чтобы в коробку могли попасть и сторонние плагины, а не только те, которые основной командой разрабатываются.
May the Source be with you!

<<<1...5...10...24252627282930>>>