Hi Antranig,

The issue with the UIO tab rendering inside the iFrame has been fixed. But the 
new problem I'm having now seems indicating we probably reach the point that 
some framework support is needed.

The source problem is that with the fat panel, open up the iFrame, change the 
setting of "text style" or any other setting except the sliders (which is not 
slidable. That's another issue I'm working on). The error "node is null" is 
thrown @ 
https://github.com/cindyli/infusion/blob/FLUID-4525/src/webapp/framework/core/js/DataBinding.js#L64

Tracing down the debugging stack pinpoints to the function fluid.byId() @ 
https://github.com/cindyli/infusion/blob/FLUID-4525/src/webapp/framework/renderer/js/fluidRenderer.js#L599,
 where fluid.byId(finalID) returns null due to the fact that it looks for 
"theme" ID on the main page rather than in the iFrame.

By reading fluid.byId() function @ 
https://github.com/cindyli/infusion/blob/FLUID-4525/src/webapp/framework/core/js/Fluid.js#L1689-1703,
 it does allow the looking up of the given id in a different DOM object by 
providing it via the second argument of the function. This argument is simply 
not being used by fluidRenderer.js

I believe you would have some insights of a good solution to this problem.

The github branch with the working-on code: 
https://github.com/cindyli/infusion/tree/FLUID-4525

In the meantime I will be working on the slider issue which is fairly 
interesting that the slider handle is  not slidable in the iFrame but if I 
click on the handle and move the mouse cursor out of the iFrame into the main 
page, the handle is back to slidable. This prompts me like a kind of js 
detector is sort of in action at sliding which is missing from the iFrame. This 
detector thing however is pretty bizarre.

I haven't changed the name of "renderUIOptions", which I'm leaving later when 
the experiment that you suggested to combine both iframe and UIO rendering 
comes. Let me know if you already have a proper name in mind.

More fyi with IE, the implementation so far is liked by IE8 & 9, but not 6 & 7 
which throws the error and refuses the rendering.

Thanks

Cindy
On 2011-10-25, at 1:49 AM, Antranig Basman wrote:

Hi Cindy - it is great that you have got so far with this implementation. Good 
luck with resolving the remaining rendering bugs tomorrow. Unfortunately I 
don't think this current plain sailing can be completely guaranteed - since it 
is virtually certain that on some version of IE that this "jQueryless" strategy 
will break.

To recall Colin's remarks from our meeting last week, I think we are prepared 
to "soft-pedal" IE6 and IE7 compatibility issues for now, pending an evaluation 
of the needs of our userbase and the state of our resources. However, it would 
be worthwhile to try your current "free 'n easy" implementation with IE9 at 
least to see if it explodes horribly.

As Colin remarked, "this is not policy" but currently it looks like we see our 
way to thorough testing on IE8 and IE9 with at least the potential to have to 
revive earlier versions depending on conditions.

Looking forward to the final destruction of the "swappedFatPanelMapping",
Boz

PS "fluid.uiOptoins.renderUIOptions" is an odd name, and doesn't really express 
its binding to the FatPanel configuration. Perhaps it would be a good 
opportunity to continue the namespace rationalisation we started before the 
release and create a fluid.uiOptions.fatPanel namespace to mirror the other two 
configurations?

One route to making the configurations even more similar is to simply modify 
the type of "uiOptionsLoader" in the standard "inline" hierarchy. If it can be 
made to take responsibility for iframe loading and rendering as well as just 
standard template loading, and delay the firing of its 
"onUIOptionsTemplateReady" event until all this is done, we could keep the 
overall "inline" arrangement and therefore save on even the remainder of 
"swappedFatPanelMapping".

This is just a suggestion and it may not prove to be practical, but I think it 
is worth a try

On 24/10/2011 13:46, Li, Cindy wrote:
Hi Antranig,

The issue with the incorrect iframe document object that was passed into 
renderer has been resolved. The current status is that the UI Options interface 
is successfully rendered into iFrame by using the jQuery and infusion from the 
outer world although the UIO interface is not fully correct yet with all the 
settings showing up in one tab rather than being properly distributed to each 
tab. But it's good that the rendering part that we had expected the difficulty 
on is almost done. :) BTW, it's a lovely surprise that even if the entire 
jQuery inclusion, not only infusion, has been removed from iFrame, the 
rendering is still able to be performed.

I will continue looking into the tab issue tomorrow and afterwards would be 
utilizing the uiEnhancer from the main page to manipulate both inner and outer 
worlds.

Here's the github branch with the latest code: 
https://github.com/cindyli/infusion/tree/FLUID-4525

Cheers

Cindy


_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Reply via email to