редактор полей для страниц

esclkm	#1 2008-12-18 05:59
Team Thanked: 76 times	Увидев его в действии я был если честно более чем восхищен! Это реально очень нужная вещь и реализована весьма супер приятно! в общем большой респект. но: 1. таблица sed_pages_extra_fields я бы ее лучше назвал просто sed_extra_fields, и добавил туда еще одно поле: location - то есть это дополнительное поле укаывает это поля для таблицы пользователей страниц форумов и прочее и все в одной таблице, зачем гора аналогичных таблиц? 2. еще одно поле description - тоесть простое описание зачем как и что это надо. дабы если вдруг забудешь какое поле за что отвечает - глянул туда и все написано. 2. поля: может лучше индекс не my а extra ? что более исконно привычно 3. а зачем тогда поля page_extra1 - page_extra5. Их можно удалить дабы убрать избыточные поля в базе данных. 4. user_occupation user_location user_birthdate user_gender user_irc user_msn user_icq user_website user_extra1-9 - при становлении подобного редактора для таблицы пользователей можно будет также удалить Я понимаю что мы сможем убить совместимость для части плагинов. (ну пускай их будет до 10...) - но если мы хорошо докуметируем как избежать несовместимости то все будет окейно. Интересно ваше мнение, если отошел от общей концепции разработки прошу простить. littledev.ru - мой маленький зарождающийся блог о котонти. снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
This post was edited by esclkm (2008-12-18 06:40, 15 years ago)

esclkm

#1 2008-12-18 05:59

Увидев его в действии я был если честно более чем восхищен! Это реально очень нужная вещь и реализована весьма супер приятно! в общем большой респект.

но:
1. таблица sed_pages_extra_fields я бы ее лучше назвал просто sed_extra_fields, и добавил туда еще одно поле: location - то есть это дополнительное поле укаывает это поля для таблицы пользователей страниц форумов и прочее и все в одной таблице, зачем гора аналогичных таблиц?
2. еще одно поле description - тоесть простое описание зачем как и что это надо. дабы если вдруг забудешь какое поле за что отвечает - глянул туда и все написано.

2. поля: может лучше индекс не my а extra ? что более исконно привычно
3. а зачем тогда поля page_extra1 - page_extra5. Их можно удалить дабы убрать избыточные поля в базе данных.
4. user_occupation user_location user_birthdate user_gender user_irc user_msn user_icq user_website user_extra1-9 - при становлении подобного редактора для таблицы пользователей можно будет также удалить

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

Интересно ваше мнение, если отошел от общей концепции разработки прошу простить.

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

This post was edited by esclkm (2008-12-18 06:40, 15 years ago)

medar	#2 2008-12-18 17:30
Contributors Thanked: 5 times	Спасибо на добром слове :) 1. Я не юзаю в своих сайтах форум, поэтому не знаю, что ему нужно. Там разве тоже нужны дополнительные поля ? Они же вроде нужны для pages и users только. 2. Да, описание надо будет сделать, полезно. Но поводу названия - просто MY короче, а EXTRA уже используется в extra1-5 . Но, в принципе, {PAGE_EXTRA_FIELD} вместо {PAGE_MY_FIELD} тоже неплохо смотрится. Народ, как вы считаете ? 3-4. Пусть будут имеющиеся дополнительные поля. Дополнительной нагрузки на БД это не создаст, а плагины у народа посыпятся, если их удалить. rangjungyeshe.ru

medar

#2 2008-12-18 17:30

Contributors
Thanked: 5 times

Спасибо на добром слове :)

1. Я не юзаю в своих сайтах форум, поэтому не знаю, что ему нужно. Там разве тоже нужны дополнительные поля ? Они же вроде нужны для pages и users только.

2. Да, описание надо будет сделать, полезно.

Но поводу названия - просто MY короче, а EXTRA уже используется в extra1-5 . Но, в принципе, {PAGE_EXTRA_FIELD} вместо {PAGE_MY_FIELD} тоже неплохо смотрится. Народ, как вы считаете ?

3-4. Пусть будут имеющиеся дополнительные поля. Дополнительной нагрузки на БД это не создаст, а плагины у народа посыпятся, если их удалить.

rangjungyeshe.ru

Trustmaster	#3 2008-12-18 17:55
Administrators Thanked: 263 times	2. Я бы вообще префиксы убрал и сделал проверку на повторяющиеся имена. Чтобы можно было добавить, скажем, page_thumb, а не page_my_thumb или page_extra_thumb. 3-4. Согласен, для совместимости оставим. May the Source be with you!

esclkm	#4 2008-12-18 23:14
Team Thanked: 76 times	ну вот пришли к консенсусу негласному(!) подобъединю мысли медара trustmastera и мои. 1. в таблицу добавить поле description 2. в таблицу добавить поле location - согласитесь 5-7 полей для целой таблицы и все немного не рационально - и гора таблиц потом самих же запутает 3. убрать префиксы - но сделать проверку на повторяющиеся имена 4. изначально в таблицу уже будут добавлены поля extra1-extra5 - которые соответствуют стандартным - в итоге пользователю они не нужны - он их сам и удалит. имхо гениально и просто. Вы так не считаете? при этом с совместимостью проблем вообще никаких! (Да и от старого движка весьма сильный отход-не влекущий за собой изменений в совместимости) 5. user_occupation user_location user_birthdate user_gender user_irc user_msn user_icq user_website user_extra1-9 - при становлении подобного редактора для таблицы пользователей эти поля постигнет таже судьба что и поля extra1-5 в предыдущем пункте. 6. В имени данного экстра поля должна быть проверка, чтобы там присутствовали только англ сиволы и цифры, а остальные просто урезались В итоге такой будет фридом на нашей поляне! как вы считаете? littledev.ru - мой маленький зарождающийся блог о котонти. снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
This post was edited by esclkm (2008-12-19 00:52, 15 years ago)

esclkm

#4 2008-12-18 23:14

Team
Thanked: 76 times

ну вот пришли к консенсусу негласному(!)
подобъединю мысли медара trustmastera и мои.

1. в таблицу добавить поле description
2. в таблицу добавить поле location - согласитесь 5-7 полей для целой таблицы и все немного не рационально - и гора таблиц потом самих же запутает
3. убрать префиксы - но сделать проверку на повторяющиеся имена
4. изначально в таблицу уже будут добавлены поля extra1-extra5 - которые соответствуют стандартным - в итоге пользователю они не нужны - он их сам и удалит. имхо гениально и просто. Вы так не считаете? при этом с совместимостью проблем вообще никаких! (Да и от старого движка весьма сильный отход-не влекущий за собой изменений в совместимости)
5. user_occupation user_location user_birthdate user_gender user_irc user_msn user_icq user_website user_extra1-9 - при становлении подобного редактора для таблицы пользователей эти поля постигнет таже судьба что и поля extra1-5 в предыдущем пункте.
6. В имени данного экстра поля должна быть проверка, чтобы там присутствовали только англ сиволы и цифры, а остальные просто урезались

В итоге такой будет фридом на нашей поляне! как вы считаете?

This post was edited by esclkm (2008-12-19 00:52, 15 years ago)

Trustmaster	#5 2008-12-19 00:43
Administrators Thanked: 263 times	По-научному поля вроде extra1-9 называются повторяющимися группами и нормализуются следующим образом. Допустим, у нас есть отношение (таблица) example, у которой есть обязательные поля id и name, а также может присутствовать некоторое количество дополнительных полей. В таком случае формируется 3 отношения: 1-е для исходной сущности, 2-е для перечня повторяющихся групп, 3-е для хранения значений повторяющихся групп: CREATE TABLE example ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(255) NOT NULL, PRIMARY KEY(id) ); CREATE TABLE extras ( id INT NOT NULL AUTO_INCREMENT, parent_table VARCHAR(100) NOT NULL, name VARCHAR(100) NOT NULL, PRIMARY KEY(id), KEY(parent_table) ); CREATE TABLE extra_values ( extra INT NOT NULL REFERENCES extras(id), value VARCHAR(255) NOT NULL, KEY(extra) ); Проблема в том, что для каждого типа поля придется создавать при таком подходе отдельную таблицу. Да вообще Нормализация - это хорошо с точки зрения проектирования и расширяемости, но в CMS ей редко следуют строго, чтобы сократить количество коррелированных запросов за счет введения избыточности данных. May the Source be with you!

Trustmaster

#5 2008-12-19 00:43

Administrators
Thanked: 263 times

По-научному поля вроде extra1-9 называются повторяющимися группами и нормализуются следующим образом. Допустим, у нас есть отношение (таблица) example, у которой есть обязательные поля id и name, а также может присутствовать некоторое количество дополнительных полей. В таком случае формируется 3 отношения: 1-е для исходной сущности, 2-е для перечня повторяющихся групп, 3-е для хранения значений повторяющихся групп:

CREATE TABLE example (
  id INT NOT NULL AUTO_INCREMENT,
  name VARCHAR(255) NOT NULL,
  PRIMARY KEY(id)
);

CREATE TABLE extras (
  id INT NOT NULL AUTO_INCREMENT,
  parent_table VARCHAR(100) NOT NULL,
  name VARCHAR(100) NOT NULL,
  PRIMARY KEY(id),
  KEY(parent_table)
);

CREATE TABLE extra_values (
  extra INT NOT NULL REFERENCES extras(id),
  value VARCHAR(255) NOT NULL,
  KEY(extra)
);

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

May the Source be with you!

Sergeich	#6 2009-02-11 16:05
Contributors Thanked: 15 times	Имею предложение по небольшой доработке модуля экстраполей, сейчас имеется возможность в поле "Базовый HTML" прописать хтмл для формы - это замечательно. Но мне уже давно (со времён ЛДУ) не хватает возможности для каждого поля прописать и хтмл вывода результата. Допустим, что PAGE_EXTRA1 у нас должно выводить в теле страницы хтмл-ссылку. В форму PAGEADD_FORM_EXTRA1 мы вбили нужный адрес, но он не обработается на странице и выведется простым текстом, а нам нужна именно действующая ссылка вида <a href="{PAGE_EXTRA1}">НАША ССЫЛКА</a> Конечно можно обвес вбить прямо в шаблон. Но если поле PAGE_EXTRA1 будет не заполнено, то весь обвес останется, и на странице появится кривая ссылка вида <a href="">НАША ССЫЛКА</a> Это очень плохо. я привёл простой вариант с одинокой сылкой, но ведь в качестве обвеса могуть выступать целые блоки страницы и если бы мы могли их настраивать в админке, то было бы просто замечательно. А может этот функционал плагином возможно реализовать? Или напрямую в шаблоне? ---------------- Я тут подумал, и пришёл к выводу, что весь обвес должен быть всё же в шаблоне, но будет хорошо, если обвес будет заключен в специальные комментарии. Типа вот так: <!-- BEGIN: PAGE_EXTRA1 --> <a href="{PAGE_EXTRA1}">НАША ССЫЛКА</a> <!-- END: PAGE_EXTRA1 --> Причём, чтобы не усложнять без необходимости шаблон, стандартый вариант без комментариев тоже должен работать.
This post was edited by Sergeich (2009-02-11 16:38, 15 years ago)

Sergeich

#6 2009-02-11 16:05

Contributors
Thanked: 15 times

Имею предложение по небольшой доработке модуля экстраполей, сейчас имеется возможность в поле "Базовый HTML" прописать хтмл для формы - это замечательно. Но мне уже давно (со времён ЛДУ) не хватает возможности для каждого поля прописать и хтмл вывода результата.

Допустим, что PAGE_EXTRA1 у нас должно выводить в теле страницы хтмл-ссылку. В форму PAGEADD_FORM_EXTRA1 мы вбили нужный адрес, но он не обработается на странице и выведется простым текстом, а нам нужна именно действующая ссылка вида

<a href="{PAGE_EXTRA1}">НАША ССЫЛКА</a>

Конечно можно обвес вбить прямо в шаблон. Но если поле PAGE_EXTRA1 будет не заполнено, то весь обвес останется, и на странице появится кривая ссылка вида

<a href="">НАША ССЫЛКА</a>

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

А может этот функционал плагином возможно реализовать?
Или напрямую в шаблоне?

----------------
Я тут подумал, и пришёл к выводу, что весь обвес должен быть всё же в шаблоне, но будет хорошо, если обвес будет заключен в специальные комментарии. Типа вот так:

<!-- BEGIN: PAGE_EXTRA1 -->
<a href="{PAGE_EXTRA1}">НАША ССЫЛКА</a>
<!-- END: PAGE_EXTRA1 -->

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

This post was edited by Sergeich (2009-02-11 16:38, 15 years ago)

Trustmaster	#7 2009-02-11 17:58
Administrators Thanked: 263 times	Для экстраполей неплохой выход. Но в целом у нас с опциональностью тяжеловасто: приходится использовать кучу блоков. May the Source be with you!

esclkm	#8 2009-02-12 01:33
Team Thanked: 76 times	тяжело слишком тяжело - нужен нормальный иф littledev.ru - мой маленький зарождающийся блог о котонти. снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты

esclkm

#8 2009-02-12 01:33

Team
Thanked: 76 times

тяжело слишком тяжело - нужен нормальный иф

qdeez	#9 2011-01-29 23:34
Members	Ребята, подскажите : <!-- BEGIN: PAGE_EXTRA1 --> <a href="{PAGE_EXTRA1}">НАША ССЫЛКА</a> <!-- END: PAGE_EXTRA1 --> Так и не работает, а иф сделали?

Kort	#10 2011-01-30 00:19
Team Thanked: 188 times	Правильно так: <!-- IF {PAGE_EXTRA1} --> <a href="{PAGE_EXTRA1}">НАША ССЫЛКА</a> <!-- ENDIF --> SED.by - создание сайтов, разработка плагинов и тем для Котонти

qdeez	#11 2011-01-30 00:34
Members	Спасибо