Vitaphoto: Ссылки — различия между версиями

Материал из YourcmcWiki
Перейти к: навигация, поиск
 
(не показано 15 промежуточных версий этого же участника)
Строка 1: Строка 1:
Ссылки в [[Vitaphoto]] теперь будут по именам — тегов и фотографий, а не по ID (альбомов и фотографий). Самих альбомов не останется вовсе: [[Vitaphoto: Облака тегов]].
+
Я против синтетических ключей! Ссылки в [[Vitaphoto]] теперь будут по именам — тегов и фотографий, а не по ID (альбомов и фотографий). Самих альбомов не останется вовсе: [[Vitaphoto: Облака тегов]].
  
<tab sep=bar class=tableborder1black head=left cellpadding=2>
+
== Ссылки и их значения ==
/Photo/01-0333 | Фото с именем «01-0333».
+
 
/Photo/Шышечки | Фото. Только для тех, у которых есть уникальная подпись, а не только имя.
+
<tab sep=bar class=simpletable head=left cellpadding=2>
/Photo/123 | Фото. Используется для тех, у которых нет уникального имени и нет уникальной подписи.
+
/Фото:01-0333 | Фото с именем «01-0333».
 +
/Фото:01-0333/ABFCH1827AB74CE31 | То же самое, но используется только для тех фотографий, у которых имя файла неуникально. Предполагается, что таких быть не должно.
 
/ | Все фотографии от более новых к более старым.
 
/ | Все фотографии от более новых к более старым.
/Природа/ | Фотографии с тегом «природа» от более новых к более старым.
+
/Природа | Фотографии с тегом «природа» от более новых к более старым.
/Киржач/природа/ | С тегами «Киржач» + «природа». Теги в наборе сортируются по алфавиту, ссылка всегда будет /Киржач/природа/, а не /природа/Киржач/.
+
/Киржач,природа/ | С тегами «Киржач» + «природа». Теги в наборе сортируются по алфавиту, ссылка всегда будет /Киржач,природа/, а не /природа,Киржач/.
/2009-10-11/ | Диапазон, в который попадает дата 2009-10-11 (так реализованы страницы).
+
/2009-10-11 | Диапазон, в который попадает дата 2009-10-11 (так реализованы страницы).
/2009-10-11/Киржач/ | Фотографии с тегом «Киржач», диапазон набора, в который попадает дата 2009-10-11 (так реализованы страницы). Дата всегда в начале, если дата не в начале — это не дата, а имя тега.
+
/Киржач/2009-10-11 | Фотографии с тегом «Киржач», диапазон набора, в который попадает дата 2009-10-11 (так реализованы страницы).
/Tag/спецтег/ | Специальный случай: теги «name», «photo», «tag», «pn», «tn», «special», «XXXX-XX-XX» (X — цифры) предваряются словом «tag», чтобы отличаться от специальных путей.
+
/_2009-10-11 | Специальный случай: теги вида «XXXX-XX-XX» (где X — цифры) предваряются подчёркиванием (пробелом), чтобы отличаться от выборки по дате.
 
/name/01-0333 | Обратная совместимость: редирект на /photo/01-0333
 
/name/01-0333 | Обратная совместимость: редирект на /photo/01-0333
 
/pn/01-0333 | Обратная совместимость: редирект на изображение среднего размера фотографии с именем «01-0333».
 
/pn/01-0333 | Обратная совместимость: редирект на изображение среднего размера фотографии с именем «01-0333».
 
/tn/01-0333 | Обратная совместимость: редирект на миниатюру фотографии с именем «01-0333».
 
/tn/01-0333 | Обратная совместимость: редирект на миниатюру фотографии с именем «01-0333».
/Special/ | Путь зарезервирован под прочие функциональные страницы.
+
/tag/хренпоймичто/ | Обратная совместимость: редирект на /хренпоймичто.
/Special/Большое_облако_тегов | &nbsp;
+
/Служебная: | Путь зарезервирован под прочие функциональные страницы.
/Special/Большое_облако | &nbsp;
+
/Служебная:БольшоеОблакоТегов | &nbsp;
/Special/bigcloud | &nbsp;
+
/Служебная:БольшоеОблако | &nbsp;
/Special/Big_tag_cloud | Вместе с предыдущими ведёт на «большое» облако тегов по абсолютно всем фотографиям.
+
/Служебная:BigCloud | &nbsp;
 +
/Служебная:BigTagCloud | Вместе с предыдущими ведёт на «большое» облако тегов по абсолютно всем фотографиям.
 +
/Служебная:JSON | Страница, отвечающая на JSON-запросы.
 
</tab>
 
</tab>
 
Все ссылки регистронезависимы. Пробелы в названиях заменяются на _ (символы подчёркивания). Первые буквы тегов в ссылках заменяются на заглавные. С «неправильных» ссылок отправляется постоянный ([[wikipedia:HTTP 301|HTTP 301 Moved Permanently]]) редирект на «правильные», чтобы и поисковики, и пользователи всегда попадали на правильные УРЛы.
 
Все ссылки регистронезависимы. Пробелы в названиях заменяются на _ (символы подчёркивания). Первые буквы тегов в ссылках заменяются на заглавные. С «неправильных» ссылок отправляется постоянный ([[wikipedia:HTTP 301|HTTP 301 Moved Permanently]]) редирект на «правильные», чтобы и поисковики, и пользователи всегда попадали на правильные УРЛы.
  
Специальные слова подвергаются локализации: «Special» = «Служебная», «Photo» = «Фото», «Tag» = «Метка».
+
Специальные слова подвергаются локализации: «Special» = «Служебная», «Photo» = «Фото», «Album» = «Альбом».
 +
 
 +
== Размышления о страницах и датах ==
 +
 
 +
Какие можно выделить подходы разбиения альбома на страницы:
 +
 
 +
===== Банальный (количественный) =====
 +
 
 +
Последовательность фотографий разбивается на отрезки фиксированного размера, последний из которых может быть меньше этого размера.
 +
 
 +
: <font color="#008000">'''плюс'''</font>: максимум простоты.
 +
: <font color="red">'''минус'''</font>: при добавлении фотографий меняются абсолютно все страницы альбома, то есть, ссылка — не уникальный идентификатор данных.
 +
: <font color="red">'''минус'''</font>: страница — «суррогатный ключ», может искусственно разбивать «желаемое» для просмотра множество фотографий посередине.
 +
: <font color="red">'''минус'''</font> (незначительный): при просмотре последних страниц просматривается всё множество фотографий, то есть запросы к первым страницам несколько легче, чем к последним. Но это некритично, так как нет здесь таких объёмов данных, на которых сканирование индекса приводит к хотя бы каким-нибудь проблемам.
 +
 
 +
===== По датам, одна дата на странице =====
 +
 
 +
: <font color="#008000">'''плюс'''</font>: простота.
 +
: <font color="#008000">'''плюс'''</font>: ссылка на набор фотографий не меняется со временем.
 +
: <font color="#008000">'''плюс'''</font>: все запросы к базе равнозначны и очень легки.
 +
: <font color="red">'''минус'''</font> (существенный!): фотографий за день может быть очень немного и страницы будут полупустые.
 +
 
 +
===== По датам, несколько дат на странице (минимум N фото) =====
 +
 
 +
Выбирается N фотографий, начиная с некоторой даты, и к этому множеству добавляются ещё не добавленные фотографии всех выбранных дат. Соответственно на главной странице несколько дат, начиная с наиболее новой, на следующей странице — следующие и т. п.
 +
 
 +
: <font color="#008000">'''плюс'''</font>: все запросы к базе равнозначны.
 +
: <font color="#008000">'''плюс'''</font>: нет «суррогатного ключа» — страницы.
 +
: <font color="red">'''минус'''</font>: ссылка на набор фотографий опять меняется со временем, опять со временем меняются многие (или все) страницы!
 +
 
 +
===== По датам, разбиение с начала истории =====
 +
 
 +
Аналогично предыдущему, но на страницы альбом разбивается не с начала отображения, а с начала истории (начиная с наиболее старых фотографий). Возникает проблема — на главной странице может оказаться мало фотографий. Она решается так: утверждаем, что главная страница будет содержать не одну последнюю страницу, а две последние, так как предпоследняя гарантированно будет полна.
 +
 
 +
: <font color="#008000">'''плюс'''</font>: нет «суррогатного ключа» — страницы.
 +
: <font color="#008000">'''плюс'''</font>: ссылка на набор не меняется со временем.
 +
: <font color="red">'''минус'''</font>: сложность. Требует разбиения ''каждого альбома целиком'' на страницы, а это либо некоторая нагрузка, либо нужен кэш, а кэш нужно инвалидировать, хотя бы при каждом обновлении…
 +
 
 +
===== Вывод =====
 +
 
 +
Либо не выпендриваться и делать классическое разбиение по количеству, либо выпендриваться по полной и делать разбиение по датам с начала истории с кэшированием и инвалидацией.
  
[[Категория:Разработка]]
+
[[Категория:Архив]]
 +
[[Категория:Sway]]

Текущая версия на 15:43, 20 июня 2016

Я против синтетических ключей! Ссылки в Vitaphoto теперь будут по именам — тегов и фотографий, а не по ID (альбомов и фотографий). Самих альбомов не останется вовсе: Vitaphoto: Облака тегов.

Ссылки и их значения

/Фото:01-0333 Фото с именем «01-0333».
/Фото:01-0333/ABFCH1827AB74CE31 То же самое, но используется только для тех фотографий, у которых имя файла неуникально. Предполагается, что таких быть не должно.
/ Все фотографии от более новых к более старым.
/Природа Фотографии с тегом «природа» от более новых к более старым.
/Киржач,природа/ С тегами «Киржач» + «природа». Теги в наборе сортируются по алфавиту, ссылка всегда будет /Киржач,природа/, а не /природа,Киржач/.
/2009-10-11 Диапазон, в который попадает дата 2009-10-11 (так реализованы страницы).
/Киржач/2009-10-11 Фотографии с тегом «Киржач», диапазон набора, в который попадает дата 2009-10-11 (так реализованы страницы).
/_2009-10-11 Специальный случай: теги вида «XXXX-XX-XX» (где X — цифры) предваряются подчёркиванием (пробелом), чтобы отличаться от выборки по дате.
/name/01-0333 Обратная совместимость: редирект на /photo/01-0333
/pn/01-0333 Обратная совместимость: редирект на изображение среднего размера фотографии с именем «01-0333».
/tn/01-0333 Обратная совместимость: редирект на миниатюру фотографии с именем «01-0333».
/tag/хренпоймичто/ Обратная совместимость: редирект на /хренпоймичто.
/Служебная: Путь зарезервирован под прочие функциональные страницы.
/Служебная:БольшоеОблакоТегов  
/Служебная:БольшоеОблако  
/Служебная:BigCloud  
/Служебная:BigTagCloud Вместе с предыдущими ведёт на «большое» облако тегов по абсолютно всем фотографиям.
/Служебная:JSON Страница, отвечающая на JSON-запросы.

Все ссылки регистронезависимы. Пробелы в названиях заменяются на _ (символы подчёркивания). Первые буквы тегов в ссылках заменяются на заглавные. С «неправильных» ссылок отправляется постоянный (HTTP 301 Moved Permanently) редирект на «правильные», чтобы и поисковики, и пользователи всегда попадали на правильные УРЛы.

Специальные слова подвергаются локализации: «Special» = «Служебная», «Photo» = «Фото», «Album» = «Альбом».

Размышления о страницах и датах

Какие можно выделить подходы разбиения альбома на страницы:

Банальный (количественный)

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

плюс: максимум простоты.
минус: при добавлении фотографий меняются абсолютно все страницы альбома, то есть, ссылка — не уникальный идентификатор данных.
минус: страница — «суррогатный ключ», может искусственно разбивать «желаемое» для просмотра множество фотографий посередине.
минус (незначительный): при просмотре последних страниц просматривается всё множество фотографий, то есть запросы к первым страницам несколько легче, чем к последним. Но это некритично, так как нет здесь таких объёмов данных, на которых сканирование индекса приводит к хотя бы каким-нибудь проблемам.
По датам, одна дата на странице
плюс: простота.
плюс: ссылка на набор фотографий не меняется со временем.
плюс: все запросы к базе равнозначны и очень легки.
минус (существенный!): фотографий за день может быть очень немного и страницы будут полупустые.
По датам, несколько дат на странице (минимум N фото)

Выбирается N фотографий, начиная с некоторой даты, и к этому множеству добавляются ещё не добавленные фотографии всех выбранных дат. Соответственно на главной странице несколько дат, начиная с наиболее новой, на следующей странице — следующие и т. п.

плюс: все запросы к базе равнозначны.
плюс: нет «суррогатного ключа» — страницы.
минус: ссылка на набор фотографий опять меняется со временем, опять со временем меняются многие (или все) страницы!
По датам, разбиение с начала истории

Аналогично предыдущему, но на страницы альбом разбивается не с начала отображения, а с начала истории (начиная с наиболее старых фотографий). Возникает проблема — на главной странице может оказаться мало фотографий. Она решается так: утверждаем, что главная страница будет содержать не одну последнюю страницу, а две последние, так как предпоследняя гарантированно будет полна.

плюс: нет «суррогатного ключа» — страницы.
плюс: ссылка на набор не меняется со временем.
минус: сложность. Требует разбиения каждого альбома целиком на страницы, а это либо некоторая нагрузка, либо нужен кэш, а кэш нужно инвалидировать, хотя бы при каждом обновлении…
Вывод

Либо не выпендриваться и делать классическое разбиение по количеству, либо выпендриваться по полной и делать разбиение по датам с начала истории с кэшированием и инвалидацией.