Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#6981 closed enhancement (fixed)

Pseduo-REST store

Reported by: guest Owned by: Kris Zyp
Priority: low Milestone: 1.2
Component: DojoX Data Version: 1.1.0
Keywords: JsonRestStore, dojox.rpc.Rest Cc: maulinpshah.public@…
Blocked By: Blocking:

Description (last modified by kriszyp)

I know JsonRestStore? is not even out yet... but here is a thought. While I understand that REST is based on the POST/GET/PUT/DELETE for CRUD, JsonRestStore? is by far the most robust RPC based store built yet. I want to use it for all my CRUD-requiring data access, but my server blocks PUT and DELETE. So, I know its slightly less efficient (maybe), but how about supporting exactly the same envelope as REST for the service, but only using GET and POST and then adding an "action" attribute to the query-string of "POST/PUT/DELETE".

I've actually "subclassed" dojox.rpc.Rest, but I think in a very volatile way that will likely break as the implementation of JsonRestStore? and dojox.rpc.Rest get more mature. But this works for me for now, and I perhaps a more formal support for this can be added in the future.

Thanks for your time. Here is my "subclass":

/

  • uses post for all post/put/delete, but adds and attribute called action
  • @author maulin
  • */

dojo.provide("medryx.stores.ModifiedRest?"); dojo.require("dojox.rpc.Rest");

(function() {

copied verbatim from dojox.rpc.Rest function index(deferred, service, range, id){ deferred.addCallback(function(result){

if(id==""){

service._rootQueries.push(result);

} if(range){

try to record the total number of items from the range header range = deferred.ioArgs.xhr.getResponseHeader("Content-Range"); deferred.fullLength = range && (range=range.match(/\/(.*)/)) && parseInt(range[1]);

} return service.cache.intake(result,id);

}); return deferred;

}

"over-rides" the actual xhr call to use POST and add action attribute to querystring dojox.rpc.Rest._change = function(method,service,id,content){ this is called to actually do the put, post, and delete var request = service._getRequest(id); request[method+"Data"] = content; request.data += "&action=" + method.toLowerCase();

request.url += (request.url.indexOf('?') > 0 ? "&" : "?" ) + "action=" + method.toLowerCase();

console.debug("request:", request); return index(dojo.xhr("POST",request,true),service);

};

})();

http://blog.medryx.org/2008/06/18/pseudo-restful/

Change History (17)

comment:1 in reply to:  description Changed 11 years ago by guest

So, thinking about this at a less ridiculous hour and after a good night's sleep -- I think The JsonRestStore? may be mixing a few concerns -- one is client side state management (creation of objects, tracking their edits), and one is client-server communication. I like the client-side state management model of JsonRestStore?, but I would like the communication to be pluggable. Perhaps we can define a RestApi? that describes a class that has put, get, delete, post methods and accepts parameters appropriate to them. Then we could create a RestService? class that implements it with "real" rest. That would leave others free to create their own implementations of the RestApi? -- using rpc, or home-rolled xhr, or whatever.

Perhaps this is more of a discussion item than a ticket... sorry to clutter the ticket system. What would be the best forum for this?

comment:2 Changed 11 years ago by kriszyp

Owner: changed from Jared Jurkiewicz to kriszyp
Status: newassigned

comment:3 Changed 11 years ago by kriszyp

Here is my response to Maulin (I had responded to him on his blog about the same thing):

Maulin, I am not exactly certain what you mean by entity-manager, are you referring to the mechanism for triggering lazy loads on property access and recording property changes? I am not sure how you would like JsonRestStore? split up. Here is the current breakdown of modules: JsonRestStore? - Dojo Data API adapter JsonRest? - Tracks changes and fires Rest services Rest - Remote communication service provider dojox.json.ref - Referencing manager for lazy loading and other forms of referencing Perhaps JsonRest? or JsonRestStore? would roughly correspond to your “entity-manager”, and the Rest service would correspond to your “persister”, not sure. You can definitely plug your own custom Rest service into JsonRestStore?. It looks like: myService = function(id){ … get data … } myService.put = function(content) { … save data …} myService.post = function(target,content) { .. create new object …} myServicedelete? = function(target){ … delete object …}

If you providing getters and setters is what you have in mind for an entity-manager, you can also define schemas for JsonRestStore? that define the prototype to use for the objects in the store: mySchema = { prototype: { getFoo:function(){return this.foo}, setFoo:function(val){this.foo =val} } } myStore = new JsonRestStore?({service:myService,schema:mySchema});

I had also suggested this for REST blocking servers: May I suggest something like this for REST blocking servers:

var defaultXhr = dojo.xhr; dojo.xhr = function(method,args,hasBody){ if(method!=”GET”){ args.url += (args.url.indexOf(’?') > 0 ? “&” : “?” ) + “action=” + method.toLowerCase(); if(method==”PUT”){ args.postData = args.putData; } method = “POST”; } return defaultXhr(method,args,hasBody); }

That way all your requests that use PUT, POST, and DELETE will automatically have the correct “action” parameter. I didn’t test this, but I think it should work.

Maulin, I hope this answers your question, let me know if you had something different in mind that you wanted from JsonRestStore?.

comment:4 in reply to:  3 ; Changed 11 years ago by guest

Kris:

I don't think you have actually implemented the schema/prototype stuff, have you? A quick look through the most recent nightly build shows ServiceStore? supporting a schema argument that it mixes in and uses for _idAttr (which in and of itself is seem "magic" -- since its not really part of your JSON-schema spec at http://groups.google.com/group/json-schema/web/json-schema-proposal---second-draft).

Then in JsonRestStore?, it sets the schema to service._schema, ONLY if you haven't described your OWN service (i.e. only when you provide a target argument).

Finally in JsonRest?, it only uses the _schema as a mixin in the constructor, which wouldn't be quite right. I think you would mix in the prototype, right? and THEN you would mixin the data.

In Rest, you do get the id attribute from the schema by looking for the unique property, but is this really the same as an id? shouldn't json-schema support "identifier" as a property attribute?

So, I guess if you are using JsonRestStore? out of the box with native REST (as opposed to your own custom service), then this potentially works (though I still think the prototype object thing is not supported), and none of this works with a custom service.

Also, it seems in terms of mixing in the prototype or using the schema, it is only for new items, not for items retrieved in a query (which would only return the raw json object). Is that by intent? Because I would assume that if your provide a prototype (with getters and setters, for example, or with other methods), that they would be availble on any object I fetched before I fetched it.

I think that if we really want to make this pluggable (as per our previous conversations) we might need to think through what pieces are pluggable and to what degree.

Replying to kriszyp:

Here is my response to Maulin (I had responded to him on his blog about the same thing):

Maulin, I am not exactly certain what you mean by entity-manager, are you referring to the mechanism for triggering lazy loads on property access and recording property changes? I am not sure how you would like JsonRestStore? split up. Here is the current breakdown of modules: JsonRestStore? - Dojo Data API adapter JsonRest? - Tracks changes and fires Rest services Rest - Remote communication service provider dojox.json.ref - Referencing manager for lazy loading and other forms of referencing Perhaps JsonRest? or JsonRestStore? would roughly correspond to your “entity-manager”, and the Rest service would correspond to your “persister”, not sure. You can definitely plug your own custom Rest service into JsonRestStore?. It looks like: myService = function(id){ … get data … } myService.put = function(content) { … save data …} myService.post = function(target,content) { .. create new object …} myServicedelete? = function(target){ … delete object …}

If you providing getters and setters is what you have in mind for an entity-manager, you can also define schemas for JsonRestStore? that define the prototype to use for the objects in the store: mySchema = { prototype: { getFoo:function(){return this.foo}, setFoo:function(val){this.foo =val} } } myStore = new JsonRestStore?({service:myService,schema:mySchema});

I had also suggested this for REST blocking servers: May I suggest something like this for REST blocking servers:

var defaultXhr = dojo.xhr; dojo.xhr = function(method,args,hasBody){ if(method!=”GET”){ args.url += (args.url.indexOf(’?') > 0 ? “&” : “?” ) + “action=” + method.toLowerCase(); if(method==”PUT”){ args.postData = args.putData; } method = “POST”; } return defaultXhr(method,args,hasBody); }

That way all your requests that use PUT, POST, and DELETE will automatically have the correct “action” parameter. I didn’t test this, but I think it should work.

Maulin, I hope this answers your question, let me know if you had something different in mind that you wanted from JsonRestStore?.

comment:5 in reply to:  4 Changed 11 years ago by kriszyp

Replying to guest:

Kris:

I don't think you have actually implemented the schema/prototype stuff, have you? A quick look through the most recent nightly build shows ServiceStore? supporting a schema argument that it mixes in and uses for _idAttr (which in and of itself is seem "magic"

This is an internal private property (hence the _ prefix) used to cache the result of the search for the unique/identity property from the schema.

Then in JsonRestStore?, it sets the schema to service._schema, ONLY if you haven't described your OWN service (i.e. only when you provide a target argument).

You are right, this needs to be fixed so the schema can be provided for your own service. It should be noted that a SMD generated service (through dojox.rpc.Service) can also set the schema, so both of these entry points should properly set the schema.

Finally in JsonRest?, it only uses the _schema as a mixin in the constructor, which > wouldn't be quite right. I think you would mix in the prototype, right? and THEN you would mixin the data.

By doing a mixin on the constructor, the prototype from the schema is copied to the constructor, consequently all the new objects created by the constructor have their delegate proto? pointing to the prototype object copied from the schema, using true JavaScript? inheritance (not mixins). I just tested this again, and it does work properly.

In Rest, you do get the id attribute from the schema by looking for the unique property, but is this really the same as an id? shouldn't json-schema support "identifier" as a property attribute?

Good suggestion, I can propose this.

So, I guess if you are using JsonRestStore? out of the box with native REST (as opposed to your own custom service), then this potentially works (though I still think the prototype object thing is not supported), and none of this works with a custom service.

I'll fix this.

Also, it seems in terms of mixing in the prototype or using the schema, it is only for new items, not for items retrieved in a query (which would only return the raw json object). Is that by intent? Because I would assume that if your provide a prototype (with getters and setters, for example, or with other methods), that they would be availble on any object I fetched before I fetched it.

Objects returned from queries get their prototype set immediately on entry to the system in dojox.json.ref.fromJson (line 74-82) from the schema. This must be done on initial object creation because Proto? is immutable in IE (and probably some other browsers), and don't want to copy and lose object identity.

I think that if we really want to make this pluggable (as per our previous conversations) we might need to think through what pieces are pluggable and to what degree.

Feel free to share more suggestions about how pieces should be properly designed for proper pluggability.

comment:6 Changed 11 years ago by guest

great. first thanks for bolstering my javascript knowledge -- this whole prototype thing still gets me a little confused.

i also didn't notice the connection to dojox.json.ref.fromJson so i couldn't see how it was all getting applied. and since i couldn't get it to work with my custom service, i thought it didn't work. But alas, it does with a Rest service.

so i guess the take home for this ticket is the "I'll fix that" bit -- i.e. supporting custom services (that are not SMD or REST). which, it seems will not be a big deal. so that's good news!

thanks again for all your attention to this. I am really doing my best to not have to use my custom store and use JsonRestStore?!

comment:7 Changed 11 years ago by kriszyp

I just checked in the fix for setting the schema with a custom service. Let me know if you have any problems, I want to try get any issues with JsonRestStore? fixed quickly since we will be releasing 1.2 beta soon.

comment:8 Changed 11 years ago by guest

Maybe its me -- I think I am missing something fundamental. Let me describe my test case:

I create a "Mock" REST service as follows:

dojo.declare("MockService?", null, {

mockResult:null,

doFakeXhr:function() {

var d = new dojo.Deferred();

d.callback(this.mockResult); return d;

},

get:function(params) {

console.debug("in get", params, this.mockResult); this.getParams = params; var d = this.doFakeXhr();

return d;

},

put:function(params, data) {

console.debug("in put", params, data); var d = this.doFakeXhr();

return d;

},

post:function(params, data) {

console.debug("in post", params, data); var d = this.doFakeXhr();

return d;

},

'delete':function(params) {

console.debug("in delete", params); var d = this.doFakeXhr();

return d;

}

});

Then, to use it in JsonRestStore? I do:

var service = new MockService?(); var mockService = dojo.hitch(service, "get"); mockService.put = dojo.hitch(service, "put"); mockService.post = dojo.hitch(service, "post"); mockServicedelete? = dojo.hitch(service, "delete");

I then create a schema:

var schema = {

prototype:{

getAnotherValue:function() {

return this.anotherValue;

} anotherValue:"someOtherValue"

}

}

Now I create my JsonRestStore? as:

var store = new dojox.data.JsonRestStore?({service:this.mockService, schema:schema});

now lets look at the test case:

service.mockResult = {id:1, value:"Test"}; store.fetchItemByIdentity({identity:1, onItem:function(item) {

console.debug(item);

});

(actually I use doh with my doh.TestCase?, but I've simplified here a bit)

I expect my "item" to be:

{

id:1, value:"Test", anotherValue:"someOtherValue", getAnotherValue:function() {

return this.anotherValue;

}

}

but I get the raw json:

{

id:1, value:"Test"

}

and stepping through the code, I never run dojox.json.ref code.

what am i missing that I should be doing differently?

comment:9 Changed 11 years ago by kriszyp

The OOTB Rest service (dojox.rpc.Rest) is responsible for calling dojox.json.ref with the correct parameters for schema/prototype assignment. This is the so the objects introduced by the Rest service can be used consistently where access directly or from a store. Using a custom service, I can see how things get trickier, you will have to call dojox.json.ref.resolveJson yourself. You You can look at lines dojox.rpc.Rest lines 81-86 to see an example. An important aspect is that the services object is used to lookup the correct service and schema, so services[idPrefix]._schema is used to load the schema.

I can see that using the schema/prototype functionality from a custom service is definitely awkward. Perhaps a good mitigation would be to allow you to directly provide the schema to dojox.json.ref.resolveJson (it wouldn't support loading cross-store objects with the correct prototype, but most probably don't need that functionality).

comment:10 Changed 11 years ago by guest

okay, so this is not a "bug". but this is what i mean by pluggable, and in my earlier conversations about a violation of separation of concerns. Perhaps it is just my quirky way of thinking, but I think that a more layered approach would make for a cleaner, more extensible code, especially for a toolkit where it is fully expected people will be extending the code.

I think there are at least a few different layers that *should* be present and interchangeable (pluggable)

  1. persistence -- this is the CRUD functions. I should be able to use an RPC service, a custom class, whatever. I just agree to implement the CRUD api which would be very simple. (I think this will allow you to plug REST, RPC, etc in very easily. Or imagine a person who build a GWT-RPC service and now wants to convert to to dojo without changing the service. Build a little CRUD that communicates withy GWT-RPC servlets and you are done. An additional benefit may be offline storage. Build a CRUD connector to Gears, and the rest of your code is unchanged).
  1. caching/instantiation/query -- this is the piece that uses the raw data from the persistence layer, and creates the appropriate representation on the client. This is what I have been referring to as an "EntityManager?".
  1. client side querying mechanism -- this could potentially be completely independent of the caching layer, and could allow for different client-side query implementations (for example, a simple dojo.data.filter/sorter based one, perhaps a TaffyDB based one?) This would connect to the EntityManager? in some way
  1. Store API -- Read/Write/Identity? etc. that provides store-per-class granularity. This would be "managed" (either explicitly or transparently) by the EntityManager? (so that cross-store references and object identity could be maintained).

The current implementation of JsonRestStore? has all these concepts, but not in the distinct layers as best as I can understand. The obvious case in point is that dojo.rpc.Rest actually handles instantiation of objects, when I think it should really only deal with "raw" data and how to connect to get/put/post/delete methods the right way.

I could see a JsonRest? class that would assume the return types from the get/put/post/delete methods were Json objects (since they could theoretically be anything from raw text to csv to whatever, right?)

JsonRest? really wouldn't do anything other than guarantee that your return results were the appropriate raw json (i.e. it could handle conversion from other formats if needed/desired)

I could see ServiceStore? being the real meat of an EntityManager?. It would be abstract and require subclasses to "_processResults" as it does now -- and this is where the instantiation of the objects from whatever raw CRUD service data would occur.

Client side queries are really not yet described.

And then JsonServiceStore? would be a very specific implementation of a ServiceStore?. There actually would not be a lot of code here. It could take any CRUD that promised to meet the CRUD api AND return Json. (A Rest, JsonRest?, or any other CRUD implementor). its only real purpose in life would be to implement _processResults, which it would do using the dojox.json.ref.resolveJson mechanism.

Finally, you could create a JsonRestStore? that essentially offers "shortcuts", so you don't actually have to create a JsonRest? service, but instead just provide the "target", etc directly to JsonRestStore?.

Do you see what I mean about how the current implementation, while it has "layers", there is a lot of bleeding between the layers?

Now, I understand this is JS and not Java, and its not pure OO, and maybe having all these layers is a performance nightmare. But I don't think it has to be.

If a layered approach like this were taken, and then someone like me came along and wanted to build my own service, but really just because i didn't like Json-Schema (which, is not the case, by the way) and wanted to use a different method for instantiation, or even just skipped the whole instantiation phase and used the raw objects, i could. With the current implementation -- as proven by the example above, I can't swap out one layer and roll-my-own service and still get a lot of the benefit of the work you have already put in.

Here is another example. Lets talk about the API layer. The usual implementation of this could be quite simple, wrapping ServiceStore? calls for specific stores. But now lets say I want to extend the API to support dot-path'd attribute (e.g. store.getValue(item, "person.name.firstName")), in a layered system, I would not have to do more than extend the Api layer, mix back in all the existing other classes, and suddenly I've got a working solution for my needs.

Obviously I could hack the current solution and make it work for me. And as you know, I've already created a solution that works for me that is a bit more layered. But I would like to see dojo -- as a platform for development and infinite extension and possibilities -- try to be as arhcitecturally disciplined as possible, to really facilitate that kind of use.

I hope that makes some sense. You all have a LOT more experience than I do in these matters, ESPECIALLY on the client-side, but I just want to be sure this issue is really thought through.

comment:11 in reply to:  10 Changed 11 years ago by kriszyp

Description: modified (diff)

Replying to guest:

okay, so this is not a "bug". but this is what i mean by pluggable, and in my earlier conversations about a violation of separation of concerns. Perhaps it is just my quirky way of thinking, but I think that a more layered approach would make for a cleaner, more extensible code, especially for a toolkit where it is fully expected people will be extending the code.

Absolutely, but I thought I actually had a very layered approach, more layers than you have suggested with your design. My layers include: Store API for services dojo - dojox.data.ServiceStore? Store API for read-write (REST) services - dojox.data.JsonRestStore? Rest Service - dojxo.rpc.Rest Index/referencing resolution - dojox.json.ref SMD Service creation - dojox.rpc.Service Multi-store/table manager - dojox.rpc.JsonRest? Offline capability - dojox.rpc.OfflineRest? Comet/live-sync capability - dojox.cometd.HttpChannels?

I think there are at least a few different layers that *should* be present and interchangeable (pluggable)

Absolutely, although of course with many development exercises, we would like to keep components as distinct as possible, but meaningful and efficient interaction often requires signification interaction.

  1. persistence -- this is the CRUD functions. I should be able to use an RPC service, a custom class, whatever. I just agree to implement the CRUD api which would be very simple. (I think this will allow you to plug REST, RPC, etc in very easily. Or imagine a person who build a GWT-RPC service and now wants to convert to to dojo without changing the service. Build a little CRUD that communicates withy GWT-RPC servlets and you are done. An additional benefit may be offline storage. Build a CRUD connector to Gears, and the rest of your code is unchanged).

Right, we have pluggable services. But, ss discussed earlier this requires levels of integration to achieve efficient cross-site referencing with prototyping.

  1. caching/instantiation/query -- this is the piece that uses the raw data from the persistence layer, and creates the appropriate representation on the client. This is what I have been referring to as an "EntityManager?".

This is what dojox.json.ref does. This is more modular than "EntityManager?", because the handling of transactions between stores is separated into a separate module.

  1. client side querying mechanism -- this could potentially be completely independent of the caching layer, and could allow for different client-side query implementations (for example, a simple dojo.data.filter/sorter based one, perhaps a TaffyDB based one?) This would connect to the EntityManager? in some way

This doesn't exist yet, this is what we have been discussing, and doing it in a new module is fine.

  1. Store API -- Read/Write/Identity? etc. that provides store-per-class granularity. This would be "managed" (either explicitly or transparently) by the EntityManager? (so that cross-store references and object identity could be maintained).

JsonRestStore? provides the Store API.

The current implementation of JsonRestStore? has all these concepts, but not in the distinct layers as best as I can understand. The obvious case in point is that dojo.rpc.Rest actually handles instantiation of objects, when I think it should really only deal with "raw" data and how to connect to get/put/post/delete methods the right way.

If the Rest service doesn't handle object instantiation than you actually lose more modularity than you gain. You could no longer use dojox.rpc.Rest directly, since it would return different objects than would appear dojox.data.JsonRestStore?. Indexing and referencing should not be so tied to the data store. In the interest of modularity I want indexing and referencing to be separated from the data store. On the otherhand index/cache is direct concern of Rest, that is foundation of the Rest concept. Now it may be worth looking at house the Rest service could be broken into separate modules, a high level Rest handler and lower level transport handler. I would definitely consider that.

I could see a JsonRest? class that would assume the return types from the get/put/post/delete methods were Json objects (since they could theoretically be anything from raw text to csv to whatever, right?)

JsonRest? really wouldn't do anything other than guarantee that your return results were the appropriate raw json (i.e. it could handle conversion from other formats if needed/desired)

I could see ServiceStore? being the real meat of an EntityManager?. It would be abstract and require subclasses to "_processResults" as it does now -- and this is where the instantiation of the objects from whatever raw CRUD service data would occur.

ServiceStore? works fine on it's own, why would I treat it as abstact?

Client side queries are really not yet described.

Right, we are discussing that one.

And then JsonServiceStore? would be a very specific implementation of a ServiceStore?. There actually would not be a lot of code here. It could take any CRUD that promised to meet the CRUD api AND return Json. (A Rest, JsonRest?, or any other CRUD implementor). its only real purpose in life would be to implement _processResults, which it would do using the dojox.json.ref.resolveJson mechanism.

Once again, we are losing modularity if we tie data stores to dojox.json.ref.

Finally, you could create a JsonRestStore? that essentially offers "shortcuts", so you don't actually have to create a JsonRest? service, but instead just provide the "target", etc directly to JsonRestStore?.

You can already do that, you can provide a target to JsonRestStore? and it will work. That is actually how I would recommend using it.

Do you see what I mean about how the current implementation, while it has "layers", there is a lot of bleeding between the layers?

Hopefully I have addressed the need for certain interaction (bleeding) between layers, hopefully we can improve areas where we can improve modularity.

Now, I understand this is JS and not Java, and its not pure OO, and maybe having all these layers is a performance nightmare. But I don't think it has to be.

Performance has been a very high priority. This is also one of the reasons that object instantiation takes place in dojox.json.ref, so the indexing and object instantiation can take place in one sweep.

If a layered approach like this were taken, and then someone like me came along and wanted to build my own service, but really just because i didn't like Json-Schema (which, is not the case, by the way) and wanted to use a different method for instantiation, or even just skipped the whole instantiation phase and used the raw objects, i could. With the current implementation -- as proven by the example above, I can't swap out one layer and roll-my-own service and still get a lot of the benefit of the work you have already put in.

Right, that is definitely the idea, and I appreciate your help in polishing in towards that end.

Here is another example. Lets talk about the API layer. The usual implementation of this could be quite simple, wrapping ServiceStore? calls for specific stores. But now lets say I want to extend the API to support dot-path'd attribute (e.g. store.getValue(item, "person.name.firstName")), in a layered system, I would not have to do more than extend the Api layer, mix back in all the existing other classes, and suddenly I've got a working solution for my needs.

We using JavaScript?, that is easy, you don't need my help for that :).

Obviously I could hack the current solution and make it work for me. And as you know, I've already created a solution that works for me that is a bit more layered. But I would like to see dojo -- as a platform for development and infinite extension and possibilities -- try to be as arhcitecturally disciplined as possible, to really facilitate that kind of use.

Hopefully I have clarified the modular architecture I am using. It sounds like dojox.rpc.Rest is the area that may need more work (and adding client side querying)

I hope that makes some sense. You all have a LOT more experience than I do in these matters, ESPECIALLY on the client-side, but I just want to be sure this issue is really thought through.

Certainly appreciated!

comment:12 Changed 11 years ago by guest

Kris,

I think we are basically on the same page. I think that first that rpc.Rest should be broken into Transport/Rest? layers. My only (and final concern) is that it took this long of a conversation to sort this out for me. Perhaps I am thick, but could it also be a flag that perhaps some design simplification is needed?

For now, I am sticking with my EM concept (though I think I will refactor to try and use Json-Schema if possible). Some reasons --

  1. already supports pluggable transport layer (most important to me since I like to test without a real store or server around, and since my server side is likely to change multiple times in the not-to-distant future)
  2. already has a mechanism for client side querying
  3. supports "property level lazy loading" or "sparsely populated objects" -- i.e. a very long string may be lazily loaded as well as a reference to another object.
  4. only loads a lazy association if its really needed. (which means, only if a property, other than the id is required and doesn't already exist)
  5. already supports dot-path notation with built in lazy loading
  6. supports "eager fetching" of properties that the server didn't necessarily send (an edge-case, but cool anyway)
  7. already supports javabean style accessors/mutators, but can use direct property access in almost all situations safely
  8. already supports active-record style saving (instance.save())
  9. I understand it better, and obviously it suits my needs :-) !!

I will be watching the progress of JsonRestStore? with great anticipation! I can imagine integrating the two solutions at some point. I just don't think I am there yet.

Thanks again for the time.

-m

comment:13 Changed 11 years ago by Kris Zyp

Milestone: 1.21.3

Is there any more separations, module breakouts, or rearchitecting that need to be done with the JsonRestStore?? Or should I close this ticket (more specific tickets could be open later)?

comment:14 Changed 11 years ago by maulin

I think it should be closed.

comment:15 Changed 11 years ago by Kris Zyp

Resolution: fixed
Status: assignedclosed

comment:16 Changed 11 years ago by bill

Milestone: 1.31.2

comment:17 Changed 10 years ago by bill

Owner: changed from kriszyp to Kris Zyp
Note: See TracTickets for help on using tickets.