В плагине она и используется. Суть плагина в том, что к стандартному компоненту дерево Ext.tree.TreePanel прикручен другой стандартный компонент Ext.History — получилось дерево с историей.
возможно я сейчас глупость сморожу, но почему просто установку состояния не повесить на fn: это раз, два что будет с состоянием, если использовать сортировки и поиск по дереву? ведь я так понял у вас состояние записывается не кодом id-id-id как рекомендуют extjs а позициями в дереве?
При изменении состояния url соответственно меняется состояние дерева. На какое fn вы предлагаете повесить установку состояния?
Если позиции узлов дерева будут меняться, узлы будут удаляться/добавляться, то ссылки могут оказаться битыми.
Как уже писала, порядковые номера вместо idшников я решила использовать для краткости.
Но идею замены номеров на idшники — обдумаю :)
Тогда скорее так:
«stonejungle.net/extjs/ru/#{»historyTree":{«Group_A»:{},«Group_B»:{},«Quarterfinals»:{«First»:{},«Second»:{},«selected»:«Second»}}}»
Просто через "/" не получится: как тогда, например, показать, что в узле «Quarterfinals» раскрыты 2 узла — «First»и «Second» и выделен «Second».
А нам и не нужно этого показывать. Наоборот, дерево по идентификаторам определяет, что ему и как показывать.
Здесь жертвуем ненужной универсальностью и полностью базируем все на соглашениях (conventions).
Из "#/quarterfinals/final/x/" список всегда должен знать, что «x» — выбранный пункт, а два предыдущих — открыты. Индекс с идентификаторами загружается на страницу вместе с деревом. Можно индексировать как отдельные кусочки адреса (например, «final»), так и маршруты целиком.
Если пользователь только-только зашел на страницу, то ему вообще не нужны «открытые» еще и Group_A, и Group_B. И состояние не нужно хранить в адресной строке — его нужно хранить на сервере и можно загружать, скажем, асинхронно, с помощью JSON.
Если пользователь уже на странице, а само содержимое загружается асинхронно — то можете хранить состояние на самой странице (опять же — не в адресной строке), и на дереве это никак не отразится.
А если X — это не лист, то как по такому адресу понять, что X именно выбран, а не открыт?
Для хранения состояния дерева на сервере есть плагин от Saki.
В моем плагине смысл в том, что состояние хранится в URL: всегда можно дать кому-то ссылку на определенное состояние дерева и перейти Назад/Вперед по истории переходов по дереву.
«А если X — это не лист, то как по такому адресу понять, что X именно выбран, а не открыт?»
Простота — это всегда круто. Не усложняйте. Следуйте соглашениям опять же.
Если «x» — не лист, то он по-умолчанию и выбран и открыт, когда человек перешел по ссылке. К тому же, с точки зрения навигации, «папка» вполне может одновременно быть и какой-то «страницей» — то есть такой адрес вполне может содержать некоторый контент.
Просто вопрос в том, что вы хотите достичь — как по мне, лучше сделать просто и покрыть основные сценарии, чем усложнить все, сделав (зачем-то) передачу состояния через ссылку, что на практике если и будет использовано — то очень редко.
1. URL более красивый хотелось бы, либо тогда заенкодить его, чтобы просто уникальный был. JSON пугает.
2. JsLint Вам в помощь — меолчь, а неприятно:
if(this.encodeValue(newState) == "")
this.fireEvent('statechange', this, "", newState);
else
for (element in newState)
if (this.encodeValue(newState[element]) != this.encodeValue(previousState[element]))
this.fireEvent('statechange', this, element, newState[element]);
Зачем лицензия GPL? Для таких вещей самое то использовать BSD.
Прикольно конечно, но не вижу практической ценности. Плюс к тому такие вещи намного легче поддерживать, если они лежат на гитхабе или гуглкоде, в плане контроля версий и в плане фидбека.
Плагин Ext.ux.HistoryTree — дерево с историей