Унификация шаблонов редактирования страницы

91.9% 57
6.5% 4
1.6% 1

62 Дата 07.12.2012 07:36

Форуми / National / Russian / Идеи / Опитування: Унификация шаблонов редактирования страницы

Alex300
#1 07.12.2012 07:36

В связи с этим: https://github.com/Cotonti/Cotonti/issues/920

Мы получили удобный инструмент для управления страницами.

В формах страниц параметры полей стали одинаковыми при редактировании и создании страницы, нарпимер названия полей: rpage<имя_поля>

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

Для себя я этот вопрос решаю планигом т.к. сейчас реальная разница в этих шаблонах только в префиксах тегов. Но может пришла пора от этого избавляться?

А, если у кого-то есть специфика требующая вывода одних полей при редактировании страницы и не вывода их при добавлении, то это легко решается условиями.

Есть миры, не здесь, там, где небеса горят, и моря засыпают, и реки дремлют; люди сделаны из дыма, а города – из песен. Где-то опасность, где-то несправедливость, даже где-то остыл чай. Идем Эйс, у нас много работы!...
...Sorry for my english...
Бесплатные расширения для Cotonti: https://lily-software.com/free-scripts/

Відредаговано: Alex300 (07.12.2012 07:44, 11 років тому)
esclkm
#2 07.12.2012 08:52
Может. Может. Но с возможностью разных
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Trustmaster
#3 07.12.2012 10:08

Отличная идея! Создал аналогичный англоязычный опрос.

May the Source be with you!
Moool13
#4 07.12.2012 10:51

За, но полностью исключать page.add.tpl думаю не стоит - если он есть в скине, использовать его.

Macik
#5 07.12.2012 12:42
#36461 Moool13:

За, но полностью исключать page.add.tpl думаю не стоит - если он есть в скине, использовать его.

В целом тоже «за». Однако согласен с «Moool»,  и изложил несколько вопросов и предлождений в английском топике.

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
esclkm
#6 07.12.2012 12:47

подробно:

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

- это начало переименовывания тегов. А если переименовываем в 1 месте, то летит гора плагинов, и это меприятие требует замены кругом шаблонов

Добавлено 4 часа спустя:

в общем вечер думал - шаблоны все-таки не одинаковые. я против.

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

Відредаговано: esclkm (07.12.2012 16:58, 11 років тому)
Moool13
#7 07.12.2012 18:00

в общем вечер думал - шаблоны все-таки не одинаковые. я против.

Про это и речь - шаблоны будут объединены, но различные шаблоны в несколько файлов по-прежнему можно будет использовать, так же лучше, имхо.

esclkm
#8 07.12.2012 18:40

Moool13 - у эдит есть: OWNER DATE DELETE и другие, которых нет у простого add / да и зачем крушить шаблоны

Добавлено 1 минуты спустя:

редактирование данных шаблоно в занимает 2 минуты... а вот header и footer надо объединить имхо

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Kort
#9 07.12.2012 19:16

page.add'ы обычно формируется в конце работ по сайту из page.edit'ов за максимум полчаса

На этапе разработки сейчас мне достаточно дефолтного page.add из папки с модулем. Вся работа идет только с page.edit. В конце они унифицируются по п. 1. Никаких лишних проблем и телодвижений это не требует.

Часто и в add и в edit используются конструкции IF / ELSE с проверкой разделов, в нескольких проектах у меня, например, использованы селекты и jQuery. Часто add и edit шаблоны вообще не симметричны (запрещена смена раздела или ключевого экстраполя).

Дефолтный page.add из папки модуля теперь не будет подтягиваться? Или его не будет? Или как?

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

Примитивные сайтики станут на один шаблон короче. Там, где необходима гибкость, ничего не улучшится (да и зачем?)

Нет.

SED.by - создание сайтов, разработка плагинов и тем для Котонти
Aristei
#10 20.06.2013 18:44

Согласен с Kort. И думаю такие вопросы нужно решать не голосованием. Потому как я сначала был за, а прочитав пост Kort стал против:)

Многие голосуют не осознвая подводных камней.

Sorry for my English
Oughtem
#11 30.06.2013 13:27

Имея сайты, где доп.полей больше чем 50, я соглашусь с тем, что шаблоны не плохо было бы объединить.

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

Примитивные сайтики станут на один шаблон короче

И не примитивные тоже станут на один шаблон короче.

у эдит есть: OWNER DATE DELETE и другие, которых нет у простого add / да и зачем крушить шаблоны

это легко обходится условиями

редактирование данных шаблоно в занимает 2 минуты

на небольшом сайте да.

Конечно, старые сайты, возможно, и придётся обгрейдить, но это же не причина отказываться от нововведения.

Macik
#12 02.07.2013 14:34

Раз уж тему воскресили - подкину дровишек:

1. Неоднократно думал о необходимости дополнительного модуля, типа CCK (Content construction kit). Суть в том, чтобы в удобном интерфейсе определять какие поля нужны для того или иного типа страниц, какие из них отображать при создании, какие при редактировании. А в шаблоны просто вставлять обобщенные тэги {CCK_PAGE_ADD} / {CCK_PAGE_EDIT} (или вообще единый). Тогда вопрос нужной/ненужной унификации решается сам собой, кому нужно тот пользует, кому нет - сидит на старых шаблонах. Но вот на пути реализации есть одна загвоздка - см. пунтк 2.

2. На самом деле об этой проблеме я уже писал (#1152). Можете там прочитать - там подробно. Если кратко то проблема в том, что мы не имеем единого стандарта именования переменных языкового файла, которые отвечают за названия «стандартных» полей форм. Это хорошо видно на примере модуля «pages» (см. описание на ГитХабе). 

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F