cotonti.com : редактор полей для страниц https://www.cotonti.com Останні повідомлення в темі Cotonti en Mon, 12 Jan 2026 02:38:36 -0000 qdeez Нд, 30 Січ 2011 00:34:25 -0000 Kort <!-- IF {PAGE_EXTRA1} --> <a href=https://www.cotonti.com/"{PAGE_EXTRA1}">НАША ССЫЛКА</a> <!-- ENDIF -->]]> Нд, 30 Січ 2011 00:19:52 -0000 qdeez
<!-- BEGIN: PAGE_EXTRA1 -->
<a href=https://www.cotonti.com/"{PAGE_EXTRA1}">НАША ССЫЛКА</a>
<!-- END: PAGE_EXTRA1 -->

Так и не работает, а иф сделали?]]>
Сб, 29 Січ 2011 23:34:59 -0000
esclkm Thu, 12 Лют 2009 01:33:35 -0000 Trustmaster Ср, 11 Лют 2009 17:58:39 -0000 Sergeich
Допустим, что PAGE_EXTRA1 у нас должно выводить в теле страницы хтмл-ссылку. В форму PAGEADD_FORM_EXTRA1 мы вбили нужный адрес, но он не обработается на странице и выведется простым текстом, а нам нужна именно действующая ссылка вида

<a href=https://www.cotonti.com/"{PAGE_EXTRA1}">НАША ССЫЛКА</a>

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

<a href=https://www.cotonti.com/"">НАША ССЫЛКА</a>

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

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

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

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

Причём, чтобы не усложнять без необходимости шаблон, стандартый вариант без комментариев тоже должен работать.]]>
Ср, 11 Лют 2009 16:05:39 -0000
Trustmaster
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 ей редко следуют строго, чтобы сократить количество коррелированных запросов за счет введения избыточности данных.]]>
Пт, 19 Гру 2008 00:43:18 -0000
esclkm подобъединю мысли медара 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. В имени данного экстра поля должна быть проверка, чтобы там присутствовали только англ сиволы и цифры, а остальные просто урезались

В итоге такой будет фридом на нашей поляне! как вы считаете?]]>
Thu, 18 Гру 2008 23:14:20 -0000
Trustmaster
3-4. Согласен, для совместимости оставим.]]>
Thu, 18 Гру 2008 17:55:20 -0000
medar
1. Я не юзаю в своих сайтах форум, поэтому не знаю, что ему нужно. Там разве тоже нужны дополнительные поля ? Они же вроде нужны для pages и users только.

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

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

3-4. Пусть будут имеющиеся дополнительные поля. Дополнительной нагрузки на БД это не создаст, а плагины у народа посыпятся, если их удалить.]]>
Thu, 18 Гру 2008 17:30:32 -0000
esclkm
но:
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...) - но если мы хорошо докуметируем как избежать несовместимости то все будет окейно.

Интересно ваше мнение, если отошел от общей концепции разработки прошу простить.]]>
Thu, 18 Гру 2008 05:59:04 -0000