cotonti.com : Пояснения по проекту https://www.cotonti.com Neueste Themenbeiträge Cotonti en Sat, 14 Feb 2026 07:04:08 -0000 Trustmaster So, 15 Mär 2009 02:09:23 -0000 esclkm Следуюжая версия вроде как ожидалась летом...
Изменения смотрите RoadMAP.]]> Sa, 14 Mär 2009 15:56:59 -0000 ARt_KG Sa, 14 Mär 2009 15:50:29 -0000 Trustmaster В этой теме пожалуйста.

И, да, поддержка быстрой интеграции сторонних парсеров будет, не говоря уже о редакторах, которая по сути всегда была.]]> Fr, 22 Aug 2008 06:23:58 -0000 Boss Ratibor, обсуждаем уже мелочи. Не вижу смысла продолжать про xBB. Давайте так, если кто-то еще считает что интеграция xBB нужна, то пусть выскажется, иначе ну его нафиг.

Считаю, что хранить инфу в базе в HTML не самая лучшая идея. В общем-то это мунтая довольно штука, особенно если учесть, что руками его писать никто не захочет. Задача будет возложена на редактор, а он там такого понапишет. Никогда не доверял визуальным HTML-редакторам! Вариант bb-кодов на мой взгляд оптимален. При наличии необходимых bb-тегов можно делать все что угодно, в том числе таблицы.

Может составим список необходимых по умолчанию bb-тегов?]]> Fr, 22 Aug 2008 03:02:04 -0000 Ratibor #594 Boss : Честно смотрел его, думал даже использовать. Но для меня там действительно много лишнего, поэтому проще оказалось доработать стандартный парсер SE.
Да ты крут :)
Не знал, что проще писать на PHP, чем просто удалить файлы :)
Поделись измененным парсером где нормально работает тэг code и quote.
#594 Boss : Вообще, если взглянуть более широко, то зачем тебе нужен именно xBB? Поскольку bb-код не привязывается к редактору, то стало быть редактор можно использовать любой.
А я и не говорил что мне нужен редактор xBB.
Лично меня устраивает связка: парсер xBB 0.29 и редактор HotEditor 4.2
А почему мне нужен именно парсер xBB, так я уже говорил, он отлично и самое главное правильно обрабатывает все тэги.
И как правильно сказал Trustmaster
Что мне действительно понравилось, так это то, что он умеет находить ошибки и из неправильного дерева делать правильное.
А на автоматах он работает или нет, мне если честно побарабану, главное что правильно работает.
#594 Boss : Да и вообще если честно то я бы часть стандартных кодов из SE выкинул. Типа f, page, user, pfs, post, pm. Не понимаю, кто ими только пользуется. Это слишком специфично и обычным юзерам этим голову забивать абсолютно не нужно.
Вот здесь я с тобой полностью согласен, все специфичные для Seditio коды - фтопку. Блондинкам все равно не объяснишь для чего они. За 4 года у меня на сайте никто их так и не использовал ни разу.]]> Do, 21 Aug 2008 17:45:37 -0000 Trustmaster
Допустим, даже если мы получим это разрешение, я не понимаю всех этих восторгов по поводу xBB. Очень много шума по поводу конечных автоматов и парсинга в один проход. Надо сказать, что все применение этой теории ограничивается в нем заданием логики для по сути классического лексического разбора, и за громким названием скрываются классические алгоритмы разбора строк. Далее в результате полного прохода текста и разбора мы получаем его представление в виде семантического дерева. После этого по дереву идет полный рекурсивный проход согласно установленным правилам синтаксиса (в качестве которых выступают встроенные или сторонние классы). Отмечу основные моменты:
* парсинг на чистом PHP;
* классы, классы и еще раз классы;
* скорость обработки зависит не от числа известных парсеру тэгов, а от сложности структуры текста.

Что мне действительно понравилось, так это то, что он умеет находить ошибки и из неправильного дерева делать правильное. Но вот только никакой баснословной сверхпроизводительности там нет. Все-таки не стоит сбрасывать со счетов старый добрый PCRE, написанный на чистом Си.

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

С чистым ХТМЛ есть целый набор технических проблем, в частности как обеспечить нормальное редактирование, и при этом защитить систему от злоумышленников.

А тому, кто еще раз процитирует золотые слова великого и ужасного Antony я скажу: выход там. Трепаться и права качать все умеют, а вот реальную работу делают единицы. И они почему-то знают что они делают и зачем, не боясь попасть под призрачный гнет капиталистических эксплуататоров светлого социалистического труда. И устраивать разборки "кто прав, кто виноват" - это детский сад. Есть проблемы и задачи - их надо рассматривать, а затем решать. Остальное от лукавого.]]> Do, 21 Aug 2008 13:44:34 -0000 Sergeich Do, 21 Aug 2008 12:23:53 -0000 Boss #593 Ratibor : Boss прежде чем говорить про xBB поюзай его. Там все модифицируется/убавляется/добавляется на ура.
Честно смотрел его, думал даже использовать. Но для меня там действительно много лишнего, поэтому проще оказалось доработать стандартный парсер SE.

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

ps: только вот давайте действительно в движок по умолчанию включать лишь минимум bb-кодов. А то всякие там h1, h2, ... , hide полюбому не всем нужны. Да и вообще если честно то я бы часть стандартных кодов из SE выкинул. Типа f, page, user, pfs, post, pm. Не понимаю, кто ими только пользуется. Это слишком специфично и обычным юзерам этим голову забивать абсолютно не нужно.]]> Do, 21 Aug 2008 11:26:24 -0000 Ratibor #592 Boss : Много лишнего и код тяжеловатый. Зачем усложнять движок? Кому надо пусть сами его потом подключают, ведь хотели же обеспечить возможность подключения внешнего парсера.
100 кил это тяжолый ? А то что дистрибутив весит 600 кил, так в нем помимо парсера еще находится и редактор.
А также geshi, который все равно придется прикручивать.
А как я подключу сейчас xBB ? Вернее если я его подключу, то нахрена мне "SQL scheme and several API functions for the new bbcode parser implementation" в ядре ?

P.S. Я не против родного парсера, но если только он будет хотябы не уступать xBB.
А в ближайшее время это не придвидится. Зачем изобретать велосипед с квадратными колесами, когда есть нормальный ? Boss прежде чем говорить про xBB поюзай его. Там все модифицируется/убавляется/добавляется на ура.
И все зделано по человечески, на сегодня это лучший парсер. Дак за каким лепить убожество, причем тратя на это время, когда можно включить "из коробки" полноценный 100% рабочий парсер ?]]> Do, 21 Aug 2008 11:00:04 -0000 Boss Do, 21 Aug 2008 10:54:22 -0000 Ratibor #590 Boss : Помоему в xBB много лишнего.
И что там лишнее ?
А в родном или модифицированном парсинге, как небыло рабочего тэга code, так и нет,
да и некоторые другие тэги работают через )(]]> Do, 21 Aug 2008 10:47:48 -0000 Boss Do, 21 Aug 2008 10:34:15 -0000 Ratibor Если Cotonti будет под BSD лицензией, то тогда это не противоречит лицензии xBB.
А уж если ктото потом решит на базе Cotonti зделать супер-пупер аукцон и продавать его,
то это как говорится его проблемма.
А если этот ктото сейчас один из авторов проекта, то приходим опять к этому:
Antony:
Получается что сообществу, за кучей красивых слов из первого и следующих сообщений, предлагается решать чьи-то "локальные бизнес задачи", при этом абсолютно не ясна мотивация разработчиков, которые должны будут воплощать всякие новые "бизнес-идеи" и "бизнес-потребности"

ИМХО делать парсинг, то отдельным плагином.
Сделать два варианта, на xBB и как ты хочешь.
И если кто-то решит делать супер-пупер аукционы, то нехай юзает родной(модифицированный) парсинг,
а кому нужен будет нормальный парсинг, поставят xBB.]]> Do, 21 Aug 2008 09:38:41 -0000 Antar http://trac.cotonti.com/ticket/26 , но только там ее будет тяжело искать...
Trustmaster, добавь плиз ссылку на тракер в верхнее меню сайта.

По поводу плагинов, по-моему все нормально, просто надо разбить плагины на проверенные и не проверенные.
Вот моя кучка, которую надо еще разгребать, сравнивать с тем что уже есть, и так далее: 22-plugins.rar]]> Do, 21 Aug 2008 06:47:12 -0000 Trustmaster Ratibor:
Я не всмысле того что не надо добавлять плагины, к тому же сейчас там накиданы плагины которые и так у всех есть.
Лучше пусть каждый добавит по одному плагину, но полностью рабочими.
На крайняк создать ветку в которой обсуждать и координировать все это. Я всеми руками за :yes Только вот что-то никто ничего не добавляет...

Ratibor:
Понятно для чего добавлен jQuery, но опять же но..... а гидэ тогда как минимум аякс ?
Как минимум здесь. Скажу по секрету, oc переделал с его помощью стандартные голосовалки на безрефрешевые, но потом что-то затруднился сделать эту фишку более-менее стандартной.

Ratibor:
ИМХО продуктивней для всех, будет изложение мыслей вести на родных языках.
А гуру уж потом суммируют все. Удобней и продуктивней получится.
Пока так и выходит :)

6. По поводу xBB. Лицензия GPL предполагает, что любой проект, в котором этот код включается, должен распространяться под GPL и никакой другой лицензией (даже свободной), а значит со всеми потрохами и без отчислений. Мы не планируем делать Cotonti платным или закрытым, мы хотим выпустить его по гораздо более лояльной лицензии BSD, которая, в отличие от GPL, разрешает спокойно использовать код в коммерческих проектах, если при этом сохраняются оригинальные копирайты. Ну например, если кто-то сделает на базе Cotonti крупный аукцион недвижимости, использующий какие-то секретные алгоритмы, да и вообще написанный "за бешеные бабки" специально для себя. Формально, если при этом использовалась лицензия GPL, то он обязан распространять свое это чудо безвозмездно, да еще и с исходниками. Т.е. BSD оставляет некоторое пространоство для рынка коммерческих модификаций. Ну и делает жизнь немного проще, поскольку не надо париться над тем, как лицензирована 673-я строчка в файле pupkin.php.

Sergeich:
Я так понял этот проект хочет соханить ту же лицензию что сейчас имеет Сед, единственное отличие - решать всё будет не 1 человек "группа активистов" . Всё это предлагалось и подробно разжёвывалось на неокром.нет, но Оливер проигнорировал предложение.
Старый код в любом случае идет под старой лицензий, с этим ничего не поделаешь. Новый код под BSD. Но пока старый будет играть роль лимитирующего фактора.

Sergeich:
Кстати, по поводу аттача файлов и PFS. Я уже предлагал в своё время каким то образом их скрестить. Чтобы юзер мог рулить всеми своими файлами из одного места. Простейший вариант создавать в PFS некую "папку" в которую и кидать все приаттаченые файлы.
Я помню. Но пока не было никакой возможности это реализовать (в плане времени).]]> Do, 21 Aug 2008 04:51:02 -0000 Sergeich Mi, 20 Aug 2008 22:54:01 -0000 Sergeich Mi, 20 Aug 2008 22:51:06 -0000 Ratibor Я не всмысле того что не надо добавлять плагины, к тому же сейчас там накиданы плагины которые и так у всех есть.
Лучше пусть каждый добавит по одному плагину, но полностью рабочими.
На крайняк создать ветку в которой обсуждать и координировать все это.
2. Понятно для чего добавлен jQuery, но опять же но..... а гидэ тогда как минимум аякс ?
3. :)
Судя по последней ветке, которую ты перевел и перекинул, международное сообщество мало интересуется, оно занято более глобальными проблеммами, там общаются одни русские на английском, попахивает маразмом :)
4. По поводу международной кооперации я конечно согласен, но это в идеале.
А в реальности если по английски все могут прочитать и понять о чем речь,
то вот с писаниной намного сложней. Небольшие предложения также все могут написать.
А вот ясно выразить мысль, тем более на пол километра, вот здесь сложнее, таких еденицы :)
ИМХО продуктивней для всех, будет изложение мыслей вести на родных языках.
А гуру уж потом суммируют все. Удобней и продуктивней получится.

6. А что не так с лицензией xBB ?
Скрипт распространяется бесплатно по лицензии GNU GPL v 2. Согласно этой лицензии вы можете свободно использовать, распространять и менять этот скрипт при условии, что ваши собственные программные продукты, использующие этот скрипт, не будут распространяться, либо будут распространяться по той-же лицензии GNU GPL.
В данный момент Seditio-n-0.0.1 не распространяется, что соответствует лицензии.
Или в будующем (после открытия кода на всеобщее обозрение) данный проект станет платным ?
То тогда получается, как правильно сказал Antony:
Получается что сообществу, за кучей красивых слов из первого и следующих сообщений, предлагается решать чьи-то "локальные бизнес задачи", при этом абсолютно не ясна мотивация разработчиков, которые должны будут воплощать всякие новые "бизнес-идеи" и "бизнес-потребности"
Сейчас проект не распространяется, а если после открытия он будет бесплатным, то я не вижу никакого нарушения лицензии xBB.
В общем если перевести на более понятный язык лицензию xBB, то получается.
Если хотите использовать xBB (оригинальный или измененный) в своих продуктах, то продукты должны быть бесплатными. А если вы решите рубить бабки в открытую, то плиз делитесь. А иначе боже упаси если они (ваши продукты) попадутся мне на глаза.

Тот же XTemplate сейчас юзается и ничего.
XTemplate is dual licensed using BSD and LGPL

LGPL в отличие от лицензии GNU GPL разрешает статическое связывание LGPL-программы с коммерческой.

Так что нарушение лицензии xBB будет в единственном случае - если продукт будет распространятся платно.

И раз ты говоришь что лицензия не подходит, то вывод напрашивается один. Или может я чегото не допонял ?]]> Mi, 20 Aug 2008 21:10:48 -0000 Trustmaster
2. jQuery включен в основную ветку как фреймворк, а не как некая новая примочка, которая все делает сразу глянцевым и нарядным. Это таки и нужно затем, чтобы кодеры могли спокойно писать плагины, спокойно используя эту библиотеку, не заботясь о зависимостях и конфликтах.

3. Стандартные скины - на общее обсуждение в международный форум.

4. Antar работает над новой версией локализации, когда закончит, тогда она (в utf8) и будет включена в основную ветвь. Что касается этого сайта, то очень хочется скооперировать сообщество из разных стран, вместо того чтобы все расползались по своим углам, а раз так, то надписи на английском не должны вызывать проблем. Полоска внизу преследует ту же цель, с которой Xiode ее туда добавил изначально.

5. Да собственно, все предложения пока за переход на UTF-8, работа над этим ведется. Следующий шаг - рефакторинг на mbstring и новая локализация в utf8.

6. По поводу bbcode советую повнимательнее прочитать ветку в Core Labs. Xbb, к сожалению, мы интегрировать не будем хотя бы из-за его лицензии. Никакие новые ббкоды никуда не добавляются. Добавляется универсальный API, который позволит не только управлять ббкодами в админке, но и в пользовательских плагинах. Привязки ббкодов к конкретному редактору больше не будет, и в комплекте с разными редакторами можно будет устанавливать специфические ббкоды. В качестве нового дефолтного редактора попробуем прикрутить markItUp! с подробными инструкциями, как создавать другие плагины-редакторы. Технически новый парсер реализован на все тех же строках и регулярных выражениях (я бы, может, и рад воспользоваться каким-нибудь бинарным модулем из PECL или написать парсер на Си, да вот только тогда всем надо будет как минимум на VPS переезжать). Можно, конечно, "подсмотреть" идею конечных автоматов у xBB или еще что изобресть, но пока это не самоцель. Про производительность MySQL беспокоиться не стоит, ибо кэширование для этого есть. Кроме того, реализуется новая опция "рендеринга по требованию" для страниц и форумов, т.е. парсинг происходит после того, как были произведены изменения в тексте, а не при каждом отображении. От идеи модульных парсеров в пользу одного универсального пришлось как раз отказаться из-за потерь в производительности, которые возникают вследствие этой самой модульности.

7. В attach я старался закрыть все известные дыры, связанные с закачкой файлов в php, кроме тех, которые в принципе не закрываются (дыры IE в частности). Я, конечно, постарался предоставить API для того, чтобы вложения можно было реализовать в любом плагине или модуле ядра, но PFS - это все-таки немного другое. Иногда нужно именно "личное файловое пространство", а не возможность прикреплять файлы к сообщениям. Так что просто взять и выкинуть PFS на свалку истории - опрометчивый поступок. Доработать - более взвешенный. Все это вопрос чьих-то человеко-часов.

8. Про разделение кода и html полностью согласен, да и все согласны.]]> Mi, 20 Aug 2008 20:39:51 -0000 Ratibor По какому принципу накидали плагинов ?
Лишь бы были ?
Некоторые дублируют друг друга, некоторые впринципе нерабочие,
некоторые не доделанные и т.п.
Чтоб не быть голословным, плагин ajax_poll впринципе не рабочий,
после голосования тебя выкидывает с сайта.
Так же что там делают news, textboxer2, recentitems ?
Они же есть в основной ветке.
Если они чем то отличаются от тех что в основной ветке, то почему бы тогда не выбрать лучшие и не включить в основную ветку ?

Так же на данном этапе не вижу смысла в добавлении jQuery,
в данный момент получается как в поговорке: мы посовещались и я решил.
jQuery в голом виде абсолютно не нужна, нужны плагины и нужен аякс.
На данный момент плагинов с поддержкой других JS FW и Ajax больше.
C jQuery я знаю только один плагин - это FAQ от Tefra, да и тот глючный.
Так же есть thumbnailviewer для jQuery, но он убогий, тот же lytebox намного лучше.
Либо надо все это включть в комплексе, либо вообще не включать.
А то на данный момент ситуация как с плагинами - лишь бы было, авось кто-то доработает напильником.

Также я думаю уместно будет выкинуть два скина из основной ветки, есть же отдельная ветка для скинов.
И если кто будет добавлять плагины, чтоб обязательно их подгоняли под дефолтный скин.
А кто выкладывает скины, подгоняли их под плагины.
Причем все это должно обновлятся постоянно, а не так что залил скин, а потом забил на него.
Ну и если кто решится выкладывать скин, то пусть выкладывают полноценный скин.
Вот что меня больше всего бесит в скинописателях, так это то что сделают главную страничку и выкладывают, типа пользуйся рванина, а на все остальное наплевать. В последнее время на neocrome.net, да и других сайтах по Seditio, такого мусора накидали кучу.
В общем все должно работать как говорится из коробки, а не так как сейчас - доработай напильником.

Ну и для кучи по поводу сайта:
ИМХО было бы уместно добавить русский (ну и другие по желанию) язык :)
Есть же нормальный перевод от Antar, правда он в win1251, но я в траке выкладываел переделанный в utf-8, правда это предыдущий его перевод, но если Antar не против, то я могу переделать его последний перевод в utf-8 и выложить.
Хотя лучше чтоб это сделал он сам.
И какую цель преследует внизу полоска "Home / About Us / Documentation / Legal / FAQs / Contact" ?
Она все равно никуда не ведет.
Как говорится если на сцене висит ружье, то оно обязательно должно выстрелить.
А если оно не будет стрелять, то нехрен его туда вешать.

P.S. Ну и думаю по русскому языку (да и другим non latin) нужно договорится, в какой кодировке делать.
А то все делают по старинке в win 1251. ИМХО давно надо перейти на utf-8.
С переходом на utf-8 решится много проблемм.
К примеру таже ява работает только с utf-8.

P.P.S Ну и совсем не понятно за каким в Revision 31 было добавлено "added SQL scheme and several API functions for the new bbcode parser implementation" ?
ТО идут разговоры чтоб вообще выкосить bbcode из ядра, что было бы уместней, то в ядро интегрируется еще больше этих самых bbcode. Если что и интегрировать, то это xbb, на сегодня он ИМХО превосходит все поделки для Seditio.
Понятно что хотелось бы своего, но вот когда будет это свое как минимум не уступающим xbb, вот тогда и можно его включать.
А вообще для начала надо определится со всеми необходимыми bbcode, а потом чтото воротить. Тот же hide, попросту необходим, но его нет в основных, а только отдельным плагином, а это в некоторых случаях доставляет сильные неудобства.
В крайнем случае сделать API чтоб можно было подключать разные парсеры и редакторы, а не толкать bbcode в MySQL базу, на сайтах-визитках может быть это то что доктор прописал, но на загруженных сайтах это зло, причем самое злейшее.
Ну уж если совсем-совсем приспичило создавать "several API functions for the new bbcode parser implementation", то хотябы хранить их (bbcode) не в базе а в отдельном файле.

P.P.P.S И вопрос к Trustmaster:
по поводу твоего плагина attach.
На сколько он с точки зрения безопасности, хотябы по сравнению с тем же pfs ?
И если он нормальный, то может стоит выкосить этот pfs и заменить его твоим плагином, а лучше интегрировать его ?

Ну и на последок мое ИМХО по поводу плагинов как таковых.
lang файлы конечно хорошо, но .. пусть попробует новичек разобраться хотябы в том же recentitems.
Плагины, как и ядро, не должны содержать html код.
Если плагин предусматривает вывод html кода, то его уместней выносить в tpl файл.
На крайняк, должно быть так, чтоб пользователь мог легко изменить html код внутри плагина.
Некоторые плагины, так и сделаны, но таковых еденицы, в основном html тупо встроен в php, и попробуй там разберись если тебе приспичит изменить html код выводимый этим плагином. А таких операторов как table, tr, td вообще впринципе не должно быть внутри ядра или плагина, только в tpl. Ну и как я уже написал выше, не нужно сувать что не попадя в SQL базу, только при острой необходимости.
Ну и господа админы, давайте в первую очередь думать о пользователях, а потом уж об удобстве администрирования.
Разговаривал со многими админами и большинство из них говорит "а мне так нравится" и им наплевать удобно это пользователям или нет. К примеру как в прошлом релизе Seditio все ждали подфорумы, а Оливер вместо подфорумов забабахал корзину. Алес.]]> Mi, 20 Aug 2008 17:56:29 -0000 Dayver Sa, 16 Aug 2008 20:31:19 -0000 Amro Идея про популяризацию модулеписательства вместо исключительно плагинописательства мне оч понравилась. Но то что до сих пор написание какого либо модуля это ну очень редкий случай частично напрямую связано с сложностью процесса установки модуля(который описал Asmo). Поскольку не многие могут написать плагин (про модуль и говорить нечего), а значит и не каждый сможет справиться с задачей установки модуля......мы же говорим про будущую популяризацию котонти, а если так то нужно учитывать факт что чайники тоже будут ставить модули (в зависимости от их нужд) значит, и процесс установки модуля должен быть не сложнее установки плуга.
Думаю те кто справляется с установкой плагинов, те справяться и с установкой модуля, стоит лишь продумать удобный инсталлятор для них, так же как и у плагинов. Возможно для этого придётся немного изменить концепцию модулей, но не более.]]> Sa, 16 Aug 2008 20:09:17 -0000 Dayver Идея про популяризацию модулеписательства вместо исключительно плагинописательства мне оч понравилась. Но то что до сих пор написание какого либо модуля это ну очень редкий случай частично напрямую связано с сложностью процесса установки модуля(который описал Asmo). Поскольку не многие могут написать плагин (про модуль и говорить нечего), а значит и не каждый сможет справиться с задачей установки модуля......мы же говорим про будущую популяризацию котонти, а если так то нужно учитывать факт что чайники тоже будут ставить модули (в зависимости от их нужд) значит, и процесс установки модуля должен быть не сложнее установки плуга.]]> Mo, 11 Aug 2008 12:14:05 -0000 Trustmaster Mo, 11 Aug 2008 07:25:29 -0000 Asmo Для поисковков plug.php?e=n это все один и тот же файл с разными параметрами, соответсвенно и отношение к нему такое же, плюс ко всему еще длиннее борода из параметров чем в модуле получается.]]> Mo, 11 Aug 2008 02:28:38 -0000 Asmo Чтобы модуль появился там, достаточно выполнить набор sql запросов:
1) добавить новый элемент в sed_core, появляется новый модуль

2) добавить набор прав в sed_auth , у нового элемнта появляется кнопка редактирования прав

3) добавить настройки по необходимости в sed_config , появляется соответствующая кнопка со ссылкой на редактирование конфига

Админ-часть нового модуля кладется в system/core/admin/admin.newmodule.inc.php
Да, еще, иконка модуля берется автоматически из папки system/img/admin ? туда нужно ,eltn добавить гифку newmodule.gif например :)
Управление для нового модуля готово.
Frontend часть модуля исполняется по всем правилам жанра движка c разброской файлов по соответсвующим папкам.

Занимался этим все выходные, необходимость вмешиваться в ядро не обнаружена, кроме того случая что я уже описал в первом посте. Сакральный смысл этого массива с умолчальными настройками в sed_loadconfigmap() для меня так и остался загадкой , может он делался из расчета быстрого восстановления работоспособности после потери базы данных, но смысл поднятия пустого движка без потерянных данных, мне не ясен.]]> Mo, 11 Aug 2008 02:23:46 -0000 Trustmaster
Да, хуки и инклюды - вселенское зло, когда дело касается производительности движка. В порядке эксперимента на одном из сайтов я их вообще вытравил как вид. Но необходимость в модульности против патчей возникла из практического опыта: когда необходимо поддерживать несколько сотен сайтов, а не один-два, то наложение очередного хака превращается в сущий ад, учитывая то, что на разных сайтах требуется разный набор хаков, которые, кроме прочего, ещё и зависят друг от друга.]]> So, 10 Aug 2008 11:55:43 -0000 Sergeich Кстати, помнится в ЛДУ можно было создавать копии файлов ядра, вносить в них изменения и каким то образом заставлять их работать совместно с основным ядром, скорее всего эта фича сохранилась и в Сед.]]> Sa, 09 Aug 2008 18:17:59 -0000 Asmo
Одной из причин для создания нового проекта была недостаточная модульность, которая вынуждает использовать хаки ядра вместо плагинов. Поэтому мы планируем вывести весь функционал, не относящийся к базовой системе, в плагины, попутно добавляя необходимые хуки там, где нужно. Это нанесёт некоторый ущерб производительности, но значительно упростит процесс разработки как ядра, так и плагинов.

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

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

Оливер предусмотрел такую возможность, но не до конца немного. Есть всего пару моментов буквально, где необходимо трогать код ядра.
Вернее даже один пока вижу: в function sed_loadconfigmap() добавить умолчальные конфиги для нового модуля, без этого, их уже добавленные в БД, не возможно изменять, ну и в плане языковых переменных, можно в общие языковые файлы добавлять новые константы, ну или уж если совсем не хочется никуда лезть, то отдельный языковый файл заинклудить для конкретного модуля тоже не тяжело.

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

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

Такой подход ничем не хуже плагинов, а даже лучше, все что нужно - это забросить папку в core и выполнить sql с правами, конфигами и новыми таблицами.]]> Sa, 09 Aug 2008 12:15:15 -0000 Trustmaster
2. Полная обратная совместимость - удовольствие дорогое. Поэтому мы планируем постепенное внедрение нововведений, если такие имеются. По крайней мере, в ветке 0.0.x никаких изменений в плагинах и скинах не потребуется. А к ветке 0.1.x будет видно, живёт проект, или заглохла инициатива.

3. Одной из причин для создания нового проекта была недостаточная модульность, которая вынуждает использовать хаки ядра вместо плагинов. Поэтому мы планируем вывести весь функционал, не относящийся к базовой системе, в плагины, попутно добавляя необходимые хуки там, где нужно. Это нанесёт некоторый ущерб производительности, но значительно упростит процесс разработки как ядра, так и плагинов.

4. На данном этапе у нас нет другого выбора. В лицензии есть только маленькая лазейка, которую мы пытаемся использовать. И так как Оливье с вероятностью 90%, мягко говоря, эта затея не понравится, он может быстро прикрыть эту лавочку. И до тех пор, пока в репозитории находится код с копирайтами Neocrome, мы не можем открыть его для масс. Если мы дойдём-таки до версии 1.0.0, где спорного кода не будет, то сможем открыть репозиторий и сайт для внешнего мира, явив ему новую CMS, основанную на многолетнем опыте LDU и Seditio.

5. Префиксы в бд никто менять не будет. Если вас смущает папочка branches/cotonti в репозитории, не обращайте на нее внимания - это давняя попытка Kilandor'а сваять новую CMS с нуля. Что касается именно префиксов, то формально, их можно менять даже в стандартном Seditio.

6. Jason Booth (Kilandor).

7. Народ :) Новый код лицензируется под BSD, авторские права на отдельные части сохраняются за их оригинальными авторами, авторские права на весь код проекта в целом закрепляются за составной единицей "Cotonti Team", которую (если возникнет-таки необходимость) нужно будет зарегистрировать.

8. KIlandor поставил Трак, и настаивает на том, что это скорее необходимость, чем каприз ввиду поддержки SVN, дорожной карты и т.д. и т.п. Над трекером надо работать, об этом все говорят, но никто не делает. У меня на него нет времени, Kilandor пишет плагины для интеграции Trac в Сед, остальные курят в сторонке и выдвигают предложения / предлагают выдвижения.

Есть ещё вопросы, пишите, отвечу.]]> Sa, 09 Aug 2008 05:26:58 -0000 Antar Поэтому я задам вопросы, надеюсь, будут ответы.

1. Какова цель проекта?
2. Планируется ли постоянное compatibility (забыл, как по-русски) с плагинами и скинами седитио?
3. Стоит ли действительно уходить совсем от Седитио? Ведь можно хакнуть несколько основных файлов, а все остальное делать только плагинами. Причина - если проект загнется - возможность возврата на седитио.
4. Как авторы проекта видят его продвижение в массы? Ведь на данном этапе сайт закрыт, новых пользователей не намечается, а большинство тех кто тут, смотрят с интересом со стороны ( но рук не марают :) ).
5. Зачем менять префиксы в бд?, не повлияет ли это на пункт 2?
6. Кто хозяин домена?
7. Кто хозяин будущего движка?
8. Зачем установлен трак. Не лучше ли было доделывать тракер седитио? Как-никак - одним хорошим плагином больше (хотя, как я вижу - трак намного мощней?)

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

Если у кого-то еще есть вопросы, добавляйте.]]> Fr, 08 Aug 2008 20:59:10 -0000