Creating Items when using JsonRest-store about dojo-calendar

[damiengarbarino]

Hi,

The interactive creation of items has changed in 1.9 to better handle the asynchronous stores.

Before when the user was creating an item through a gesture, the data item was directly added to the store.

There were two issues with that behavior:

• if the store is remote and slow, the user is not seeing any graphic feedback during a long time during the gesture. It looks like nothing happened.
• the user was not able to cancel the gesture before adding the item to the store.

In 1.9, the data item, when created, is added to the store at the end of the gesture, if it has completed successfully. As the id is the only way to identify a data item, it indeed need to have it to be properly managed by the calendar.

With that said, I don't think that this behavior will change but we can look for solutions for your issue.

I need to check with the code, but it may be possible to assign a dummy ID in your function that creates the data item and then, in your store.add, remove this ID using aspect.before for example.

I need more time to further investigate if something is needed in the library.

Regards,

Damien

[cjeriksson]

Hi Damien,

Thanks for your quick response. I had thought about doing what you suggest - but unless the Calendar will change the ID back to what is returned by the store once the add is completed it will be broken (the Calendar would keep thinking that the items ID is when it really is and updates will fail. Right ?

Another point to consider is that it is in fact incorrect to assume having an ID upon creation, at least when using JsonRest. JsonRest will issue a POST if the ID is missing and a PUT if the ID is present.

I think the Calendar itself should assign a temporary ID upon creation and then change that ID to whatever is returned by the stores add-method when it completes.

Thanks,

Johan

[damiengarbarino]

Hi,

Yes you are correct, this was the lead I was investigating.

I have still some issues with Observable implementation because the observer is notified before the promise on store.add. But the investigation is still going on.

Thanks,

Damien

[damiengarbarino]

I made a first fix, it would be great if you can try it.
It's not perfect though, but I don't have a better solution yet.
If the ID changes, the calendar is notified of an addition and then in the store.add() promise callback, I remove the extra item.
Drawback: it means 2 layouts. But it should work. I will improve code later if this is OK.

Fixed code is in branch issue61: https://github.com/damiengarbarino/dojo-calendar/tree/issue61

Regards,
Damien

[cjeriksson]

Thanks Damien - I will try it out and let you know in a few hours.

Really appreciate your responsiveness ! Big thanks!

[cjeriksson]

Just tested it, unfortunately I am getting an error:

Uncaught Error: InvalidStateError: DOM Exception 11 JsonRest.js:110
declare.put JsonRest.js:110
store.(anonymous function) Observable.js:155
declare.add JsonRest.js:132
store.(anonymous function) Observable.js:159
declare._onItemEditEnd ViewBase.js:2185
declare._endItemEditing ViewBase.js:2148
declare._editingMouseUpHandler Mouse.js:277
lang.hitch

It is attempting to serialize the storeItem by calling JSON.stringify on it - and that generates this exception.

Thanks,

Johan

[cjeriksson]

Tried this in Firefox (the previous test was done with Chrome) - and there it succeeds on the client-side but then my server-side fails because there are unknown properties in the incoming JSON-object (there was one called 'fired' at least - which made the serialization code barf). So I assume the storeItem is a mix of not just what has been declared by the user but also some internal properties which shouldn't really be there - and one or more of those are messing up JSON.stringify in Chrome....

[damiengarbarino]

Hum, this is quite strange. The item returned by the calendar is updated using the StoreMixin.renderItemToItem(). So no extra property should appear.
In the asynchStore sample, if I display the JSON, it is well formed.

[cjeriksson]

Damien,

I think I know what the issue is. I can see that the object that reaches my store is a mix of a Deferred and the actual item. Looking at line 117 of StoreMixin.js we see:

        return lang.mixin(store.get(renderItem.id), item);

The store.get here will return a Deferred - so that explains it. I can also see that my server gets hit with a GET-request for an item with ID="undefined". This lookup should be unnecessary in this particular case since we know the item doesn't exist yet.

Thanks,

Johan

[damiengarbarino]

Nice catch.

I will look to fix this tomorrow.

Using the Jsonrest store, this is indeed different.

I need to set up a complete environment to test properly.

Thanks for the investigation,

Damien

D.

On Thu, Jun 13, 2013 at 7:11 PM, Johan Eriksson [email protected]:

Damien,

I think I know what the issue is. I can see that the object that reaches
my store is a mix of a Deferred and the actual item. Looking at line 117 of
StoreMixin.js we see:

    return lang.mixin(store.get(renderItem.id), item);

The store.get here will return a Deferred - so that explains it. I can
also see that my server gets hit with a GET-request for an item with
ID="undefined". This lookup should be unnecessary in this particular case
since we know the item doesn't exist yet.

Thanks,

Johan

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/61#issuecomment-19407071
.

[cjeriksson]

No problem, thanks again for acting so quickly on this.

Cheers,

Johan

[damiengarbarino]

Johan,

I made a quick fix for the mixin issue you are facing.

Unfortunately I cannot test for real yet as my env is not ready.

Thanks,

D.

On Thu, Jun 13, 2013 at 7:24 PM, Johan Eriksson [email protected]:

No problem, thanks again for acting so quickly on this.

Cheers,

Johan

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/61#issuecomment-19408490
.

[cjeriksson]

Is it checked in ? If so I can try it out on my end.

[damiengarbarino]

Yes it is:
bf7798a

D.

On Fri, Jun 14, 2013 at 10:37 AM, Johan Eriksson
[email protected]:

Is it checked in ? If so I can try it out on my end.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/61#issuecomment-19445423
.

[cjeriksson]

I just tested it - there still seems to be a couple of issues.

First, in ViewBase._onItemEditEnd - line 2251:

                    when(store.add(storeItem), lang.hitch(this, function(res){

It breaks because the temp-ID is still assigned and thus there will be a PUT-request issued instead of a POST.

I fixed this by adding this before (you can probably fix it in a cleaner way):

                    if (oldID.indexOf('_tempId_') == 0) {
                        delete storeItem.id;
                    }

That takes care of the ID and my item gets created in the store - however, after that I get another issue:

Uncaught TypeError: Cannot read property 'style' of null dom-style.js:303
setStyle dom-style.js:303
declare._createRendering SimpleColumnView.js:584
declare.refreshRendering SimpleColumnView.js:577
declare.validateRendering _Invalidating.js:53
lang.hitch lang.js:375
TypeError {} "TypeError: Cannot read property 'offsetWidth' of undefined
at declare._layoutInterval (http://localhost:8080/js/dojo-1.9.0/dojox/calendar/SimpleColumnView.js:1458:40)
at declare._layoutRenderers (http://localhost:8080/js/dojo-1.9.0/dojox/calendar/ViewBase.js:1097:11)
at inherited (http://localhost:8080/js/dojo-1.9.0/dojo/_base/declare.js:189:30)
at declare._layoutRenderers (http://localhost:8080/js/dojo-1.9.0/dojox/calendar/ColumnView.js:248:9)
at declare._refreshItemsRendering (http://localhost:8080/js/dojo-1.9.0/dojox/calendar/ViewBase.js:898:9)
at inherited (http://localhost:8080/js/dojo-1.9.0/dojo/_base/declare.js:189:30)
at declare._refreshItemsRendering (http://localhost:8080/js/dojo-1.9.0/dojox/calendar/ColumnView.js:234:9)
at declare._refreshItemsRendering (http://localhost:8080/js/dojo-1.9.0/dojox/calendar/CalendarBase.js:377:22)
at declare._updateItems (http://localhost:8080/js/dojo-1.9.0/dojox/calendar/StoreMixin.js:218:11)
at lang.hitch (http://localhost:8080/js/dojo-1.9.0/dojo/_base/lang.js:375:55)

[cjeriksson]

FYI - I see a similar issue (with the mixed in Deferred) when I try to edit an existing item.

[damiengarbarino]

Hi Johan,

I set up my environment to have a REST service running. So I was able to run/debug/fix the Jsonrest use case.

So, on my side interactive creation without an ID and editing gesture are working properly.

Concerning my refresh problems related to Observable, I added a workaround that is using a sub class of JsonRest, see new tests/jsonrest.html sample.

This subclass is not mandatory, it will work with the default Jsonrest store but you'll experience a 2 steps layout: one with the new item added (new because of new ID) and the second to remove the temporary renderer.

With the subclass, the internals are synch when Observable is notifying the calendar and a single layout is done.

It should work for you, could you confirm?

Regards,

Damien

[cjeriksson]

Hi Damien,

This seems to be working beautifully now ! Thank you very much - I cannot stress enough how much I appreciate your responsiveness on this matter.

Hope you're having a great weekend,

Johan

[damiengarbarino]

Great news!

Thanks for pointing out this issue.

Now I need to merge in the master and next Dojo 1.9 release.

Regards,

Damien

On Sun, Jun 16, 2013 at 6:01 PM, Johan Eriksson [email protected]:

Hi Damien,

This seems to be working beautifully now ! Thank you very much - I cannot
stress enough how much I appreciate your responsiveness on this matter.

Hope you're having a great weekend,

Johan

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/61#issuecomment-19514224
.

[damiengarbarino]

Fixed in master and Dojo 1.9 branch (will be in 1.9.2 release).