Chrome multiple HTMLPane concurrency problem.

[jason.saunders]

If a VLayout, for instance, contains two members that are HTMLPane's using contentsType fragment where the contentsURL points to pages that return smartclient content, then, when running google chrome, often the smartclient content of the first member appears in the second member.

The behaviour is intermittent but occurs for me around every 2nd or 3rd refresh of the page.

Tested using google chrome 13.0.782.41 beta-m.

This does not appear to occur in Firefox v4 or IE9.

Test case as follows;

Primary page;

isc.VLayout.create({
    defaultHeight:"100%",
    defaultWidth:"100%",
    members:[
        isc.HTMLPane.create({
            showEdges: true,
            contentsURL:"test2.htm",
            contentsType:"fragment"
        }),
        isc.HTMLPane.create({
            showEdges: true,
            contentsURL:"test3.htm",
            contentsType:"fragment"
        })
    ]
    })

test2.htm

This is Test2
<script>
isc.DynamicForm.create({
    top: 20,
    fields:[{ title: "Test2", name: "test" }]
})
</script>

test3.htm

This is Test3
<script>
isc.DynamicForm.create({
    top: 20,
    fields:[{ title: "Test3", name: "test" }]
})
</script>

When running test case, the first member will contain the text "This is Test2" but with no Test2 field - therefore proving the content loaded OK but just the smartclient content failed.

The Test2 field will then appear in the test3.htm member and the Test3 field will not be shown.

On some occasions the reverse occurs where the Test3 field appears in the test2.htm member.

Using SmartClient 8.0 SmartClient_SC_SNAPSHOT-2011-06-26_LGPL

[jason.saunders]

Isomorphic, do you have any advice on this one as it is a bit of a critical problem?

I'm thinking that I could derive a class from HTMLPane which in it's initWidget function get's the content via a (synchronous) RPCManager call and does a setContents with the response. Would that get round the concurrency issue?

[jason.saunders]

I'm thinking that I could derive a class from HTMLPane which in it's initWidget function get's the content via a (synchronous) RPCManager call and does a setContents with the response. Would that get round the concurrency issue?

To answer my own question (I think) - no that won't work as setContents is just a Canvas member, not a member of HTMLFlow, so it does not evaluate the smartclient content in the way the HTMLFlow contentsURL handling does.

So I'm still stuck. Any clues?

[jason.saunders]

Moved to a ViewLoader based system. ViewLoader also seem to have problems on Chrome as well where the '...special variable "viewLoader"...' is apparently trashed.

But I was able to mitigate that by having unique references to the ViewLoader instance rather than using viewLoader variable.

Isomorphic, there *are* bugs here for Chrome, but I'm happy with what I've got now.

(PS this is my 3rd thread and so far zero replies to anything)

[Isomorphic]

You're using a beta of Chrome, that's probably the actual problem. Testing things on a beta version of a browser only is a good way to ensure the absence of replies :)

Also, the docs for HTMLFlow tell you not to load components that way, and the docs for ViewLoader refer you to the SmartClient Architecture topic - be sure you've read and understood this, because the road you're going down is wrong almost all of the time.

[jason.saunders]

You're using a beta of Chrome, that's probably the actual problem. Testing things on a beta version of a browser only is a good way to ensure the absence of replies :)

I take your point, but pretty sure other members on my dev team have the same problem using chrome stable release. I will check later today.

Also, the docs for HTMLFlow tell you not to load components that way, and the docs for ViewLoader refer you to the SmartClient Architecture topic - be sure you've read and understood this, because the road you're going down is wrong almost all of the time.

/me embarrassed/ Yes, now that I read overview on HTMLFlow it does say that - although confusingly HTMLFlow has a captureSCComponents attribute which seems counter to the overview. Still ViewLoader is working for me and, I believe, is the right approach for the application under development which is indeed intended to have "hundreds of views" as per the "Segmenting very large Applications" section of SmartClient Architecture docs.

Like I say ViewLoader still seemed to have problems with Chrome but will confirm if it happens on stable release.

[Isomorphic]

There are extraordinary edge cases where capturing components from HTML content makes sense, it's a short term bridge for legacy architectures.

Note that the SmartClient architecture topic still does not have you using ViewLoader for large applications.

[jason.saunders]

There are extraordinary edge cases where capturing components from HTML content makes sense, it's a short term bridge for legacy architectures.

Note that the SmartClient architecture topic still does not have you using ViewLoader for large applications.

Say for the sake of argument I was designing a "portal" style application where each portlet could contain an arbitrary smartclient "application" and the user can choose to have any number of collections of portlets making up a "page".

What is the recommended method of obtaining the individual portlet applications? FileLoader.loadJSFiles()? ViewLoader? I'm struggling to see a distinction between the two in this context.

If, for instance, I look at your standard PortalLayout/Portlet design I would naturally just set the src on a portlet to the application URL. You're saying this is wrong or at least an "extraordinary edge case"? If so what would be the correct model using PortalLayout/Portlet where the content of each Portlet is smartclient content?

[Isomorphic]

A ViewLoader loads one screen. Files can contain any number of screens.

A Portal could be done either way. To figure out the right approach you have to think through who's providing the portlets (separate parties, separate teams within each company, etc).

But at most, a Portal would be using ViewLoader, not an HTMLPane that extracts SmartClient components. This last capability is just something we have in our arsenal for dealing with very very crufty old systems where almost nothing can be changed and yet SmartClient has to be inserted.

[jason.saunders]

Many thanks, I understand the distinction now between ViewLoader and FileLoader.loadJSFiles and will use them as appropriate.

Definitely not using HTMLPane unless I find something suitably crufty :)

Tried ViewLoader with chrome stable release and was not getting the issue above where the viewLoader special variable was trashed.

[mikeshimura]

Could you show me code

Moved to a ViewLoader based system. ViewLoader also seem to have problems on Chrome as well where the '...special variable "viewLoader"...' is apparently trashed.

But I was able to mitigate that by having unique references to the ViewLoader instance rather than using viewLoader variable.

Isomorphic, there *are* bugs here for Chrome, but I'm happy with what I've got now.

(PS this is my 3rd thread and so far zero replies to anything)

I have same problem with chrome and ViewLoader.

Could you show me javascript code to create ViewLoader instance.

[jason.saunders]

In essence pass the ID of the ViewLoader instance as a parameter on the view URL and in the javascript returned by the handler of that URL call setView on the passed ID, instead of using the "viewLoader" special variable the documentation refers to.

var vl = isc.ViewLoader.create({...});
vl.setViewURL(url, {viewloaderID: vl.ID} );

Then in the javascript returned by url;

var view = smartclient stuff ...
<viewloaderID>.setView(view);

Like I said earlier on this thread I could not replicate a problem using the stable version of Chrome at the time, and since I had put the code above into our app already I stuck with it - so not sure if using the viewLoader variable is actually a genuine problem.

If you are having a problem I recommend you create a test case and submit to isomorphic so they can fix it properly.