Деревья (в том числе, сетевые)

На мой взгляд, идеальным инструментом упорядочивания гиперссылок является Wiki-движок (для сравнительно небольших сайтов подойдёт DocuWiki, например). Готовых деревьев, там, правда, нет, но можно либо написать небольшое дополнение (в том числе, и на основе того скрипта, который вы выложили выше) или просто организовать страницы иерархически так, чтобы главная страница Wiki соответствовала корню, дальше создавались бы на Wiki создавались бы страницы промежуточных уровней, а с со страниц последнего уровня иерархии шли бы ссылки уже на внешние ресурсы или готовая информация.
Асинхронную загрузку отдельных сообщений делать нецелесообразно, если учесть, что сообщения могут редактироваться. Если учесть, что каждый запрос к HTTP серверу — это чуть меньше 1 Кб служебного траффика, то окажется, что если на станице 20 сообщений, то выгоднее проверять ее обновление целиком штатными средствами броузера и в случае необходимости перегружать ее целиком (как это сейчас сделано в IntB), чем проверять каждое сообщение в отдельности (для чего нужно писать дополнительный JavaScript, который тоже дает траффик, плюс это усложнит поисковую индексацию).

Пытался логически разделить Ваши мысли. Вот, что получилось:


Целесообразно. И даже необходимо. Причин для такого функционала могу напридумывать много... Вот, главные, которые обойти не получится:

1) Кроме служебного трафика есть контентный. И это намного больше 1кб/(на каждый пост), особенно, если с картинками.

2) "Лишние" сообщения отвлекают пользователя, уводят в сторону его мысли.

3) А если пост по структуре обсуждений связан с другими темами или даже с другими сайтами? В этом случае лишние посты из родной ветки — это уже 100% гарантия путаницы.

Например, из конкретной темы я могу надёргать в свою структуру десяток постов (в которых вся суть этой темы), и вывести их на одной странице. Удобно? Конечно! И, следовательно, нужна технология, позволяющая пользователям создавать такие структуры. Сервер за раз получит список постов (хоть из разных тем!), которые нужны пользователю, и отправит их в едином потоке (как одну страницу или, лучше, как архив файлов). Разбивку этой страницы на отдельные посты (с целью их кэширования или перекомпоновки) можно осуществить уже на компьютере пользователя.

Попутно решим и вопрос о количестве постов на страницу. Теперь это будет во власти пользователя: хоть сотня штук!

--

В следующем посте покажу, как исправить недоделанную систему адресов (насчитал три пункта для изменений).

Системы адресации на форумах
(этих возможностей здесь пока нет)
 

• 
  Система косвенной адресации. Проще говоря, сервис коротких ссылок (которые можно настраивать). Например, переместили вы пост из одной темы в другую. Что при этом произойдёт с прежней гипер-меткой?? Она изменится, и все ссылки на неё перестанут действовать.
   
  А теперь усложним систему адресации сообщений (и тем). На основании простой таблицы
   
  Всегда можно по внешней ссылке получить внутреннюю. Перемещая пост из темы в тему, модератор автоматически изменит в этой таблице внутреннюю ссылку [Объект2]. Также, внутреннюю ссылку можно автоматически менять при каждом редактировании поста. А в правом верхнем углу высвечивать внешнюю. Простой пользователь может вообще не догадываться, что у его постов есть внутренние ссылки.
   
  Но, всёже, дать ему возможность редактировать эту таблицу – полезно. Например,

1)      Меняя внешнюю метку [Объект1], можно запретить загрузку поста (или рисунка) по всем ссылкам, которые когда-либо были опубликованы (и переназначить на этот пост другие ссылки, с другого поста).

2)      Меняя внутреннюю ссылку [Объект2], можно переназначить существующие ссылки на другой пост (который может быть где угодно в Интернете).

3)      Одной внешней метке можно назначить несколько внутренних ссылок (то есть, несколько строчек в этой таблице связей. Таким способом, получаем механизм множественных ссылок: по внешней ссылке пользователь увидит не контент, а дерево ссылок:   (из которого уже можно перейти к просмотру конкретной информации).
Кстати, в http-адресе можно указывать, на каком из узлов дерева нужно сфокусироваться, и, одновременно, выделить (пометить) сразу несколько узлов (например, тематическую группу ссылок).

4)      Внутреннюю ссылку (в том числе, "пустышку" можно в новой строчке записывать на место внешней метки (то есть, в другой столбец этой таблицы). Таким способом получим механизм цепочек и папок. А это и есть материал для строительства деревьев (в том числе, сетевых, которые вообще никто ещё не научился строить, кроме простейших случаев…).
 

• 
  Множественные ссылки.
  Ну, то есть, нужен механизм прорисовки деревьев. В следующем посте расскажу (пока без рисунков), как его красиво интегрировать в сообщения форумов.

 

• 
  Метки на произвольные фрагменты html-текста.
  Частенько приходится ссылаться не на весь пост, а лишь на некоторые его фрагменты. И нужен скрипт, который сможет выделять эти фрагменты (или скрывать остальной, ненужный контент). Реализовать этот механизм "меток в чужих постах" можно так: спанить фрагменты сообщений особым классом "quote", и внутри таких спанов осуществлять текстовый поиск (или отступы по количеству символов). Вот такие фрагменты и показывать в особом виде.

Маленькие фреймы внутри поста    (возможно ли такое?)

   ... Настолько маленькие, что внутрь поместится лишь пиктограммка:   ()  У данного пользователя нет прав размещать ссылки!
FireFox позволяет из контекстного меню открыть этот фрейм в отдельном окне, тогда вместо этого рисуночка должно быть построено соответствующее дерево ссылок. Для страниц форума лучше это плавающее окошко открывать над аватарками, чтобы не загораживало текст сообщений.
 
В таком дереве достаточно кликнуть по узлу-ссылке, и она откроется в связанном окне.
Визуально выделяя определённый TreeView-узел, можно отобразить место соответствующего поста в конкретной структуре.
 
Открывать страницу фрейма в отдельном окошке (чтобы установить между окнами связь по гиперссылкам) – это будет одной из самых распространённых операций, и её научатся выполнять все броузеры. Конечно, возможны и другие веб-технологии. Но смысл их будет именно таким: по гиперссылкам связывать окна.

<-- intbpro.ru/plans/treeView/post-237.htm от 4X_Pro :

Мне он тоже нравится. Но до идеала ему далеко: не увидел ничего, что мне захотелось бы повторить. А поскольку с иерархически-сворачиваемыми списками работать пока не умеет, то предлагаю временно о нём забыть, и пойти простым путём: мне от Вас нужны две таблицы:

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

2.   ID поста (или рисунка) — гиперметка, по которой он доступен. Если эти поля принадлежат пользователю, то они, как и сообщения форума, должны быть доступны ему для редактирования.

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

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

<-- intbpro.ru/plans/treeView/post-237.htm от 4X_Pro :


В этой цитате есть шероховатости и непонятки… Например, узлы дерева – это не страницы (на которые те узлы ссылаются).

Любому узлу (если мы говорим именно об html-деревьях) могут соответствовать:
–  html-страница,
–  другой узел (родного или чужого дерева),
–  произвольный javascript

Или может вообще ничего не соответствовать: в этом случае такой узел просто выступит в роли папки.

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

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


Но шероховатости в обсуждении упорядоченных структур понять можно: даже разработчики броузеров с деревьями ссылок до сих пор толком не научились работать: как сделали неправильным сервис закладок, так и копируют эти глупости один у другого…
•  зачем-то метки вынесли из структуры дерева
•  самим папкам (в которых хранятся закладки) нельзя назначить ссылки
•  из закладки нельзя ссылаться на другой узел (в том числе, на папку)
•  метки закладок – это и есть папки! (неужели трудно было до этого додуматься лет двадцать назад??)
•  лучше дерево закладок сразу выводить в html-формате (чтобы пользователи могли нестандартно редактировать и обмениваться такими страничками)

assessor, рад, что ты теперь и тут!
_1_, по поводу меток: у меня несколько другие соображения: вместо одной уникальной метки (плюс еще средств для группирования сообщений по этим меткам) использовать обычные теги. Собственно говоря, библиотека для работы с ними в дистрибутиве уже есть, но изначально я планировал делать возможность ставить теги на темы, а не на отдельные сообщения, но технически разницы никакой нет, можно и на сообщения. В этом случае можно сообщению будет вешать несколько тегов, скажем, один уникальный, чтобы ссылаться только на это сообщение, остальные — теги групп, к которым это сообщение будет относиться.
Причем в этом случае оно будет без привязке к конкретной теме по URL (т.е. адрес будет вида /tags/имя_тега.htm или /tags/имя_тега/). Единственный недостаток этого решения — это кириллица в URL.

Зачем такое вообще может быть нужно?

Вроде во всех броузерах его можно экспортировать в HTML. Экспортируйте в локальный файл, повесьте его в качестве домашней страницы, и будет вам счастье. Кстати, возможность нестандартно редактировать практически не имеет смысла потому что файл будет перезаписываться при каждом добавлении новой закладки в броузер, и все сделанные вами изменения будут теряться.

Зачем такое вообще может быть нужно?

Вроде во всех броузерах его можно экспортировать в HTML. Экспортируйте в локальный файл, повесьте его в качестве домашней страницы, и будет вам счастье. Кстати, возможность нестандартно редактировать практически не имеет смысла потому что файл будет перезаписываться при каждом добавлении новой закладки в броузер, и все сделанные вами изменения будут теряться.