Seadragon - iFrame - Fullscreen, Oh My!
A little challenge for the budding Seadragon Community.
I am developing a Seadragon based application that I is going to be used both as a component for my personal website, and as widget for others.
The application is going to be managing large sets of data for use with this component/widget, therefore I am going to be needing to send and receive data from my server on load, and potentially through AJAX calls.
Anyway to the point of the question. It seems to me that the best way for a widget to avoid conflicts of other javascript libraries etc is to load it in an iFrame. Seadragon seems to work fine in an iFrame in it's basic form, but I would like to be able to full-screen the iFrame container from within the iFrame. (I can see you shaking your head already.) :)
So essentially, even though Seadragon would be loaded within an iFrame, do you have any thoughts on if I could modify the parent iFrame and then Seadragon's div container.
Anyway, this is sort of obscure, but if any of you have experience communicating between iFrames, or if there is code within Seadragon to help this along, please give me your thoughts.
If I am simply crazy, let me know too. :D
Sincerely,
Dustin
I am developing a Seadragon based application that I is going to be used both as a component for my personal website, and as widget for others.
The application is going to be managing large sets of data for use with this component/widget, therefore I am going to be needing to send and receive data from my server on load, and potentially through AJAX calls.
Anyway to the point of the question. It seems to me that the best way for a widget to avoid conflicts of other javascript libraries etc is to load it in an iFrame. Seadragon seems to work fine in an iFrame in it's basic form, but I would like to be able to full-screen the iFrame container from within the iFrame. (I can see you shaking your head already.) :)
So essentially, even though Seadragon would be loaded within an iFrame, do you have any thoughts on if I could modify the parent iFrame and then Seadragon's div container.
Anyway, this is sort of obscure, but if any of you have experience communicating between iFrames, or if there is code within Seadragon to help this along, please give me your thoughts.
If I am simply crazy, let me know too. :D
Sincerely,
Dustin
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
The company marked this question as answered.
The best answer from the company
-
Great stuff guys. Just to chime in with the "official" word:
We don't support an <iframe> embed because we -- inside our own code -- can't access the outer DOM cross-domain, which means we can't do full-page mode, as that involves us manipulating the size and position of the <iframe> within your DOM.
You, on your page, can resize the <iframe> yourself, which is what you did here using the x library. For a general-purpose embed though, we need to contain this logic within our code.
One possible workaround we've been aware of but haven't had time to implement is to launch a new window for full page instead of modifying the existing one. The new window can have no chrome, etc., and pressing the full page button in there would simply close the window.
In the meantime though, I do have to agree with Eric that you really don't have to worry too much about conflicts; we do namespace the code, and we took extra care to never modify any global variables or DOM properties outside of our own containers. But I can understand if you need to use <iframe> for other reasons.
I’m appreciative of community help!
The company says
this answers the question
-
Inappropriate?You know, In thinking about this further, I think it would be much more simple to simply change the control to open a new window with the full screen mode set. That way I can keep it really simple. Though, if any of you have any ideas on how you could create a full-screen type container through an iFrame I would be interested to hear about it.
-
Inappropriate?Dustmoo, hi.
It is always tempting to use iFrames because of the simplicity. It is a good way to get started.
But ultimately down the road you will wish to use DIVs instead of iFrames. Communicating between an iFrame and the hosting document is clumsy and time-consuming, and messy when implemented cross-browser.
So for instance, you have a web page with a list of pictures. You want to click a picture and display it in Sea Dragon in an iFrame. Communicating between your list of pictures and the iFrame is not good clean fun.
As far as eliminating conflicts with other javascript libraries, look at the Sea Dragon code. They have implemented namespacing in their javascript which completely eliminates the possibility of conflicts. You will see stuff like Microsoft.SeaDragon.Viewer.showSomething(). There is no special meaning to this, it is just a convention. It could just as well be Gork.Blimp.Foo.barm(). For there to be a conflict you would ostensibly need a library from the Gork company, for a product called Blimp, with an object called Foo, and a method called barm. See what I mean?
- ej -
Inappropriate?Dustmoo, see my previous response. Here is an example using a DIV rather than an iFrame. There are four Sea Dragon buttons in the lower-right corner. If you click the right-most button, it will go full screen:
http://68.178.240.17/wkj/
Regards,
- ej -
Inappropriate?Eric,
Thanks for that humbling example. :D (Love the resizable div)
I love what you did with your div. So perhaps I can pick your brain a little.
Essentially what I am doing is using Seadragon to rebuild the flash-based map application located at http://www.discoverymap.com. (pick any market for an example)
So, basically I have a image (a map in this case) and am going to use overlays to notate business locations.
So, there is data that I have to manage here, lots of overlays potentially that will have to pull from a database for the related ad data.
This means that my application will need to communicate with my database through hopefully ajax calls, and my problem currently, is that if other users embed the java in their own site as a widget, current AJAX conventions will limit the type of calls I can make back to my database.
So, unless I can think of another way, I may have to stick to an iframe because of the complexity of my app.
Thanks for your feedback though!
Dustin
-
Inappropriate?Dustin:
Sounds like that may be the case. In your case it seems an iFrame would be the most convenient method.
There is a way to make your iFrame go full screen from within the iFrame:
http://www.cross-browser.com/x/exampl...
In this demo by Mike Foster, several windows containing iFrames will open up when you go to this URL.
The bottom-most window is labelled xMenu6. In the upper right-hand corner of that window there is a maximize-restore button.
1 person says
this answers the question
-
Inappropriate?Eric,
This is a fantastic resource! Thank you! :)
Much obliged. I'll have to post the new app when I am done.
Cheers!
Dustin
I’m grateful for the help.
-
Inappropriate?Dustin:
This is answered, is it not? If so then mark it. Also please donate to Mike Foster if you are willing so that he can continue providing cross-browser.com
Thanks. -
Thanks.. still getting the hang of get satisfaction.. I appreciate your help. -
Inappropriate?Great stuff guys. Just to chime in with the "official" word:
We don't support an <iframe> embed because we -- inside our own code -- can't access the outer DOM cross-domain, which means we can't do full-page mode, as that involves us manipulating the size and position of the <iframe> within your DOM.
You, on your page, can resize the <iframe> yourself, which is what you did here using the x library. For a general-purpose embed though, we need to contain this logic within our code.
One possible workaround we've been aware of but haven't had time to implement is to launch a new window for full page instead of modifying the existing one. The new window can have no chrome, etc., and pressing the full page button in there would simply close the window.
In the meantime though, I do have to agree with Eric that you really don't have to worry too much about conflicts; we do namespace the code, and we took extra care to never modify any global variables or DOM properties outside of our own containers. But I can understand if you need to use <iframe> for other reasons.
I’m appreciative of community help!
The company says
this answers the question
Loading Profile...



EMPLOYEE