Last piece of the puzzle... the JSON store? [solved]

Hi,

I have my calendar working and I’m pretty happy with the result, although I need to do some tweaking on the CSS yet. See the attached screenshot.

The following happens:

- The manager/user navigates to the calendar tab and selects a property from a combo.
- After selection of a property a processor is kicked off which collects 4 rolling months from the calendar for that property. This is done via a MODx.Ajax.request

- The processor instantiates a calendar object with an HTML renderer and the renderer produces an HTML representation of the requested calendar months. This HTML representation is then returned to the browser via the reply object where it is dissected into 4 individual HTML strings, each representing a month. These strings are then placed into the individual months (each month is a separate MODx.panel).


Although this works, I consider the transport of the HTML string via the reply object a bit of a hack.

I’ve experimented a bit with a JSON store but could not get that to work.

So, my question: is it possible to introduce a JSON store for the above and if so, how would I go about doing that?

Thanks, and apologies for the really long post...

That’s a bit beyond what I’ve done with Stores, but I know that you can put basically any kind of flat data into a Ext.data.Store. You can see its methods here:

http://dev.sencha.com/deploy/ext-3.3.0/docs/?class=Ext.data.JsonStore

I’d look into creating Ext.data.Record objects for each row in your store, and then using JsonStore’s methods to access that data. And remember that you can extend any Ext.* class with Ext.extend(), so if you find yourself repeating code, just extend it.

Sorry I can’t give direct advice, but it seems like you’ve got a good grasp on your application - I think JsonStore could be your route.

Thanks for the advice. I did not know of the existence of Ext.data.Record. I’ll definitely check that out.

Quote from: splittingred at Oct 13, 2010, 07:04 PM

Sorry I can’t give direct advice, but it seems like you’ve got a good grasp on your application - I think JsonStore could be your route.

I replaced my MODx.Ajax.request with a JSON store, like so:


I adapted my processor PHP to encapsulate the HTML into data objects which then get JSON encoded with "months" as the root conforming to the JSON definition.

I know I can load the store with dstore.load(). I know the processor runs as I can see its trail in the logs.

But now: where’s the data gone? How do I get the data out of the store? Is it sitting somewhere in the DOM nodes?

Try this method :-

getRange( [Number startIndex], [Number endIndex] )
Returns a range of Records between specified indices.
Parameters:
startIndex : Number
(optional) The starting index (defaults to 0)
endIndex : Number
(optional) The ending index (defaults to the last Record in the Store)
Returns:
Ext.data.Record[]
An array of Records

from the ExtJS API site

Thanks for a quick response.

I’ll try that...

Right... or rather wrong... I must have been looking at old log entries as it appears that my store does not trigger the PHP routine that prepares its data:



The url in the above works out as: /modx/assets/components/tariffs/connector.php which is the url I use throughout the component for server access.

It’s my understanding that the baseParams config option adds ’mgr/calendar/getmonth’ as a parameter to the connector call. Which eventually triggers ’getmonth.php’.

While this worked for the MODx.Ajax.request, this doesn’t seem to do the trick for the JSON store.

Any suggestions?? Or am I missing the obvious?

The MODx.ajax.request is from modext, i.e its been configed to do what you’ve described above to construct a path to your php file, the datastore you are using is a straight Ext call , so you need to give it an absolute URL or do all the mangling yourself. Try hard coding the url straight to your backend processor and see what happens.

I tried that but it crashes as -presumably- some of the preparations done by the connector are bypassed....

Yes, the connector/processor mechanism used by the request handler does more than just a straight call to your processor, you’ll have to dummy this into the top of any processors you use directly like this presumably.