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
