data store
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
data store
by Vance Dubberly
::
Rate this Message:
It would seem like a really simple thing. Use a filtering select
list. Or any select type with an object of the form pageJSON = { identifier : 'id', items : [ { id : 'a', label: "Letter A" }, { id : 'b', label: "Letter B" }, { id : 'c', label: "Letter C" }, { id : 'd', label: "Letter D" } ] } and it is if I have that object serialized on a server as a text file... but for the life of me I can not figure out how to do this really simple thing without going through the process of writing my own data store, which appears to be an long process for which I simply do not have time at this juncture. I've got to be missing something amazingly obvious. Please help. Pretty please. ;) Vance -- To pretend, I actually do the thing: I have therefore only pretended to pretend. - Jacques Derrida _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://dojotoolkit.org/docs/book Forums: http://dojotoolkit.org/forum Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: data store
by jaredj
::
Rate this Message:
I'm not following on what you are trying to do here. Can you be a
little more descriptive on your problem, other than not wanting to write your own datastore? How are you wanting to get the data? ItemFile*Store doesn't require the end point be an actual file, it could just as readily be a service, such as a PHP script or a servlet. The only thing ItemFile*Store requires is the format of the returned data match its expectations. There are many other datastores available in dojox as well, such as QueryReadStore, which expects to talk to a back end service (which is mimic'ed in a simple php file for testing purposes). So, what exactly are you trying to do and what do you want your data source to be? Sincerely, -- Jared Jurkiewicz On Dec 10, 2007 1:43 AM, Vance Dubberly <altjeringa@...> wrote: > It would seem like a really simple thing. Use a filtering select > list. Or any select type with an object of the form > > pageJSON = { > identifier : 'id', > items : [ > { id : 'a', label: "Letter A" }, > { id : 'b', label: "Letter B" }, > { id : 'c', label: "Letter C" }, > { id : 'd', label: "Letter D" } > ] > } > > and it is if I have that object serialized on a server as a text > file... but for the life of me I can not figure out how to do this > really simple thing without going through the process of writing my > own data store, which appears to be an long process for which I simply > do not have time at this juncture. > > I've got to be missing something amazingly obvious. Please help. > Pretty please. ;) > > Vance > > > > -- > To pretend, I actually do the thing: I have therefore only pretended to pretend. > - Jacques Derrida > _______________________________________________ > FAQ: http://dojotoolkit.org/support/faq > Book: http://dojotoolkit.org/docs/book > Forums: http://dojotoolkit.org/forum > Dojo-interest@... > http://dojotoolkit.org/mailman/listinfo/dojo-interest > FAQ: http://dojotoolkit.org/support/faq Book: http://dojotoolkit.org/docs/book Forums: http://dojotoolkit.org/forum Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: data store
by Vance Dubberly
::
Rate this Message:
Jared,
Thanks for the response. What I want to to populate a dijit.form.FilteringSelect with an object of the form pageJSON = { identifier : 'id', items : [ { id : 'a', label: "Letter A" }, { id : 'b', label: "Letter B" }, { id : 'c', label: "Letter C" }, { id : 'd', label: "Letter D" } ] } Honestly I don't want to use a datastore to do it. Seems like a complete waste of memory and CPU. However not using a datastore does not appear to be an option. So baring that, I want to populate a datastore with the above object without having to read it from the server. I already have the data it was pulled from the server in a much more complex format and is being used for may things. the above sample is a derived subset of that data. what I'd love to do is this: dijit.form.FiteringSelect.store = pageJSON; baring that I'd like to do this: store = new dojo.data.SomeKindOfStore( pageJSON ) dijit.form.FilteringSelect.store = store; What I don't want to do is go to the server for data I already have. Any advice or direction ( god knows i'm completely spun around at this point ) would be greatly appreciated. Vance On Dec 11, 2007 9:04 AM, Jared Jurkiewicz <jared.jurkiewicz@...> wrote: > I'm not following on what you are trying to do here. Can you be a > little more descriptive on your problem, other than not wanting to > write your own datastore? How are you wanting to get the data? > ItemFile*Store doesn't require the end point be an actual file, it > could just as readily be a service, such as a PHP script or a servlet. > The only thing ItemFile*Store requires is the format of the returned > data match its expectations. There are many other datastores > available in dojox as well, such as QueryReadStore, which expects to > talk to a back end service (which is mimic'ed in a simple php file for > testing purposes). So, what exactly are you trying to do and what do > you want your data source to be? > > Sincerely, > -- Jared Jurkiewicz > > > On Dec 10, 2007 1:43 AM, Vance Dubberly <altjeringa@...> wrote: > > It would seem like a really simple thing. Use a filtering select > > list. Or any select type with an object of the form > > > > pageJSON = { > > identifier : 'id', > > items : [ > > { id : 'a', label: "Letter A" }, > > { id : 'b', label: "Letter B" }, > > { id : 'c', label: "Letter C" }, > > { id : 'd', label: "Letter D" } > > ] > > } > > > > and it is if I have that object serialized on a server as a text > > file... but for the life of me I can not figure out how to do this > > really simple thing without going through the process of writing my > > own data store, which appears to be an long process for which I simply > > do not have time at this juncture. > > > > I've got to be missing something amazingly obvious. Please help. > > Pretty please. ;) > > > > Vance > > > > > > > > -- > > To pretend, I actually do the thing: I have therefore only pretended to pretend. > > - Jacques Derrida > > _______________________________________________ > > FAQ: http://dojotoolkit.org/support/faq > > Book: http://dojotoolkit.org/docs/book > > Forums: http://dojotoolkit.org/forum > > Dojo-interest@... > > http://dojotoolkit.org/mailman/listinfo/dojo-interest > > > _______________________________________________ > FAQ: http://dojotoolkit.org/support/faq > Book: http://dojotoolkit.org/docs/book > Forums: http://dojotoolkit.org/forum > Dojo-interest@... > http://dojotoolkit.org/mailman/listinfo/dojo-interest > -- To pretend, I actually do the thing: I have therefore only pretended to pretend. - Jacques Derrida _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://dojotoolkit.org/docs/book Forums: http://dojotoolkit.org/forum Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: data store
by Dustin Machi-2
::
Rate this Message:
I agree that lots of work still needs to be done on making use of stores
easier and more robust. Right now it can be too difficult to use in what are simple case. However... > Honestly I don't want to use a datastore to do it. Seems like a > complete waste of memory and CPU. The fact is regardless of whether or not you have to declare a store or even if a widget actually uses something called a store, you are using one. This doesn't necessarily mean a dojo.data store, but every widget that visualizes some data set must be able to have access to a data set that it understands how to access and view and potentially to manipulate as well. In the previous versions of dojo each widget handled its data on its own. This of course led to problems that the particular data set that they knew how to manage didn't quite match up with what the user needed or wanted. Or they needed to be retrieved from the server in a lazy loaded way. Or lazy loading work, but not in the way that a particular dev needed it to work. dojo.data does nothing more than split that functionality outside of the widget so stores could be defined in some standard way that lets the developers write whatever code they might like to access their server data, but still provides widgets a common interface so they don't have to be rewritten, extended or whatever with each new use case. Now, bugs aside and not withstanding some adjustments that might be needed to the dojo.data api's themselves, using stores should ultimately reduce the number of instances of a piece of data because one store can be used by multiple widgets. It ultimately also requires less widget code to be written and downloaded. > However not using a datastore does > not appear to be an option. Actually in some cases this is already the case, but as mentioned above is only illusory. For example, the combobox widget can take normal <option> tags as children. However what happens in reality is that the widget will then ingest that data and create the store on its own. Having capabilities like this available across the full set of widgets that use dojo data would go along way towards making some of the simple cases simpler. ( *on a side note for lurkers: I would say however that widgets that do this should not automatically dojo.require() the store type they want to use as you then have to get that code/store even if you don't want to use it and that can be expensive. I would prefer it to just throw an error if you tried to use a widget in this way and hadn't included an appropriate store. It would also be preferable to allow usage like this to specify which type of store would be created by default, though this might not be practical in some circumstances. Doing this allow automatic creation, but if the rest of the app is using a different store type, it doesn't require that store to be loaded.) So baring that, I want to populate a > datastore with the above object without having to read it from the > server. I already have the data it was pulled from the server in a > much more complex format and is being used for may things. the above > sample is a derived subset of that data. > > what I'd love to do is this: > > dijit.form.FiteringSelect.store = pageJSON; > This won't work because that is passing a js object in and the filtering select would be expecting that to be a store instance, not a js object. > baring that I'd like to do this: > > store = new dojo.data.SomeKindOfStore( pageJSON ) > dijit.form.FilteringSelect.store = store; > This in general is correct, however i think in practical terms that right now most data using widgets expect to have a store at creation time. So your stores would need to be created before the widget was instantiate. > What I don't want to do is go to the server for data I already have. > You don't have to go to the server for the data you already have. ItemFileReadStore takes a set of data, formatted in its special way, and makes it available locally. You could create your stores right at the beginning of your app for example (not in addOnLoad() and before the <body>) and that store could be avialable to anything you either markup or programmatically create later. Dustin _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://dojotoolkit.org/docs/book Forums: http://dojotoolkit.org/forum Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: data store
by Vance Dubberly
::
Rate this Message:
Dustin,
I really do appreciate the explanation of data stores it is both insightful and honest. Understanding the philosophy of why a thing is architected the way it is goes a long way toward making it work and it sounds like the theory is good, even if the implementation is lacking. The downside of course is that I'm still left writing my own datastore as at least instantiating dojo.data.ItemFileReadStore with the aforementioned JSON results in a data store with no data. :( I do think I've a new Tagline for dojo. "Making the complex, attainable and the simple impossible." :) ( wasn't the Java credo for a long time? ) I can do things with dojo I never thought possible and yet the simple stuff leaves me totally screwed. Anyway I gave up and just used an old fashioned select box. Looks like crap but it does the job. Vance On Dec 13, 2007 1:17 PM, Dustin Machi <dmachi@...> wrote: > I agree that lots of work still needs to be done on making use of stores > easier and more robust. Right now it can be too difficult to use in > what are simple case. However... > > > Honestly I don't want to use a datastore to do it. Seems like a > > complete waste of memory and CPU. > > The fact is regardless of whether or not you have to declare a store or > even if a widget actually uses something called a store, you are using > one. This doesn't necessarily mean a dojo.data store, but every widget > that visualizes some data set must be able to have access to a data set > that it understands how to access and view and potentially to manipulate > as well. > > In the previous versions of dojo each widget handled its data on its > own. This of course led to problems that the particular data set that > they knew how to manage didn't quite match up with what the user needed > or wanted. Or they needed to be retrieved from the server in a lazy > loaded way. Or lazy loading work, but not in the way that a particular > dev needed it to work. dojo.data does nothing more than split that > functionality outside of the widget so stores could be defined in some > standard way that lets the developers write whatever code they might > like to access their server data, but still provides widgets a common > interface so they don't have to be rewritten, extended or whatever with > each new use case. > > Now, bugs aside and not withstanding some adjustments that might be > needed to the dojo.data api's themselves, using stores should ultimately > reduce the number of instances of a piece of data because one store can > be used by multiple widgets. It ultimately also requires less widget > code to be written and downloaded. > > > However not using a datastore does > > not appear to be an option. > > Actually in some cases this is already the case, but as mentioned above > is only illusory. For example, the combobox widget can take normal > <option> tags as children. However what happens in reality is that the > widget will then ingest that data and create the store on its own. > Having capabilities like this available across the full set of widgets > that use dojo data would go along way towards making some of the simple > cases simpler. ( > > *on a side note for lurkers: I would say however that widgets that do > this should not automatically dojo.require() the store type they want to > use as you then have to get that code/store even if you don't want to > use it and that can be expensive. I would prefer it to just throw an > error if you tried to use a widget in this way and hadn't included an > appropriate store. It would also be preferable to allow usage like this > to specify which type of store would be created by default, though this > might not be practical in some circumstances. Doing this allow > automatic creation, but if the rest of the app is using a different > store type, it doesn't require that store to be loaded.) > > So baring that, I want to populate a > > datastore with the above object without having to read it from the > > server. I already have the data it was pulled from the server in a > > much more complex format and is being used for may things. the above > > sample is a derived subset of that data. > > > > what I'd love to do is this: > > > > dijit.form.FiteringSelect.store = pageJSON; > > > > This won't work because that is passing a js object in and the filtering > select would be expecting that to be a store instance, not a js object. > > > baring that I'd like to do this: > > > > store = new dojo.data.SomeKindOfStore( pageJSON ) > > dijit.form.FilteringSelect.store = store; > > > > This in general is correct, however i think in practical terms that > right now most data using widgets expect to have a store at creation > time. So your stores would need to be created before the widget was > instantiate. > > > What I don't want to do is go to the server for data I already have. > > > You don't have to go to the server for the data you already have. > ItemFileReadStore takes a set of data, formatted in its special way, and > makes it available locally. You could create your stores right at the > beginning of your app for example (not in addOnLoad() and before the > <body>) and that store could be avialable to anything you either markup > or programmatically create later. > > > Dustin > > > _______________________________________________ > FAQ: http://dojotoolkit.org/support/faq > Book: http://dojotoolkit.org/docs/book > Forums: http://dojotoolkit.org/forum > Dojo-interest@... > http://dojotoolkit.org/mailman/listinfo/dojo-interest > -- To pretend, I actually do the thing: I have therefore only pretended to pretend. - Jacques Derrida _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://dojotoolkit.org/docs/book Forums: http://dojotoolkit.org/forum Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: data store
by Jon Sykes-4
::
Rate this Message:
Vance try:
var data = {data: { identifier : 'id', items : [ { id : 'a', label: "Letter A" }, { id : 'b', label: "Letter B" }, { id : 'c', label: "Letter C" }, { id : 'd', label: "Letter D" } ] }; var myNewStore=new dojo.data.ItemFileReadStore(data); See how that handles it. On Dec 13, 2007, at 5:00 PM, Vance Dubberly wrote: > Dustin, > I really do appreciate the explanation of data stores it is both > insightful and honest. Understanding the philosophy of why a thing is > architected the way it is goes a long way toward making it work and it > sounds like the theory is good, even if the implementation is lacking. > > The downside of course is that I'm still left writing my own > datastore as at least instantiating dojo.data.ItemFileReadStore with > the aforementioned JSON results in a data store with no data. :( > > I do think I've a new Tagline for dojo. "Making the complex, > attainable and the simple impossible." :) ( wasn't the Java credo for > a long time? ) I can do things with dojo I never thought possible and > yet the simple stuff leaves me totally screwed. > > Anyway I gave up and just used an old fashioned select box. Looks > like crap but it does the job. > > Vance > > > > > > > On Dec 13, 2007 1:17 PM, Dustin Machi <dmachi@...> wrote: >> I agree that lots of work still needs to be done on making use of >> stores >> easier and more robust. Right now it can be too difficult to use in >> what are simple case. However... >> >>> Honestly I don't want to use a datastore to do it. Seems like a >>> complete waste of memory and CPU. >> >> The fact is regardless of whether or not you have to declare a >> store or >> even if a widget actually uses something called a store, you are >> using >> one. This doesn't necessarily mean a dojo.data store, but every >> widget >> that visualizes some data set must be able to have access to a data >> set >> that it understands how to access and view and potentially to >> manipulate >> as well. >> >> In the previous versions of dojo each widget handled its data on its >> own. This of course led to problems that the particular data set >> that >> they knew how to manage didn't quite match up with what the user >> needed >> or wanted. Or they needed to be retrieved from the server in a lazy >> loaded way. Or lazy loading work, but not in the way that a >> particular >> dev needed it to work. dojo.data does nothing more than split that >> functionality outside of the widget so stores could be defined in >> some >> standard way that lets the developers write whatever code they might >> like to access their server data, but still provides widgets a common >> interface so they don't have to be rewritten, extended or whatever >> with >> each new use case. >> >> Now, bugs aside and not withstanding some adjustments that might be >> needed to the dojo.data api's themselves, using stores should >> ultimately >> reduce the number of instances of a piece of data because one store >> can >> be used by multiple widgets. It ultimately also requires less widget >> code to be written and downloaded. >> >>> However not using a datastore does >>> not appear to be an option. >> >> Actually in some cases this is already the case, but as mentioned >> above >> is only illusory. For example, the combobox widget can take normal >> <option> tags as children. However what happens in reality is that >> the >> widget will then ingest that data and create the store on its own. >> Having capabilities like this available across the full set of >> widgets >> that use dojo data would go along way towards making some of the >> simple >> cases simpler. ( >> >> *on a side note for lurkers: I would say however that widgets that do >> this should not automatically dojo.require() the store type they >> want to >> use as you then have to get that code/store even if you don't want to >> use it and that can be expensive. I would prefer it to just throw an >> error if you tried to use a widget in this way and hadn't included an >> appropriate store. It would also be preferable to allow usage like >> this >> to specify which type of store would be created by default, though >> this >> might not be practical in some circumstances. Doing this allow >> automatic creation, but if the rest of the app is using a different >> store type, it doesn't require that store to be loaded.) >> >> So baring that, I want to populate a >>> datastore with the above object without having to read it from the >>> server. I already have the data it was pulled from the server in a >>> much more complex format and is being used for may things. the above >>> sample is a derived subset of that data. >>> >>> what I'd love to do is this: >>> >>> dijit.form.FiteringSelect.store = pageJSON; >>> >> >> This won't work because that is passing a js object in and the >> filtering >> select would be expecting that to be a store instance, not a js >> object. >> >>> baring that I'd like to do this: >>> >>> store = new dojo.data.SomeKindOfStore( pageJSON ) >>> dijit.form.FilteringSelect.store = store; >>> >> >> This in general is correct, however i think in practical terms that >> right now most data using widgets expect to have a store at creation >> time. So your stores would need to be created before the widget was >> instantiate. >> >>> What I don't want to do is go to the server for data I already have. >>> >> You don't have to go to the server for the data you already have. >> ItemFileReadStore takes a set of data, formatted in its special >> way, and >> makes it available locally. You could create your stores right at >> the >> beginning of your app for example (not in addOnLoad() and before the >> <body>) and that store could be avialable to anything you either >> markup >> or programmatically create later. >> >> >> Dustin >> >> >> _______________________________________________ >> FAQ: http://dojotoolkit.org/support/faq >> Book: http://dojotoolkit.org/docs/book >> Forums: http://dojotoolkit.org/forum >> Dojo-interest@... >> http://dojotoolkit.org/mailman/listinfo/dojo-interest >> > > > > -- > To pretend, I actually do the thing: I have therefore only pretended > to pretend. > - Jacques Derrida > _______________________________________________ > FAQ: http://dojotoolkit.org/support/faq > Book: http://dojotoolkit.org/docs/book > Forums: http://dojotoolkit.org/forum > Dojo-interest@... > http://dojotoolkit.org/mailman/listinfo/dojo-interest _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://dojotoolkit.org/docs/book Forums: http://dojotoolkit.org/forum Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: data store
by Vance Dubberly
::
Rate this Message:
Jon,
Thank you so very much! Woo Hoo!!! Vance On Dec 13, 2007 2:05 PM, Jon Sykes <lists@...> wrote: > Vance try: > > var data = {data: { > identifier : 'id', > items : [ > { id : 'a', label: "Letter A" }, > { id : 'b', label: "Letter B" }, > { id : 'c', label: "Letter C" }, > { id : 'd', label: "Letter D" } > ] > }; > > var myNewStore=new dojo.data.ItemFileReadStore(data); > > See how that handles it. > > > > On Dec 13, 2007, at 5:00 PM, Vance Dubberly wrote: > > > Dustin, > > I really do appreciate the explanation of data stores it is both > > insightful and honest. Understanding the philosophy of why a thing is > > architected the way it is goes a long way toward making it work and it > > sounds like the theory is good, even if the implementation is lacking. > > > > The downside of course is that I'm still left writing my own > > datastore as at least instantiating dojo.data.ItemFileReadStore with > > the aforementioned JSON results in a data store with no data. :( > > > > I do think I've a new Tagline for dojo. "Making the complex, > > attainable and the simple impossible." :) ( wasn't the Java credo for > > a long time? ) I can do things with dojo I never thought possible and > > yet the simple stuff leaves me totally screwed. > > > > Anyway I gave up and just used an old fashioned select box. Looks > > like crap but it does the job. > > > > Vance > > > > > > > > > > > > > > On Dec 13, 2007 1:17 PM, Dustin Machi <dmachi@...> wrote: > >> I agree that lots of work still needs to be done on making use of > >> stores > >> easier and more robust. Right now it can be too difficult to use in > >> what are simple case. However... > >> > >>> Honestly I don't want to use a datastore to do it. Seems like a > >>> complete waste of memory and CPU. > >> > >> The fact is regardless of whether or not you have to declare a > >> store or > >> even if a widget actually uses something called a store, you are > >> using > >> one. This doesn't necessarily mean a dojo.data store, but every > >> widget > >> that visualizes some data set must be able to have access to a data > >> set > >> that it understands how to access and view and potentially to > >> manipulate > >> as well. > >> > >> In the previous versions of dojo each widget handled its data on its > >> own. This of course led to problems that the particular data set > >> that > >> they knew how to manage didn't quite match up with what the user > >> needed > >> or wanted. Or they needed to be retrieved from the server in a lazy > >> loaded way. Or lazy loading work, but not in the way that a > >> particular > >> dev needed it to work. dojo.data does nothing more than split that > >> functionality outside of the widget so stores could be defined in > >> some > >> standard way that lets the developers write whatever code they might > >> like to access their server data, but still provides widgets a common > >> interface so they don't have to be rewritten, extended or whatever > >> with > >> each new use case. > >> > >> Now, bugs aside and not withstanding some adjustments that might be > >> needed to the dojo.data api's themselves, using stores should > >> ultimately > >> reduce the number of instances of a piece of data because one store > >> can > >> be used by multiple widgets. It ultimately also requires less widget > >> code to be written and downloaded. > >> > >>> However not using a datastore does > >>> not appear to be an option. > >> > >> Actually in some cases this is already the case, but as mentioned > >> above > >> is only illusory. For example, the combobox widget can take normal > >> <option> tags as children. However what happens in reality is that > >> the > >> widget will then ingest that data and create the store on its own. > >> Having capabilities like this available across the full set of > >> widgets > >> that use dojo data would go along way towards making some of the > >> simple > >> cases simpler. ( > >> > >> *on a side note for lurkers: I would say however that widgets that do > >> this should not automatically dojo.require() the store type they > >> want to > >> use as you then have to get that code/store even if you don't want to > >> use it and that can be expensive. I would prefer it to just throw an > >> error if you tried to use a widget in this way and hadn't included an > >> appropriate store. It would also be preferable to allow usage like > >> this > >> to specify which type of store would be created by default, though > >> this > >> might not be practical in some circumstances. Doing this allow > >> automatic creation, but if the rest of the app is using a different > >> store type, it doesn't require that store to be loaded.) > >> > >> So baring that, I want to populate a > >>> datastore with the above object without having to read it from the > >>> server. I already have the data it was pulled from the server in a > >>> much more complex format and is being used for may things. the above > >>> sample is a derived subset of that data. > >>> > >>> what I'd love to do is this: > >>> > >>> dijit.form.FiteringSelect.store = pageJSON; > >>> > >> > >> This won't work because that is passing a js object in and the > >> filtering > >> select would be expecting that to be a store instance, not a js > >> object. > >> > >>> baring that I'd like to do this: > >>> > >>> store = new dojo.data.SomeKindOfStore( pageJSON ) > >>> dijit.form.FilteringSelect.store = store; > >>> > >> > >> This in general is correct, however i think in practical terms that > >> right now most data using widgets expect to have a store at creation > >> time. So your stores would need to be created before the widget was > >> instantiate. > >> > >>> What I don't want to do is go to the server for data I already have. > >>> > >> You don't have to go to the server for the data you already have. > >> ItemFileReadStore takes a set of data, formatted in its special > >> way, and > >> makes it available locally. You could create your stores right at > >> the > >> beginning of your app for example (not in addOnLoad() and before the > >> <body>) and that store could be avialable to anything you either > >> markup > >> or programmatically create later. > >> > >> > >> Dustin > >> > >> > >> _______________________________________________ > >> FAQ: http://dojotoolkit.org/support/faq > >> Book: http://dojotoolkit.org/docs/book > >> Forums: http://dojotoolkit.org/forum > >> Dojo-interest@... > >> http://dojotoolkit.org/mailman/listinfo/dojo-interest > >> > > > > > > > > -- > > To pretend, I actually do the thing: I have therefore only pretended > > to pretend. > > - Jacques Derrida > > _______________________________________________ > > FAQ: http://dojotoolkit.org/support/faq > > Book: http://dojotoolkit.org/docs/book > > Forums: http://dojotoolkit.org/forum > > Dojo-interest@... > > http://dojotoolkit.org/mailman/listinfo/dojo-interest > > _______________________________________________ > FAQ: http://dojotoolkit.org/support/faq > Book: http://dojotoolkit.org/docs/book > Forums: http://dojotoolkit.org/forum > Dojo-interest@... > http://dojotoolkit.org/mailman/listinfo/dojo-interest > -- To pretend, I actually do the thing: I have therefore only pretended to pretend. - Jacques Derrida _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://dojotoolkit.org/docs/book Forums: http://dojotoolkit.org/forum Dojo-interest@... http://dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: data store
by pcarmichael
::
Rate this Message:
This is exactly what I was wanting to do too :-)
I just tried it with Dojo 1.0.2, and it doesn't work for me. I might be missing something in the rest of the code. Would you mind posting the complete code, so I try your version? > > var data = {data: { > identifier : 'id', > items : [ > { id : 'a', label: "Letter A" }, > { id : 'b', label: "Letter B" }, > { id : 'c', label: "Letter C" }, > { id : 'd', label: "Letter D" } > ] > }; > > var myNewStore=new dojo.data.ItemFileReadStore(data); > > See how that handles it. |
|
|
Re: data store
by jaredj
::
Rate this Message:
How exactly are you instantiating it? I have this working fine in a test file. My guess is you may not be taking into account Dojo's asynchronous nature. dojo.require() is an async call, it invokes xhr under normal conditions. Because of that nature, any code that is going to use dojo apis should be put into a function passed to the dojo.addOnLoad() call. Here's the example I have that works fine for me:
<html> <head> <title>Test of data loading ItemFileReadStore</title> <style type="text/css"> @import "dijit/themes/tundra/tundra.css"; @import "dojo/resources/dojo.css"; @import "dijit/tests/css/dijitTests.css"; </style> <script type="text/javascript" src="dojo/dojo.js" djConfig="isDebug: true, parseOnLoad: true, usePlainJson: true"></script> <script type="text/javascript"> dojo.require("dojo.data.ItemFileReadStore"); function init(){ var imgCtx = {data: {identifier:'item_id', items:[{item_id:1,title:'title',caption:'cap',alt_text:'alt',credits:'cred',height:'100',width:'200'}]}}; var db = new dojo.data.ItemFileReadStore(imgCtx); function gotItems1(items, request){ document.body.appendChild(document.createTextNode("Adding in the values for all items for store named 'db':")); document.body.appendChild(document.createElement("br")); for(var i = 0; i < items.length; i++){ document.body.appendChild(document.createTextNode(db.getValue(items[i], "title"))); document.body.appendChild(document.createElement("br")); document.body.appendChild(document.createTextNode(db.getValue(items[i], "width"))); document.body.appendChild(document.createElement("br")); document.body.appendChild(document.createTextNode(db.getValue(items[i], "height"))); } document.body.appendChild(document.createElement("br")); } function onError(error, request){ alert(error); console.debug(error); } var request = db.fetch({query:{}, onComplete: gotItems1, onError: onError}); var data = {data: { identifier : 'id', items : [ { id : 'a', label: "Letter A" }, { id : 'b', label: "Letter B" }, { id : 'c', label: "Letter C" }, { id : 'd', label: "Letter D" } ] }}; var store2 = new dojo.data.ItemFileReadStore(data); function gotItems2(items, request){ document.body.appendChild(document.createTextNode("Adding in the values for all items for store named 'store2':")); document.body.appendChild(document.createElement("br")); for(var i = 0; i < items.length; i++){ document.body.appendChild(document.createTextNode(store2.getValue(items[i], "id"))); document.body.appendChild(document.createElement("br")); document.body.appendChild(document.createTextNode(store2.getValue(items[i], "label"))); document.body.appendChild(document.createElement("br")); } document.body.appendChild(document.createElement("br")); } var request2 = store2.fetch({query:{}, onComplete: gotItems2, onError: onError}); } dojo.addOnLoad(init); </script> </head> <body class="tundra"> </body> End result in my browser is as followS: Adding in the values for all items for store named 'db': title 200 100 Adding in the values for all items for store named 'store2': a Letter A b Letter B c Letter C d Letter D
|
| Free embeddable forum powered by Nabble | Forum Help |
