[Sugar-devel] sugar-web - API for storing data

Manuel Quiñones manuq at laptop.org
Tue Sep 3 16:28:50 EDT 2013


Two more comments on localStorage.

1. First I found the "storage" signal that is supposed to be emitted
when localStorage changes.  And I said, great, let's take adventage of
it to save to the datastore.

http://dev.w3.org/html5/webstorage/#localStorageEvent

But turned out it can't be used, because of
http://stackoverflow.com/questions/4679023/bug-with-chromes-localstorage-implementation

2. I tried to overload setter and getter methods of localStorage, but
there is no way to do that in JS (yet, search for dynamic proxies).
You can define a setter and getter for one property, but not for any.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Obsolete_Pages/Creating_New_Objects/Defining_Getters_and_Setters

Anyways, explicit is better than implicit, and is good to not mess
standard objects.


2013/9/3 Manuel Quiñones <manuq at laptop.org>:
> I'm back into this.  After discussing with Daniel some weeks ago, we
> agreed that the activity is the one who knows if it needs to store,
> not the toolkit.  So we prefer to let the activity developer do the
> storing, instead of doing when the activity goes to the background.
>
> Also the API I have proposed at that time was only for text data.
> Storing in web activities is a bit more complicated because there is
> no file descriptor to write to.  On the other hand, most webapps store
> text in JSON format
>
> So now I'm proposing a helper class called JSONStore that uses the
> standard localSorage.  I made it work in Get Things Done activity.  I
> will send a PR to add it to sugar-web.  Here it is:
>
> https://github.com/manuq/gtd-activity/blob/master/js/jsonstore.js
>
> An adventage of using localStorage is that it persists in a normal
> browser as well.  See http://manuq.github.io/gtd-activity/
>
> The usage is like this:
>
> myStore = jsonstore.JSONStore();
>
> myReadyCallback = function () {};
> window.addEventListener('storeReady', myReadyCallback);
>
> var value = myStore.read('key'); // read
> myStore.write('key', newValue); // write
>
> // Or use localStorage directly, and then call save():
>
> var value = localStorage['key'];
> localStorage['key'] = newValue;
> myStore.save();
>
>
> 2013/8/16 Daniel Narvaez <dwnarvaez at gmail.com>:
>> Hey,
>>
>> It seems be have two (mostly) independent questions here
>>
>> - How do we notify an activity of certain global events, being them
>> onPause/onStop or onRead/onWrite.
>>
>> If we want them to be passed in activity.setup() I think we should use an
>> object, like {"onSomething": ..., "onSomethingElse":..}. That will allow to
>> subscribe only to some of the available events. With two events that would
>> probably be overkill but if nothing else I think onStart/onPause/onStop
>> should be supported, even if we also have onRead and onWrite. They are
>> needed for more than writing to the datastore.
>>
>> Though, any reason to not use custom DOM events? This seems exactly the use
>> case they are designed for.
>> http://www.w3.org/TR/DOM-Level-3-Events/#extending_events-Custom_Events
>>
>> - Should we have onRead and onWrite events.
>>
>> What you are proposing is a bit different from what you have implemented. In
>> your patch onWrite does only a couple of things
>>
>> 1 Proxy both onPause and onStop to the same write method.
>> 2 Close the activity in onStop.
>>
>> I think 1 is not enough to justify onWrite existence, it's easy enough for
>> the concrete activity to do it if wanted.
>> About 2, I think the concrete activity needs more control on when it is shut
>> down. It might want to do so after having written some file outside the
>> journal, for example.
>>
>> Now, you are proposing that we pass metadata in both read and write,
>> similarly to the gtk API. But what about the data? I don't see exactly where
>> you are going with this, so it would helpful if you could sketch out that
>> API.
>>
>>
>> That was a bit long, to summarize:
>>
>> * I think onStart/onPause/onStop should be there in any case.
>> * On the top of those, your current onWrite implementation adds too little
>> to be justified.
>> * I tend to think we should use custom DOM events here instead of callbacks,
>> if possible.
>>
>> On 16 August 2013 14:01, Manuel Quiñones <manuq at laptop.org> wrote:
>>>
>>> This is one of the most important APIs we will have, so I would
>>> like to open discussion on it.
>>>
>>> In GTK activities, the activity developer subclass Activity, and
>>> override read() and write() methods.
>>>
>>> In web activities, we don't have that kind of hierarchy.  Instead, the
>>> activity developer imports 'activity/activity' module, and calls
>>> activity.setup() .  Then she/he can use activity.getDatastoreObject()
>>> to read and write.
>>>
>>> In GTK activities, 'read' is called at startup and 'write' is called
>>> when the activity goes to the background or when it stops.  Recently,
>>> I added in sugar-web those notifications, with the intention to make
>>> web activities behave like GTK ones.
>>>
>>> I provided an initial patch and dnarvaez proposed another option:
>>> https://github.com/sugarlabs/sugar-web/pull/74
>>>
>>> So we can:
>>>
>>> - Let web developers connect to the 'pause' and 'stop' notifications,
>>>   and use the activity datastore object directly. Pro: is more
>>>   flexible.  Con: more work in the activity side: error handling,
>>>   datastore object handling.
>>>
>>> - Subscribe 'read' and 'write' functions in activity.setup() .  They
>>>   will be called as expected, like in GTK.  'read' will have a JSON
>>>   string as argument.  'write' must return a JSON string.  Pro:
>>>   simpler approach.  Con: less flexibility in the activity side.  A
>>>   mockup can be found in this comment:
>>>
>>> https://github.com/manuq/sugar-web/commit/3c2420f59c9aa8df44d2c0d639fe37b4af63f9fb#commitcomment-3872770
>>>
>>> Thoughts?  Any other ideas?
>>>
>>>
>>> --
>>> .. manuq ..
>>>
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>>
>>
>> --
>> Daniel Narvaez
>
>
>
> --
> .. manuq ..



-- 
.. manuq ..


More information about the Sugar-devel mailing list