Сабж.

Store может иметь некоторое состояние - отфильтрован или нет и т. п. Предположим, нужно вывести select для списка стран на нескольких вкладках, данные в который подгружаются с помощью JsonStore и соответвующих readerов.

Список стран во всех вкладках будет одинаковым, но, например, в зависимости от выбора в другом selectе нужно будет отфильтровать в первой вкладке по другому, нежели во второй.

Следовательно создать один store и использовать его во всех вкладках не получится. Создавать полностью отдельные store для каждой вкладки тоже не хочется - если откроется 5 вкладок, то информация по странам будет запрошена аяксом 5 раз вместо 1.

Есть ли в ExtJS хранилище кэшированных данных, которое можно передать store'у?

Яростный Меч,

нет, вкладки ExtJSа.

P. S. Способ с сохранением в переменную результатов AJAXа и подсовывания SimpleStore'у не рассматриваем. :)

Яростный МечИмеются в виду вкладки браузера (т.е. отдельные окна с точки зрения JS)?
Если очень грубо - имеем два JsonStore с одинаковым url. Надо подгрузить оба. Как это сделать за один запрос?

Яростный Меч,

копия не подойдет, она скопирует состояние первого JsonStore.

Нужна возможность создать новый JsonStore на основе тех же данных, на основе которых был создан первый JsonStore. Желательно, чтобы не пришлось во второй копировать данные из первого - тогда придется сообщать второму о первом, третьему о первом, что излишне. Или держать "прототип" - Store с общими данными в начальном состоянии.

Нужно что-то вроде объекта-сигнлтона (с lazy инициализацией), инкапсулирующего данные, который можно передать множеству store'ов. Вот этот самый объект-синглтон я знаю, как реализовать на чистом аяксе, сохранить просто возвращенный Json в переменную и все создаваемые store'ы сделать SimpleStore'ами и передавать им эту переменную.

Но может в ExtJS есть уже нечто готовое на этот счет? Не очень понимаю, что конкретно делают reader и proxy - есть подозрение, что proxy - оно и есть.

зы,

т. е. proxy и reader - это не это? reader инкапсулирует запрос данным, а proxy только их (если необходимо) трансформацию, но никто из них данные в себе as is не хранит?

зы,

т. е. proxy и reader - это не это? reader инкапсулирует запрос данным, а proxy только их (если необходимо) трансформацию, но никто из них данные в себе as is не хранит?

Сорри, даблпост.

yelena,

тогда надо сохранять их текущее состояние где-то, чтобы бы при переходе обратно, его восстановить.

Master4,

напишите пример сохранения и восстановления множества состояний ОДНОГО Store после многократного применения filter[By]. А мы почитаем, посмеемся.

yelenayelena, и вообще jsonData можно AJAX'сом запросить один раз
и создать несколько JsonStore для разных вкладок
и по факту загрузки jsonData сделать store.loadData(json, append); для каждого JsonStore
зы, у меня еще до вопроса на этом форуме был вариант, как предложила yelena в процитированном посте. От лени искал готового и/или более красивого решения. 10 февраля, после ваших ответов, так и реализовал - сделал синглтон, запрашивающий по аяксу данные с сервера, и отэкстендился от JsonStore для автоматической подвязки этого синглтона в виде загрузчика. Теперь большинство справочников так гружу.

Кстати, в прошлой и в этой теме забыл сказать - спасибо! :) И вам и yelena'е.

зы,

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

зы,

всмысле? Если хранилище самих данных обновляется, то все на него завязанные store'ы получают сообщение и подгружают данные из хранилища, если вы об этом.

Сложнее логику не вижу смысла реализовывать, пока это нужно только для справочников - а там ни сохранение, ни сортировка на стороне сервера, ни нечто другое пока не требуется. Только оптимизировать, чтобы один справочник сто раз не грузился.

ZeusTheTrueGod,

сейчас так и делается.