Property access needed for all properties buried behind JSON storage

[seanupton]

We need/want property access for r/o access to the things now abstracted behind stored JSON for due date and notification rules.

Uses:

• Indexing
• Search by email notificaiton daemon
• View of rules outside of javascript powered forms.

Optional scope: setter access to properties.

Ideally JSON is used primarily as an interchange format here, for form use, not for internal programmatic use in python. We need to have a discussion about the contracts spelled out in the interfaces, since so much of the system aside from forms is going to assume attribute-level access to the data abstracted/buried inside stored JSON.

The changes to the schema suggest to me that we need to have some kind of proxy interface (similar to current) for the forms, and a push of the content storage interface closer to original specification, but I could be persuaded otherwise (e.g. 'this is a pain, let's create some kind of adapter interface').

[seanupton]

@aclark4life My current preference is to avoid storing the JSON, and use either z3c.form data converter or some kind of adapter for custom form that allows us to store the compositions abstracted behind JSON now as native Python data-types.

[garbas]

+1 data converter was removed since i got some problem with registering it to correct interfaces. also in previous interaction we were still exploring UI/UX. will add it back and make sure it converts json<->dict like it does QueryStringDaaConverter in p.a.widgets.

[garbas]

i would just like to leave here a remark that current code is a work in progress. none of the names should stay as they are. also code placement is there where it was most conveniently to put it at the time of writing.

reason behind json or dict schema is that zope.schema is not the best (easiest to use) tool to describe data structures. especially whole rewriting process is quite tedius and usually requires a lot of time. using more free form data sctructures (json/dict) allows me/us to experiment faster before we settle on certain format. using names like field1, field2, ... forces me to come back and give meaninful names at the end of the design iterations.

before we go back and fix names and add schemas i would like us to finish few more things:

• indexes
• inheriting values from taskplanner
• fully finalize ui/ux of our custom widgets
• at least add some tests for core functionalities

do you agree with this?

[aclark4life]

@garbas Thanks! I fully understand the need for "temp vars" until we are "done" and I'm certainly fine with more free form data structures (json/dict) > zope.schema. @seanupton Any concerns? And @garbas I think indexing is a good next thing to focus on.

[garbas]

i forgot one more thing we need to add ... p.a.event integration for start/end field. and i would go with p.a.event since they already solved timezone related problems there and we can avoid solving them again.

[aclark4life]

+1; if it gives us any trouble we can always create our own fields and punt on TZ

[garbas]

with above helper method i would close this issues and open separate tickets for things we discussed (#31, #35, #36, #37). reopen if i'm doing something wrong.