cotonti.com : Скины. Метод теплейтов хранения по умолчанию. https://www.cotonti.com Последние сообщения в теме Cotonti en Mon, 23 Feb 2026 22:39:23 -0000 medar Kort:
Для юзеров, которые не боятся править tpl и css, и так все замечательно работает. Забрасывать спецом для них tpl и css в лишний каталог и группировать админовские шаблоны -- сомнительное удобство, которое не стоит всех этих мозговых штурмов :) Схема дублирования tpl/css с приоритетом папки skins дает следующие плюсы:

- можно распространять скины с подогнанными tpl/css дефолтных плагинов (у нас же есть дефолтные плагины)
- можно распространять скины с подогнанными tpl/css плагинов для сборок (движок + некоторые плагины). Подозреваю, сборки будут.
- если сайт имеет несколько скинов (допустим, юзер может их выбирать), то для каждого скина можно настроить корректное отображение плагинов.

Согласен ?

И да, сия проблема не стоит такого активного мозгового штурма :)]]> пт, 13 мар 2009 04:32:55 -0000 esclkm я рассматриваю движок - как ядро - а все остальное это чужеродные части (инородные тела, пускай даже сделанные той же коммандой и по антигенной структуре идентичны).
Например я хочу сделать сайт без форума и опросов - ну зачем мне будут в скине файлы по опросам и форумам, я считаю не зачем. Я должен иметь возможность все отключить безболезненно и быстро.
Для дизайнеров - это люди знающие и умные - и скинуть нужные им файлы в папку со скином - им труда не составит.
Но дефолтовый темплейт - должен быть в папке с модулем. и он должен быть максимально простым и максимально оптимизованым под общепользовательские нужды.

(ТО же самое ленг файлов. - зачем каждый лок от каждого плагина выкидывать в отдельную папку. Надо включить возможность того чтобы локализация сначала искалась в папке с плагином, а затем в общей папке ланг. - тогда чтобы перевести сокотни на укр понадобиться только скопировать 1 папку и никаких замен.)]]> пт, 13 мар 2009 00:27:22 -0000 Kort чт, 12 мар 2009 22:22:09 -0000 medar Kort:
Это пример того, почему css (aka оформление) нельзя использовать в плагине: Пока обсуждение не ушло хз куда хочу отметить, что данная ситуация есть хорошая иллюстрация к тому, как надо хранить tpl и css плагинов и как движок должен использовать их.

А именно так, как предложил esclkm в первом мосте в пунктах 3 и 4.
- смотрим, есть ли файл tpl или css файл в /skins/ (ну или в /skins/plugins/)
- если да, используем его. если нет, используем файлы из /plugins/plugin_name/tpl

Dayver:
3. Устал доказывать, почему это не правильно
4. Плодиловка файлов получится и все ради одного случая на мильйон
Как мы видим, это не один случай на мильон, это потребуется везде, где дефолтный css плагина не подходит к дизайну скина.
Ты можешь, кстати, повторить свою аргументацию, почему это не правильно, или ссылку на пост кинуть ?

Kort:
3. А цветам место в конфиге плагина (вдруг у меня все ссылки зеленые?).
css-файл - уже такой конфиг по сути. У нас движок для юзеров, которые не боятся править tpl и css. Меняешь css плагина под свой скин и записываешь его в этот скин - и ссылки снова зеленые. Делать возможность задавать все из админки - пока не наш путь.

Чтобы не было конфликтов, кстати, в plugin coding guide прописать пожелание использовать сложные названия css-классов, желательно с префиксом в виде названия плагина.

Kort:
Model skin должен быть:
Согласен с перечисленным.
Я начал делать такой скин вот так пока получается: http://exampler.net/cotnewskin . В ближайшее время продолжу.]]> чт, 12 мар 2009 21:47:37 -0000 Ratibor # Kort : 1. В sed-light.css объявляются 4 класса таблиц. 3 из них подходят.
А вот в моем скине ни один не подходит :-)
# Kort : 2. Жестко забитые высоты и ширины? Для любого дизайна не подойдет.
3. А цветам место в конфиге плагина (вдруг у меня все ссылки зеленые?).
В данном случае все это не важно, не об этом речь :-)
Важно то, что там все привязано к конкретному плагину.
Если все плагинописатели научатся правильно оформлять свои плагины,
то тогда все будет нормально.
А если нет, то и не жалко, без них говна хватает.]]> чт, 12 мар 2009 20:58:11 -0000 Kort # Ratibor : P.S. Вот пример правильного css для плагинаЭто пример того, почему css (aka оформление) нельзя использовать в плагине:
1. В sed-light.css объявляются 4 класса таблиц. 3 из них подходят.
2. Жестко забитые высоты и ширины? Для любого дизайна не подойдет.
3. А цветам место в конфиге плагина (вдруг у меня все ссылки зеленые?).
Все, css закончился]]> чт, 12 мар 2009 20:39:25 -0000 Ratibor # Sergeich : тогда для формирования этой странички движку потребуется подключить 12 CSS-файлов! и очень повезёт, если в них не будет конфликтов. А если конфликты будут то придётся их искать в этих 12 файлах, да ещё если они все в разных папках...

Отсюда следует несколько неприятных моментов:
Движок начнёт лепить по умолчанию говнокод.
Нечего лепить говноплагины и не будет говнокода.

Вот живой пример:
какой то чудак, но не на букву Ч, в SVN перекинул плагин login в оттестированные.
Смотрим код login.header.tags.php:

require($cfg['plugins_dir'].'/login/lang/login.'.$lang.'.lang.php');

при этом папки с ланг файлами и нет в помине.

P.S. Вот пример правильного css для плагина:
/* This style only for MCALENDAR plugin BEGIN */
table.mcalendar { border-collapse:collapse; }
.mcalendar table { background-color:#FFFFFF; font-size: 100%; font-family: tahoma; border-collapse:collapse; }
.mcalendar td { background-color: #f0f0f0; border:1px solid #FFFFFF; vertical-align:middle; text-align:center; }
.mcalendar td.field { width: 20px; height:20px; }
.mcalendar td.future { color: #B0B0B0; width: 20px; height:20px; }
.mcalendar td.today { font-weight:bold; color:green; width: 20px; height:20px; }
.mcalendar td.week { color:#5D7BA7; width: 20px; height:15px; }
.mcalendar td.navigation { background-color:#c9c9c9; }
.mcalendar td.month { background-color:#d9d9d9; }
.mcalendar td.year { background-color:#d9d9d9; }
.mcalendar a { color: #0000FF; text-decoration: underline; font-weight:normal; }
.mcalendar a:hover { color: #0000FF; text-decoration: none; font-weight:bolder; }
/* This style only for MCALENDAR plugin END */

P.P.S. А вот как подключать css в плагинах надо хорошенько подумать и сделать чтоб красиво было.]]> чт, 12 мар 2009 20:07:36 -0000 Kort 1. Model skin
2. Плагины, созданные "под model skin"
3. Custom skins, созданные "под model skin"
И плагины и скины выкладываются здесь не каждый день, и "причесать" их под единые требования для штатного дизайнера / скинмэйкера не проблема. Вот тогда и получится это переключение.]]> чт, 12 мар 2009 19:53:53 -0000 Sergeich
Корт:
А много плагинов под Seditio использовали свои css? А много плагинов под Cotonti сейчас требуют свои css?
Сейчас может быть и не много (хотя, вообще-то, много ;) ), но в случае, который предлагает Ratibor, практически каждый плагин обзаведётся своим CSS и tpl.]]> чт, 12 мар 2009 19:35:15 -0000 Kort Я и сам против выноса css/tpl из каталога со скином. Но движок должен (насколько это возможно) подходить для всех уровней пользователя.

Вдогон: плагин-мэйкерам вообще стоит рекомендовать не включать css в поставку плагина. plugins/whosonline/tpl/whosonline.css означает навязывание стороннего дизайна (со всеми вытекающими последствиями), а шаблон плагина должен соответствовать общему дизайну сайта и быть обезличенным.]]> чт, 12 мар 2009 19:09:44 -0000 Sergeich
Отсюда следует несколько неприятных моментов:
Движок начнёт лепить по умолчанию говнокод.
Простота первичной установки автоматом снизит уровень знаний пользователей движка.
Процесс поиска ошибок в скине усложнится неимоверно.
Плагинописателям придётся крайне тщательно подходить к разработке шаблона и ксс к своим плагинам, раньше или позже они нафиг пошлют весь этот гемморой.

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

Ф топку. Пусть уж лучше плагин вообще не работает, чем такие проблеммы поимет.]]> чт, 12 мар 2009 18:49:05 -0000 Kort Model skin должен быть:
1. Максимально обезличенным с точки зрения дизайна
2. Наглядным, простым, юзабельным и пригодным для навеса на него конкретной дизайн-идеи
3. Универсальным (1-, 2-, 3-колоночная верстка)
4. Хорошо откоментированным
5. Хотя бы слегка SEO-friendly (никаких безумных mboxHD или привычных title: только h1, h2 и т. д.)
Это то, что пришло в голову. Добавить можно много чего еще.
При таком подходе можно обеспечить безболезненную установку, тестирование и использование плагинов для всех категорий граждан.]]> чт, 12 мар 2009 18:32:47 -0000 Ratibor # Dayver : 3. Устал доказывать, почему это не правильно
4. Плодиловка файлов получится и все ради одного случая на мильйон
5. Размер может быть и меньше, а вот качество может пострадать. А структура и так очень понятна при "все в папке скина" .... и не надо это обзывать мусоркой.
А как это называть ?
Ну не хочешь мусоркой, давай будем называть файл-помойкой.

Начнем с того что плагин это отдельная единица и к движку отношения не имеет.

К примеру я нуб и только что с горем пополам поставил Cotonti.
Потом захожу сюда, скачиваю какой либо понравившийся плуг.
И что ?
Распакуйте плуг сюда, тпльку туда, а в css пропишите тото.
И это только для того чтоб посмотреть плуг ?
И если он не понравиться проделать эту же работу обратно.
Туши свет.

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

Это же самое касается тех плагинов, которые включены в дистрибутив.
Не важно что они дефолтные, как говорится перед законом все равны.]]> чт, 12 мар 2009 17:18:17 -0000 Dayver Тааакс тему, зачем то склонировали. Мнение моё написали, а вот доводов нету (хотя б ссылочку можно было оставить на тот топик).

# esclkm : Или, например, удаляешь из скина 1 темплейт и движок загадочно не грузится.
Такое случатся раз на мильйон.....больше года слежу за темами на neocrome.ru ... ни разу не видел что бы хоть кто то с таким сталкивался.

1. Согласен - будущие модули должны иметь такую же структуру как и у плагинов(но еще точно не решили какова все же правильная структура должна быть у плагинов).
2. Согласен при условии, что этот main.lang не будет лежать в папке системс (вот нужно мне изменить одну словарную форму то если в папке системс то это хак, если хак, то можно нарватся на геморой при обновлении до новой версии двигла).
3. Устал доказывать, почему это не правильно
4. Плодиловка файлов получится и все ради одного случая на мильйон
5. Размер может быть и меньше, а вот качество может пострадать. А структура и так очень понятна при "все в папке скина" .... и не надо это обзывать мусоркой.
6. Ток не понятно, а куда ж она денется если ее уберут из папки скина

# jcrush : согласен, еще хотелось бы чтобы такие плагины как поиск, карта сайта и т.п. имеющие стандартную структуру были с одним tpl, думаю такое сделать не сложно, поля стандартные, а сколько пользы, втыкать например рекламу, сейчас приходиться каждый шаблон править и поиска и карты и тегов...
Вот ты согласился ... а под вуалью не понятно еще выгодного ли оптимизирования тебе же хуже хотят сделать .... смотри ну доооопустим удастся оптимизировать тплки таким образом, что для 10 плагинов их будет не 10, а к примеру 5 .... но их распихают по папкам плагинов ... и что б тебе вставить код баннера тебе нужно будет лазить по папкам и править тплки ... а если они по умолчанию будут лежать в скине тебе сделать это будет, несомненно, легче

To be continued]]> чт, 12 мар 2009 15:21:59 -0000 jcrush чт, 12 мар 2009 13:35:57 -0000 esclkm Или, например, удаляешь из скина 1 темплейт и движок загадочно не грузится.

Что я считаю нужным сделать в итоге:
1.Модули должны иметь подобную файловую структуру с плагинами.
2.скин ланг максимально вынести в main.lang
3.Все темплейты пусть лежать в папке со своим модулем или плагином
4.если дизайнер менят тот или иной темплейт - он его загружает в папку со скином, а с модулем или плагином - его не трогает (зато потом двиг нормально работает при недостаче файлов)
5. В итоге скин сможет работать неся на борту только header footer index css - рахмер скина меньше - структура зачительно понятней.
6. при моем способе получится что админка - может быть а может и не быть в скине - по требованию скинмакера.

----------------------------------------------------------------------
мнение dayver:
1. все что идет по дефолту должно всегда лежать в папке со скином и только там.]]> чт, 12 мар 2009 13:05:52 -0000