FLUID-4525: Update of simplifying fat panel
cli at ocad.ca
Wed Oct 26 21:17:17 UTC 2011
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.
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",
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:
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work