демогогия часть2
| esclkm |
|
|---|---|
|
Вспомните - примерно 80% темплейтов на на neocrome отличались только header footer index css -- остальные сайты были абсолюьно идентичны. Зачем одни и теже файлы тянуть из скина в скин.
Или, например, удаляешь из скина 1 темплейт и движок загадочно не грузится. Что я считаю нужным сделать в итоге: 1.Модули должны иметь подобную файловую структуру с плагинами. 2.скин ланг максимально вынести в main.lang 3.Все темплейты пусть лежать в папке со своим модулем или плагином 4.если дизайнер менят тот или иной темплейт - он его загружает в папку со скином, а с модулем или плагином - его не трогает (зато потом двиг нормально работает при недостаче файлов) 5. В итоге скин сможет работать неся на борту только header footer index css - рахмер скина меньше - структура зачительно понятней. 6. при моем способе получится что админка - может быть а может и не быть в скине - по требованию скинмакера. ---------------------------------------------------------------------- мнение dayver: 1. все что идет по дефолту должно всегда лежать в папке со скином и только там. littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
| jcrush |
|
|---|---|
|
согласен, еще хотелось бы чтобы такие плагины как поиск, карта сайта и т.п. имеющие стандартную структуру были с одним tpl, думаю такое сделать не сложно, поля стандартные, а сколько пользы, втыкать например рекламу, сейчас приходиться каждый шаблон править и поиска и карты и тегов...
SEO блог: http://blog.stfw.ru/
|
| Dayver |
|
|---|---|
|
Итак, и снова в бой!
Тааакс тему, зачем то склонировали. Мнение моё написали, а вот доводов нету (хотя б ссылочку можно было оставить на тот топик). # esclkm : Или, например, удаляешь из скина 1 темплейт и движок загадочно не грузится.Такое случатся раз на мильйон.....больше года слежу за темами на neocrome.ru ... ни разу не видел что бы хоть кто то с таким сталкивался. 1. Согласен - будущие модули должны иметь такую же структуру как и у плагинов(но еще точно не решили какова все же правильная структура должна быть у плагинов). 2. Согласен при условии, что этот main.lang не будет лежать в папке системс (вот нужно мне изменить одну словарную форму то если в папке системс то это хак, если хак, то можно нарватся на геморой при обновлении до новой версии двигла). 3. Устал доказывать, почему это не правильно 4. Плодиловка файлов получится и все ради одного случая на мильйон 5. Размер может быть и меньше, а вот качество может пострадать. А структура и так очень понятна при "все в папке скина" .... и не надо это обзывать мусоркой. 6. Ток не понятно, а куда ж она денется если ее уберут из папки скина # jcrush : согласен, еще хотелось бы чтобы такие плагины как поиск, карта сайта и т.п. имеющие стандартную структуру были с одним tpl, думаю такое сделать не сложно, поля стандартные, а сколько пользы, втыкать например рекламу, сейчас приходиться каждый шаблон править и поиска и карты и тегов...Вот ты согласился ... а под вуалью не понятно еще выгодного ли оптимизирования тебе же хуже хотят сделать .... смотри ну доооопустим удастся оптимизировать тплки таким образом, что для 10 плагинов их будет не 10, а к примеру 5 .... но их распихают по папкам плагинов ... и что б тебе вставить код баннера тебе нужно будет лазить по папкам и править тплки ... а если они по умолчанию будут лежать в скине тебе сделать это будет, несомненно, легче To be continued Pavlo Tkachenko aka Dayver
|
| Ratibor |
|
|---|---|
# Dayver : 3. Устал доказывать, почему это не правильноА как это называть ? Ну не хочешь мусоркой, давай будем называть файл-помойкой. Начнем с того что плагин это отдельная единица и к движку отношения не имеет. К примеру я нуб и только что с горем пополам поставил Cotonti. Потом захожу сюда, скачиваю какой либо понравившийся плуг. И что ? Распакуйте плуг сюда, тпльку туда, а в css пропишите тото. И это только для того чтоб посмотреть плуг ? И если он не понравиться проделать эту же работу обратно. Туши свет. Плагин должен уже содержать в себе все необходимое, чтоб юзер мог просто распаковать его в папку плагинов и все. А вот если он уже решит его оставить и у него появится необходимость изменить вид, вот тогда он уже может отредактировать tpl в папке плагина или перекинуть эту tpl в папку со скином. Это же самое касается тех плагинов, которые включены в дистрибутив. Не важно что они дефолтные, как говорится перед законом все равны. Не задавай глупых вопросов, не услышишь вранья.
|
| Kort |
|
|---|---|
|
Только для этого понадобится соглашение о HTML-разметке плагиновских скинов. А это, в свою очередь, связано с разметкой model skin, который должен идти в поставке.
Model skin должен быть: 1. Максимально обезличенным с точки зрения дизайна 2. Наглядным, простым, юзабельным и пригодным для навеса на него конкретной дизайн-идеи 3. Универсальным (1-, 2-, 3-колоночная верстка) 4. Хорошо откоментированным 5. Хотя бы слегка SEO-friendly (никаких безумных mboxHD или привычных title: только h1, h2 и т. д.) Это то, что пришло в голову. Добавить можно много чего еще. При таком подходе можно обеспечить безболезненную установку, тестирование и использование плагинов для всех категорий граждан. SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
| Sergeich |
|
|---|---|
|
я предвижу следующую ситуацию: многие (очень многие) пользователи системы начнут делать именно так, как ты предлагаешь, Ratibor, т.е. скинули плагин в папку, включили и забыли о нём, допустим у меня на странице отрабатывается 10 плагинов с тплками и кссками (вполне реальная ситуация), тогда для формирования этой странички движку потребуется подключить 12 CSS-файлов! и очень повезёт, если в них не будет конфликтов. А если конфликты будут то придётся их искать в этих 12 файлах, да ещё если они все в разных папках...
Отсюда следует несколько неприятных моментов: Движок начнёт лепить по умолчанию говнокод. Простота первичной установки автоматом снизит уровень знаний пользователей движка. Процесс поиска ошибок в скине усложнится неимоверно. Плагинописателям придётся крайне тщательно подходить к разработке шаблона и ксс к своим плагинам, раньше или позже они нафиг пошлют весь этот гемморой. Да, конечно, можно по старинке всё файло засунуть в папку скина, настроить как надо, но... Это сделаю я, это сделаешь ты, но этого не сделают сотни начинающих васей пупкиных. Зато эти сотни заипут тех.поддержку глупыми вопросами (причём в каждой конкретной ситуации придётся разбираться отдельно), а также завалят интернет очень "лестными" отзывами о движке. Ф топку. Пусть уж лучше плагин вообще не работает, чем такие проблеммы поимет. |
|
Bu konu Sergeich tarafından düzenlendi(2009-03-12 19:39, 15 yıllar önce) |
| Kort |
|
|---|---|
|
А много плагинов под Seditio использовали свои css? А много плагинов под Cotonti сейчас требуют свои css? А почему штатный плагин Tags имеет и вынесенный css и класс в sed-light.css?
Я и сам против выноса css/tpl из каталога со скином. Но движок должен (насколько это возможно) подходить для всех уровней пользователя. Вдогон: плагин-мэйкерам вообще стоит рекомендовать не включать css в поставку плагина. plugins/whosonline/tpl/whosonline.css означает навязывание стороннего дизайна (со всеми вытекающими последствиями), а шаблон плагина должен соответствовать общему дизайну сайта и быть обезличенным. SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
|
Bu konu Kort tarafından düzenlendi(2009-03-12 19:32, 15 yıllar önce) |
| Sergeich |
|
|---|---|
|
не должен он подходить для всех групп пользователей. Это первый, даже не шаг, прыжок в сторону создания неудобоваримого монстра. Нужно определиться для кого делается движок, так уж сложилось исторически, что ЛДУ, Сед, а теперь и Кот - это движок для дизайнера со знанием ХТМЛ или верстальщика. Не нужно менять этот вектор развития, это фича отличающая его от других и позволяющая создавать абсолютно разные сайты копаясь только в шаблонах, не трогая кода.
Корт:Сейчас может быть и не много (хотя, вообще-то, много ;) ), но в случае, который предлагает Ratibor, практически каждый плагин обзаведётся своим CSS и tpl. |
| Kort |
|
|---|---|
|
imo любой движок предназначен для создания сайтов. И любой движок должен продвигаться на рынке ему подобных. А делать это можно не только за счет его технической продвинутости (которая мало кому видна), но и за счет юзабилити и дружественности к пользователю. Есть моменты, которые можно реализовать простыми способами:
1. Model skin 2. Плагины, созданные "под model skin" 3. Custom skins, созданные "под model skin" И плагины и скины выкладываются здесь не каждый день, и "причесать" их под единые требования для штатного дизайнера / скинмэйкера не проблема. Вот тогда и получится это переключение. SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
| 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 в плагинах надо хорошенько подумать и сделать чтоб красиво было. Не задавай глупых вопросов, не услышишь вранья.
|
|
Bu konu Ratibor tarafından düzenlendi(2009-03-12 20:20, 15 yıllar önce) |
| Kort |
|
|---|---|
# Ratibor : P.S. Вот пример правильного css для плагинаЭто пример того, почему css (aka оформление) нельзя использовать в плагине: 1. В sed-light.css объявляются 4 класса таблиц. 3 из них подходят. 2. Жестко забитые высоты и ширины? Для любого дизайна не подойдет. 3. А цветам место в конфиге плагина (вдруг у меня все ссылки зеленые?). Все, css закончился SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
| Ratibor |
|
|---|---|
# Kort : 1. В sed-light.css объявляются 4 класса таблиц. 3 из них подходят.А вот в моем скине ни один не подходит  # Kort : 2. Жестко забитые высоты и ширины? Для любого дизайна не подойдет.В данном случае все это не важно, не об этом речь Важно то, что там все привязано к конкретному плагину. Если все плагинописатели научатся правильно оформлять свои плагины, то тогда все будет нормально. А если нет, то и не жалко, без них говна хватает. Не задавай глупых вопросов, не услышишь вранья.
|
| medar |
|
|---|---|
Kort:Пока обсуждение не ушло хз куда хочу отметить, что данная ситуация есть хорошая иллюстрация к тому, как надо хранить tpl и css плагинов и как движок должен использовать их. А именно так, как предложил esclkm в первом мосте в пунктах 3 и 4. - смотрим, есть ли файл tpl или css файл в /skins/ (ну или в /skins/plugins/) - если да, используем его. если нет, используем файлы из /plugins/plugin_name/tpl Dayver:Как мы видим, это не один случай на мильон, это потребуется везде, где дефолтный css плагина не подходит к дизайну скина. Ты можешь, кстати, повторить свою аргументацию, почему это не правильно, или ссылку на пост кинуть ? Kort:css-файл - уже такой конфиг по сути. У нас движок для юзеров, которые не боятся править tpl и css. Меняешь css плагина под свой скин и записываешь его в этот скин - и ссылки снова зеленые. Делать возможность задавать все из админки - пока не наш путь. Чтобы не было конфликтов, кстати, в plugin coding guide прописать пожелание использовать сложные названия css-классов, желательно с префиксом в виде названия плагина. Kort:Согласен с перечисленным. Я начал делать такой скин вот так пока получается: http://exampler.net/cotnewskin . В ближайшее время продолжу. rangjungyeshe.ru
|
|
Bu konu medar tarafından düzenlendi(2009-03-12 21:57, 15 yıllar önce) |
| Kort |
|
|---|---|
|
Для юзеров, которые не боятся править tpl и css, и так все замечательно работает. Забрасывать спецом для них tpl и css в лишний каталог и группировать админовские шаблоны -- сомнительное удобство, которое не стоит всех этих мозговых штурмов :)
SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
| esclkm |
|
|---|---|
|
РЕбят вы любите уходить от темы.
я рассматриваю движок - как ядро - а все остальное это чужеродные части (инородные тела, пускай даже сделанные той же коммандой и по антигенной структуре идентичны). Например я хочу сделать сайт без форума и опросов - ну зачем мне будут в скине файлы по опросам и форумам, я считаю не зачем. Я должен иметь возможность все отключить безболезненно и быстро. Для дизайнеров - это люди знающие и умные - и скинуть нужные им файлы в папку со скином - им труда не составит. Но дефолтовый темплейт - должен быть в папке с модулем. и он должен быть максимально простым и максимально оптимизованым под общепользовательские нужды. (ТО же самое ленг файлов. - зачем каждый лок от каждого плагина выкидывать в отдельную папку. Надо включить возможность того чтобы локализация сначала искалась в папке с плагином, а затем в общей папке ланг. - тогда чтобы перевести сокотни на укр понадобиться только скопировать 1 папку и никаких замен.) littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
