Opened 12 years ago

Closed 11 years ago

#6066 closed enhancement (fixed)

Add Jaxer Support - Callback State

Reported by: guest Owned by: anonymous
Priority: high Milestone: 1.2
Component: General Version: 1.0
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by dylan)

Dojo support in Jaxer is progressing but getting it to run servers side / client side vs in the Callback state seems to be different in approach.

Rather than clog up the existing Jaxer thread(#5878) with callback notes we have this thread. It's likely that with Jaxer revisions, findings in this area will change.

Change History (7)

comment:1 Changed 12 years ago by dylan

Milestone: 1.2

comment:2 Changed 12 years ago by guest

Just so it's not forgotten, noted in thread #5878, dojo.toJson does not respond as expected in the callback state with array items [1,2,3] being converted to {"1":1,"2":2,"3":3}. Reasons uncertain at this point.

TI.

comment:3 Changed 12 years ago by guest

Overview of transparently using Dojo in the callback state.

Lifecycle.

When we make a callback, we start by re-establishing the client-data in the callback environment. This is done by recreating and repopulating containers with information from the database. The reason we need the oncallback special event is because the first time we enter this environment, we start with a blank dom environment equivalent to "about:blank" (I think I read on a forum somewhere).

Using oncallback we check for the existence of javascript variables and if they aren't present we load them up and attach them to the "window" like global environment.

Conducting work this first time works fine as we have a full load of dojo in place to work with.

Where this next works for Jquery and currently fails for dojo is the close down of the request. As the request ends and the callback goes into a tidy up state, the "client data" is persisted to the database.

When attempts to serialize the dojo data structure are made, it currently fails and the data structure is not correctly persisted. I think in the autonomous "behind the scenes" functions it persists a half broken dojo which means that when we come back in to the callback, we find the dojo variable there but can't use it without exceptions being thrown. You can see this by finding dojo.version present but most other functions instantly throwing exceptions.

The Manual Approch

Looking into the serverFramework, the containers are persisted with a persistAll call and I think it's here that the client data is deflated ready for reloading on the next callback.

containers objects have manual calls - set and get - to allow simple name/value data storing. I thought perhaps I could push and pull the dojo data structure manually into a value to see what's going on.

function oncallback(){
  var log = Jaxer.Log;
  var container =  Jaxer["page"];					
  dojo = container.get("dojo");
  if(typeof(dojo)=="undefined"){
    djConfig = {baseUrl:"dojo/dojo/",usePlainJson: true, parseOnLoad: true};
    Jaxer.load("dojo/dojo/dojo.js");
    dojo = window.dojo;
    container.set("dojo",dojo);
  } else {
    log.trace("dojo exists");
  }
}

Here I get the page container, and use the "dojo" name to store the dojo object. What I noticed here in the logs was the "tagReferences" function failing. This function walks the JS tree making sure it can serialize the information looking for arrays and objects etc.

Hence this is where I will start looking as for reasons why we are having trouble storing the dojo object.

TI. (Tony Issakov)

comment:4 Changed 12 years ago by James Burke

Tony, thanks for the great write-up. Do you think it is worth filing a ticket with Aptana to see if we can get them to look at the issue? I've already filed one ticket with them (about getting script tags and getting the src attribute from them correctly).

If you are not comfortable opening a ticket with them, I'm happy to do so. Also, give a holler if you want your email on the cc list for this bug or if you want to have your own account in dojo's trac.

comment:5 Changed 12 years ago by guest

So I took a different approach to this and decided given I could see the dojo object there, to explore what was and wasn't working. It turns out my database persistence idea was a possible work around that failed but might be unrelated to the main problem.

I found that dojo exists along with many properties but functions weren't working. I did eventually find some that were working though and it turns out that any function that references dojo externally (as opposed to 'this') crashes. I wrote up a quick example of showing how this works.

Working Case:

var testFunc = {
	a:1,
	b:function(){
		return this.a;
	}
}

Failing Case

var testFunc = {
	a:1,
	b:function(){
		return testFunc.a;
	}
}

Note I found that the following only occurs if we load a file containing the function definitions. If we defined the above inside the "oncallback" itself, things work fine.

So calling testFunc.b() in the first case works fine in all cases. Doing the same with the second case only works the first time as we load the file and from then on it doesn't find the 'testFunc' object even though we are calling with it.

I have lodged this with Aptana as it seems a quirk of the environment more than a coding approach issue:

http://support.aptana.com/asap/browse/JXR-109

TI

comment:6 Changed 12 years ago by guest

With the fairly quiet release of Jaxer 9.5.2371 we are now up and running.

With the earlier work of establishing Dojo in the oncallback, internal references seem to now be working and hence dojo (from quick tests) seems to be working too.

comment:7 Changed 11 years ago by dylan

Description: modified (diff)
Resolution: fixed
Status: newclosed

Fixed in Aptana Jaxer 0.9.5

Note: See TracTickets for help on using tickets.