|
Scrubbing deferred responses
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Scrubbing deferred responses
by Kenton Smeltzer
::
Rate this Message:
I have a question on a pattern that I seem to use allot. I hold a core belife that the UI should be tasked with UI concerns and therfore the UI should be tasked with any data manipulation to restructure the data into it's needed format, I do not like to impose a client model on my services as it tightly binds that service to a paticular UI implementation with dojo that implementation is stores. Anyway to cut to the chase I find mysellf doing somthing similar to the following so that I can inject a scrub routine between the deferred response and the UI widget that needs the data. generally massaging that data into a model for a store so that I can data bind it to my widget.
After var retDeferred = new dojo.Deferred(); //When the scrub connect point is hit call the returned deferreds callback and passes the built store. dojo.connect(this, "_theMethodThatGetsCalledByTheScrubingMethodWhenItIsDoneAndPassesItTheStore", retDeferred , "callback"); //Call the service var deferred = dojo.xhrGet(xhrArgs); //connect the method that will scrub the results and then will call the scrub connect point. deferred.addCallback(this, "_theMethodThatWillScrubTheResults"); //Return the deferred that is connected to the after scrub connect point. return retDeferred; My question is am I reinventing the wheel here, does something exist to do this? If not does anyone have a elegant solution on how to make this a generic pattern to create a ScrubbedDeferred object that will call a scrub method before returning the deferred, kind of hitting a scrub method first and then messaging all of the callbacks? _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://docs.dojocampus.org Dojo-interest@... http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: Scrubbing deferred responses
by Miguel Coquet
::
Rate this Message:
Hi Kenton
If I understand correctly , this method you call will do the job of getting whatever the response of the webservice is, and transforming it to look right to use with an existing dojo.data store (jsonreststore or ItemFileReadStore I imagine). That seems to be what dojo.data is there for. It looks to me like the "right" thing to do would be to implement a new data.store for that service. If you look at dojox.data you will find lots of different data store implementations for various services, and all they do is translate from that webservice into dojo.data talk, allowing for any dojo.data enabled widget to talk to that webservice transparently. Is this what you are looking for? Cheers Miguel On 2009/11/07, at 05:09, Kenton Smeltzer wrote: > I have a question on a pattern that I seem to use allot. I hold a > core belife that the UI should be tasked with UI concerns and > therfore the UI should be tasked with any data manipulation to > restructure the data into it's needed format, I do not like to > impose a client model on my services as it tightly binds that > service to a paticular UI implementation with dojo that > implementation is stores. Anyway to cut to the chase I find mysellf > doing somthing similar to the following so that I can inject a scrub > routine between the deferred response and the UI widget that needs > the data. generally massaging that data into a model for a store so > that I can data bind it to my widget. > > After > > var retDeferred = new dojo.Deferred(); > //When the scrub connect point is hit call > the returned deferreds callback and passes the built store. > dojo.connect(this, > "_theMethodThatGetsCalledByTheScrubingMethodWhenItIsDoneAndPassesItTheStore > ", retDeferred , "callback"); > //Call the service > var deferred = dojo.xhrGet(xhrArgs); > //connect the method that will scrub the > results and then will call the scrub connect point. > deferred.addCallback(this, > "_theMethodThatWillScrubTheResults"); > //Return the deferred that is connected to the > after scrub connect point. > return retDeferred; > > My question is am I reinventing the wheel here, does something exist > to do this? If not does anyone have a elegant solution on how to > make this a generic pattern to create a ScrubbedDeferred object that > will call a scrub method before returning the deferred, kind of > hitting a scrub method first and then messaging all of the callbacks? > _______________________________________________ > FAQ: http://dojotoolkit.org/support/faq > Book: http://docs.dojocampus.org > Dojo-interest@... > http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://docs.dojocampus.org Dojo-interest@... http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: Scrubbing deferred responses
by Kenton Smeltzer
::
Rate this Message:
A store would work but some times the returned data only needs a few
items renamed to fit into an existing store like an ItemFileReadStore and then some times on the object tree that is returned, I only need a array that is a child of the returned object (e.g. Items = result.someSubObject.anArray). It seemed a little heavy to me to write a store for every service call, but it is verry possible that I am missing some understanding. On Nov 7, 2009, at 5:54 AM, Miguel Coquet <mcoquet@...> wrote: > Hi Kenton > > If I understand correctly , this method you call will do the job of > getting whatever the response of the webservice is, and transforming > it to look right to use with an existing dojo.data store > (jsonreststore or ItemFileReadStore I imagine). > > That seems to be what dojo.data is there for. It looks to me like the > "right" thing to do would be to implement a new data.store for that > service. > > If you look at dojox.data you will find lots of different data store > implementations for various services, and all they do is translate > from that webservice into dojo.data talk, allowing for any dojo.data > enabled widget to talk to that webservice transparently. > > Is this what you are looking for? > > > Cheers > > Miguel > > On 2009/11/07, at 05:09, Kenton Smeltzer wrote: > >> I have a question on a pattern that I seem to use allot. I hold a >> core belife that the UI should be tasked with UI concerns and >> therfore the UI should be tasked with any data manipulation to >> restructure the data into it's needed format, I do not like to >> impose a client model on my services as it tightly binds that >> service to a paticular UI implementation with dojo that >> implementation is stores. Anyway to cut to the chase I find mysellf >> doing somthing similar to the following so that I can inject a scrub >> routine between the deferred response and the UI widget that needs >> the data. generally massaging that data into a model for a store so >> that I can data bind it to my widget. >> >> After >> >> var retDeferred = new dojo.Deferred(); >> //When the scrub connect point is hit call >> the returned deferreds callback and passes the built store. >> dojo.connect(this, >> "_theMethodThatGetsCalledByTheScrubingMethodWhenItIsDoneAndPassesItTheStore >> ", retDeferred , "callback"); >> //Call the service >> var deferred = dojo.xhrGet(xhrArgs); >> //connect the method that will scrub the >> results and then will call the scrub connect point. >> deferred.addCallback(this, >> "_theMethodThatWillScrubTheResults"); >> //Return the deferred that is connected to the >> after scrub connect point. >> return retDeferred; >> >> My question is am I reinventing the wheel here, does something exist >> to do this? If not does anyone have a elegant solution on how to >> make this a generic pattern to create a ScrubbedDeferred object that >> will call a scrub method before returning the deferred, kind of >> hitting a scrub method first and then messaging all of the callbacks? >> _______________________________________________ >> FAQ: http://dojotoolkit.org/support/faq >> Book: http://docs.dojocampus.org >> Dojo-interest@... >> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest > > _______________________________________________ > FAQ: http://dojotoolkit.org/support/faq > Book: http://docs.dojocampus.org > Dojo-interest@... > http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest FAQ: http://dojotoolkit.org/support/faq Book: http://docs.dojocampus.org Dojo-interest@... http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: Scrubbing deferred responses
by Miguel Coquet
::
Rate this Message:
I see what you mean. However, in practice you can just extend that
existing store and make the tiny changes necessary. Have you tried that? It seems to be the easiest option. On 2009/11/07, at 12:40, Kenton Smeltzer wrote: > A store would work but some times the returned data only needs a few > items renamed to fit into an existing store like an ItemFileReadStore > and then some times on the object tree that is returned, I only need a > array that is a child of the returned object (e.g. Items = > result.someSubObject.anArray). It seemed a little heavy to me to write > a store for every service call, but it is verry possible that I am > missing some understanding. > > On Nov 7, 2009, at 5:54 AM, Miguel Coquet <mcoquet@...> wrote: > >> Hi Kenton >> >> If I understand correctly , this method you call will do the job of >> getting whatever the response of the webservice is, and transforming >> it to look right to use with an existing dojo.data store >> (jsonreststore or ItemFileReadStore I imagine). >> >> That seems to be what dojo.data is there for. It looks to me like the >> "right" thing to do would be to implement a new data.store for that >> service. >> >> If you look at dojox.data you will find lots of different data store >> implementations for various services, and all they do is translate >> from that webservice into dojo.data talk, allowing for any dojo.data >> enabled widget to talk to that webservice transparently. >> >> Is this what you are looking for? >> >> >> Cheers >> >> Miguel >> >> On 2009/11/07, at 05:09, Kenton Smeltzer wrote: >> >>> I have a question on a pattern that I seem to use allot. I hold a >>> core belife that the UI should be tasked with UI concerns and >>> therfore the UI should be tasked with any data manipulation to >>> restructure the data into it's needed format, I do not like to >>> impose a client model on my services as it tightly binds that >>> service to a paticular UI implementation with dojo that >>> implementation is stores. Anyway to cut to the chase I find mysellf >>> doing somthing similar to the following so that I can inject a scrub >>> routine between the deferred response and the UI widget that needs >>> the data. generally massaging that data into a model for a store so >>> that I can data bind it to my widget. >>> >>> After >>> >>> var retDeferred = new dojo.Deferred(); >>> //When the scrub connect point is hit call >>> the returned deferreds callback and passes the built store. >>> dojo.connect(this, >>> "_theMethodThatGetsCalledByTheScrubingMethodWhenItIsDoneAndPassesItTheStore > >>> ", retDeferred , "callback"); >>> //Call the service >>> var deferred = dojo.xhrGet(xhrArgs); >>> //connect the method that will scrub the >>> results and then will call the scrub connect point. >>> deferred.addCallback(this, >>> "_theMethodThatWillScrubTheResults"); >>> //Return the deferred that is connected to the >>> after scrub connect point. >>> return retDeferred; >>> >>> My question is am I reinventing the wheel here, does something exist >>> to do this? If not does anyone have a elegant solution on how to >>> make this a generic pattern to create a ScrubbedDeferred object that >>> will call a scrub method before returning the deferred, kind of >>> hitting a scrub method first and then messaging all of the >>> callbacks? >>> _______________________________________________ >>> FAQ: http://dojotoolkit.org/support/faq >>> Book: http://docs.dojocampus.org >>> Dojo-interest@... >>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest >> >> _______________________________________________ >> FAQ: http://dojotoolkit.org/support/faq >> Book: http://docs.dojocampus.org >> Dojo-interest@... >> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest > _______________________________________________ > FAQ: http://dojotoolkit.org/support/faq > Book: http://docs.dojocampus.org > Dojo-interest@... > http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://docs.dojocampus.org Dojo-interest@... http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
Re: Scrubbing deferred responses
by Kenton Smeltzer
::
Rate this Message:
No I have not, I was trying to follow the philosophy of build with and
not on, but it would be easy to convert what I have over to stores, if that is what is considered best practice. On Nov 7, 2009, at 7:45 AM, Miguel Coquet <mcoquet@...> wrote: > I see what you mean. However, in practice you can just extend that > existing store and make the tiny changes necessary. Have you tried > that? It seems to be the easiest option. > > On 2009/11/07, at 12:40, Kenton Smeltzer wrote: > >> A store would work but some times the returned data only needs a few >> items renamed to fit into an existing store like an ItemFileReadStore >> and then some times on the object tree that is returned, I only >> need a >> array that is a child of the returned object (e.g. Items = >> result.someSubObject.anArray). It seemed a little heavy to me to >> write >> a store for every service call, but it is verry possible that I am >> missing some understanding. >> >> On Nov 7, 2009, at 5:54 AM, Miguel Coquet <mcoquet@...> wrote: >> >>> Hi Kenton >>> >>> If I understand correctly , this method you call will do the job of >>> getting whatever the response of the webservice is, and transforming >>> it to look right to use with an existing dojo.data store >>> (jsonreststore or ItemFileReadStore I imagine). >>> >>> That seems to be what dojo.data is there for. It looks to me like >>> the >>> "right" thing to do would be to implement a new data.store for that >>> service. >>> >>> If you look at dojox.data you will find lots of different data store >>> implementations for various services, and all they do is translate >>> from that webservice into dojo.data talk, allowing for any dojo.data >>> enabled widget to talk to that webservice transparently. >>> >>> Is this what you are looking for? >>> >>> >>> Cheers >>> >>> Miguel >>> >>> On 2009/11/07, at 05:09, Kenton Smeltzer wrote: >>> >>>> I have a question on a pattern that I seem to use allot. I hold a >>>> core belife that the UI should be tasked with UI concerns and >>>> therfore the UI should be tasked with any data manipulation to >>>> restructure the data into it's needed format, I do not like to >>>> impose a client model on my services as it tightly binds that >>>> service to a paticular UI implementation with dojo that >>>> implementation is stores. Anyway to cut to the chase I find mysellf >>>> doing somthing similar to the following so that I can inject a >>>> scrub >>>> routine between the deferred response and the UI widget that needs >>>> the data. generally massaging that data into a model for a store so >>>> that I can data bind it to my widget. >>>> >>>> After >>>> >>>> var retDeferred = new dojo.Deferred(); >>>> //When the scrub connect point is hit call >>>> the returned deferreds callback and passes the built store. >>>> dojo.connect(this, >>>> "_theMethodThatGetsCalledByTheScrubingMethodWhenItIsDoneAndPassesItTheStore >> >>>> ", retDeferred , "callback"); >>>> //Call the service >>>> var deferred = dojo.xhrGet(xhrArgs); >>>> //connect the method that will scrub the >>>> results and then will call the scrub connect point. >>>> deferred.addCallback(this, >>>> "_theMethodThatWillScrubTheResults"); >>>> //Return the deferred that is connected to the >>>> after scrub connect point. >>>> return retDeferred; >>>> >>>> My question is am I reinventing the wheel here, does something >>>> exist >>>> to do this? If not does anyone have a elegant solution on how to >>>> make this a generic pattern to create a ScrubbedDeferred object >>>> that >>>> will call a scrub method before returning the deferred, kind of >>>> hitting a scrub method first and then messaging all of the >>>> callbacks? >>>> _______________________________________________ >>>> FAQ: http://dojotoolkit.org/support/faq >>>> Book: http://docs.dojocampus.org >>>> Dojo-interest@... >>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest >>> >>> _______________________________________________ >>> FAQ: http://dojotoolkit.org/support/faq >>> Book: http://docs.dojocampus.org >>> Dojo-interest@... >>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest >> _______________________________________________ >> FAQ: http://dojotoolkit.org/support/faq >> Book: http://docs.dojocampus.org >> Dojo-interest@... >> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest > > _______________________________________________ > FAQ: http://dojotoolkit.org/support/faq > Book: http://docs.dojocampus.org > Dojo-interest@... > http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest FAQ: http://dojotoolkit.org/support/faq Book: http://docs.dojocampus.org Dojo-interest@... http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
|
|
|
Re: Scrubbing deferred responses
by Kenton Smeltzer
::
Rate this Message:
So if I make the first connect then I am guaranteed that that routine will run first? I was not clear on that so I was avoiding it in case it was not guaranteed. If that is the case it makes my problem allot easier, Thank you for the info.
On Sat, Nov 7, 2009 at 2:14 PM, Ed Schiebel <eschiebel@...> wrote: Kenton, _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://docs.dojocampus.org Dojo-interest@... http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest |
|
|
|
|
|
Re: Scrubbing deferred responses
by Kenton Smeltzer
::
Rate this Message:
OK thanks for the info, that helps allot.
On Sun, Nov 8, 2009 at 10:35 AM, Ed Schiebel <eschiebel@...> wrote: Yes, though we're talking about Deferred.addCallback, and not dojo.connect here. _______________________________________________ FAQ: http://dojotoolkit.org/support/faq Book: http://docs.dojocampus.org Dojo-interest@... http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest |
| Free embeddable forum powered by Nabble | Forum Help |
