Opened 11 years ago

Closed 6 years ago

#7175 closed enhancement (wontfix)

BeanStore

Reported by: maulin Owned by: Kris Zyp
Priority: high Milestone: future
Component: DojoX Data Version: 1.1.1
Keywords: Cc: kris@…
Blocked By: Blocking:

Description

I've extended JsonRestStore? to add bean-style accessor/mutator methods to loaded items, as well as dot-path notation support in getValue. I call it BeanStore?... perhaps others would find it helpful?

Attachments (3)

BeanStoreTest.js (2.2 KB) - added by maulin 11 years ago.
BeanStore.2.js (1.4 KB) - added by maulin 11 years ago.
BeanStore.js (1.5 KB) - added by maulin 11 years ago.
BeanStore?.2.js

Download all attachments as: .zip

Change History (15)

Changed 11 years ago by maulin

Attachment: BeanStoreTest.js added

Changed 11 years ago by maulin

Attachment: BeanStore.2.js added

comment:1 Changed 11 years ago by Kris Zyp

Owner: changed from Jared Jurkiewicz to Kris Zyp

Looks cool, I will do some further review before committing.

Changed 11 years ago by maulin

Attachment: BeanStore.js added

BeanStore?.2.js

comment:2 Changed 11 years ago by bill

Hmm.... like most people, I'm more comfortable with an OO way to access item properties, but the decision in the dojo community was to not do that, because of possible performance issues. So, it seems strange to change it for one store. OTOH I guess it makes things more convenient if people know they are using that store.

I looked at your test and I'm not sure what "item.value" or "item.getValue()" do, since they don't list an attribute name. Did I miss something?

Also, the inline API documentation in for attributes like:

item: /* object */

should be:

item: Object?

(with the question mark to indicate that the argument is optional)

comment:3 Changed 11 years ago by maulin

Hi Bill,

Actually that was a tremendously bad test case for me to create. I actually named the attribute "value" as an example. (Who's on first? What's on second?) So you can access the property directly via:

item.foo

but because of laziness, you might not know the value has been initialized yet. And obviously if you wanted to do any audit logging of access, or anything else, you need an accessor to attach to. So the other way to access the attribute without the store is

item.getFoo()

In JsonRestStore?, this has the ability of automatically handling lazy loading.

Kris and I have talked about this as sugar before. Its un-necessary, but can be convenient in some circumstances.

The dot-path notation for values is critical for my application, so that I can, for example, have a grid that can read deeper into an object hierarchy than the first layer with simple declarative code. Such as:

<th field="some.deep.field"></th>

And I will certainly fix the API docs -- but I copied that directly from Kris's JsonRestStore?! Hah! :-)

comment:4 in reply to:  3 Changed 11 years ago by Kris Zyp

but the decision in the dojo community was to not do that, because of possible performance issues.

I don't think the desire to do this with JsonRestStore? was completely arbitrary; JsonRestStore? uses a schema and ensures that loaded and newly created items for a store all shared a common proto object, and consequently the schema can be used to determine getters and setters and augment the prototype object with those methods, such that all items in the store can use bean-style accessors and mutators. This means that you don't need to mixin on items, and the solution is quite efficient, and the cost is low. This is a subclass, so the cost that does exist is completely opt-in.

However, for the sake of being more generic, it might be beneficial to do this as a mixin class, that could be used by any other data store that might use schemas and ensure schema prototype for all items of the store. Other stores might do this in the future (there are already a number of subclasses of JsonRestStore?, might be nice if they could use this as well). As a mixing class, BeanStore? would not define a superclass, and to use it you would create a new store: dojo.declare("dojox.data.JsonRestBeanStore?",[dojox.data.JsonRestStore?,dojox.data.BeanStore?],{});

or

dojo.declare("dojox.data.CouchDBBeanStore",[dojox.data.CouchDBRestStore,dojox.data.BeanStore?],{});

And I will certainly fix the API docs -- but I copied that directly from Kris's JsonRestStore?! Hah! :-)

And I copied it from jsonPathStore! I will fix it to stop the mad propagation.

comment:5 Changed 11 years ago by bill

Ha ha, ok thanks guys.

As per the performance issue, I think the reasoning was that even methods in a prototype are too expensive, because if you have a "read only" structure like {age: 40, name: "John"} and you need to convert it to a first-class object with a getValue(/*String*/ attributeName) method, it requires creating a new object.

I never really believed there would be a performance issue but that was the decision.

comment:6 in reply to:  5 Changed 11 years ago by Kris Zyp

As per the performance issue, I think the reasoning was that even methods in a prototype are too expensive, because if you have a "read only" structure like {age: 40, name: "John"} and you need to convert it to a first-class object with a getValue(/*String*/ attributeName) method, it requires creating a new object.

You are certainly right, but I don't think Maulin is trying to replace the Dojo Data API, widgets generally can and should access data stores through the standard API, both for uniformity and performance. The getter setter thing would just be an additional augmentation for more convenient use for those that like bean style property access, and who are writing user-level code with a known target data store.

comment:7 Changed 11 years ago by maulin

yup

comment:8 Changed 11 years ago by dylan

If we want this to land for Dojo 1.2, we should get this committed this week... otherwise I'm going to push it out to the future.

comment:9 Changed 11 years ago by Kris Zyp

Milestone: 1.21.3

I don't have time to get this in this week. I think 1.3 is a good goal.

comment:10 Changed 10 years ago by Kris Zyp

Milestone: 1.31.4

comment:11 Changed 10 years ago by bill

Milestone: 1.4future

Looks like this is a "wontfix"? It's been dormant for almost a year. I know there were articles about doing this but outside of dojo, I think on the Sitepen site.

comment:12 Changed 6 years ago by dylan

Resolution: wontfix
Status: newclosed

Given the deprecation of dojo/data, if this is still needed on top of dojo/store, a lot of work would be needed to make it current.

Closing this one out, please let us know if you would like to get involved with dojo/store.

Note: See TracTickets for help on using tickets.