Bugzilla – Full Text Bug Listing
| Summary: | Investigate how to avoid requiring API key for remote Dojo | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Will Smythe <smythew> | ||||||
| Component: | EDT | Assignee: | Huang Ji Yong <hjiyong> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P1 | CC: | chenzhh, dan.darnell, hjiyong, svihovec | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 369445 | ||||||||
| Attachments: |
|
||||||||
|
Description
Will Smythe
The Google map is still part of the Dojo Sample. I don't see the relationship between the Dojo libraries hosted on Google and the Google Map widget. The Google Map widget uses a different set of .js files and does not require an API key. It was shipped in the Dojo samples project because at the time this was the easiest way to ship it. There is a work item to pull the Google Map widget into its own library (which is where it belongs) - the widget will continue to reference the same .js files it does today (i.e. Google Map specific js files hosted on Google). changing from defect to enhancement (work item) This enhancement specifically relates to the need to reduce number of files deployed for even a basic app. I investigated the problem, and updated the code to the same approach as we did for AOL in RBD - add below tag to import the JS directly instead of loading the JS by Google loader. <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/dojo/1.6.1/dojo/dojo.xd.js"></script> It works for FF & WebKit, but it has problems in IE. It seems that it's caused by JS load problem. Jiyong is working with me for it now. BTW, we had more discussions in defect #60859 in RTC. Simply update the includeDojo.html could not solve the problem in IE (js files have not been completely loaded while trying to call the functions), more elegant way is reading the contents of file includeDojo.html and directly output to the generated handler file. Jiyong is the HTML generator owner, and he will find a better way to include the file in handler file. Created attachment 209212 [details] Design Hi Guys, I investigate this problem together with bug 364295, because both problems are related to the html generator of includeFile. Both problems can be solved by using RBD's approach which will paste the html content of the includeFile to the generated HTML. But this method require the html generator to have the ability to access the file IO. Thus, the plugin have to depend on eclipse IDE which will break the rule of generator and make it unable to use in command line. I find an alternative method to fix this problem without reading the file content in generator time. It will parse the includeFile content to extract script tag and load the script appropriate. Please check the pdf file for detail. I can't decide which method to take. Welcome for comments. The last solution is to rewrite the includeFile to make it loaded synchronously. Then we can define a rule for includeFile for user to comply for. Can you attach the proposed includeDojo.html file from comment 5, or the latest version of the file that matches the design document? Can you elaborate on why Eclipse File IO is required to read the content of the includeDojo.html file? I believe we have File Locators that work off of IFile and File, which means we should be able to resolve the file and read the content using Java File IO. Assuming we did figure out a way to read the file content using Java File IO, would we modify deployment to add the content of all includeFiles directly to the HTML file? Does RBD add the content of all includeFiles directly to the HTML file, or is it hard coded to do this just for includeDojo.html? For the proposed solution of parsing the include file to extract the script tags, would this parsing happen during deployment or at runtime? I believe it would be at runtime, which I assume means a general solution for processing all 'includeFile' attributes, and not just includeDojo.html? For the solution proposed in comment 9, can you describe this in more detail? What is the rule that the user must comply with? NOTE: The defect mentioned in comment 8 is 364925, not 364295 Hi Brian, Thanks for your reply. Firstly, I must clarify the design document aims for all includeFile including includeDojo.html. (In reply to comment #10) > Can you attach the proposed includeDojo.html file from comment 5, or the latest > version of the file that matches the design document? Attached the new includeDojo.html for remote Dojo ----------------------------------------- > Can you elaborate on why Eclipse File IO is required to read the content of the > includeDojo.html file? I believe we have File Locators that work off of IFile > and File, which means we should be able to resolve the file and read the > content using Java File IO. I have an email thread from Joe when starting HTML gen work, he said "The projects can't have any references to eclipse UI or core and cannot have an activator. The reason is these project will be used in SDK mode and SDK should not rely on any non EDT eclipse API's." We cannot get the file path of includeDojo.html by pure Java IO. We must rely on eclipse to get the workspace path, dependent project etc. (FileLocator as you said). A possible solution may be transfer the path information to html generator by parameters. Which meas that we should add more parameters to the construction function of the generator. We can look into this solution if we decide to go this way. ----------------------------------------- > Assuming we did figure out a way to read the file content using Java File IO, > would we modify deployment to add the content of all includeFiles directly to > the HTML file? Does RBD add the content of all includeFiles directly to the > HTML file, or is it hard coded to do this just for includeDojo.html? RBD add the content of all includeFiles directly to the html file, not just for includeDojo.html. We would like to do the same in EDT. ----------------------------------------- > For the proposed solution of parsing the include file to extract the script > tags, would this parsing happen during deployment or at runtime? I believe it > would be at runtime, which I assume means a general solution for processing all > 'includeFile' attributes, and not just includeDojo.html? Parsing happens in runtime, and it is for all 'includeFile' attribute. ----------------------------------------- > For the solution proposed in comment 9, can you describe this in more detail? > What is the rule that the user must comply with? The rule may be: The script link in the 'includeFile' must written in a dynamic script tag manners. Such as var script = document.createElement("script"); script.type = "text/javascript"; if (script.readyState){ //IE script.onreadystatechange = function(){ if (script.readyState == "loaded" || script.readyState == "complete"){ script.onreadystatechange = null; // The logic should go here callback(); } }; } else { //Others script.onload = function(){ // The logic should go here. callback(); }; script.onerror = function(){ console.log("load " + this.src + " fail"); } } script.src = "/" + egl__contextRoot + "/" + url; document.getElementsByTagName("head")[0].appendChild(script); Additionally this load function should be included in the runtime such as egl.load(file, callback). So when user is writing a includeFile to link to an external script file, they should write in this manner egl.load("mysrc.js", callbackFunc); ----------------------------------------- > NOTE: The defect mentioned in comment 8 is 364925, not 364295 Sorry for the mistake. Created attachment 209302 [details]
New includeDojo.html
In the design document, it states, "The script tag <script src="src.js" /> is
loaded asynchronously in IE when using document.write"
In the attached HTML file (includeDojo.html), it appears that the script tag is no longer using document.write. Is the problem related to the document.write that is used in the overall HTML file to include all dynamically loaded content?
if(isLastFile){
document.write(htmlString + "<script>egl.load(RUI_RUNTIME_JAVASCRIPT_FILES, function(){egl.startupInit();});<\/script>");
isLastFile = false;
}
(In reply to comment #13) > In the design document, it states, "The script tag <script src="src.js" /> is > loaded asynchronously in IE when using document.write" > > In the attached HTML file (includeDojo.html), it appears that the script tag is > no longer using document.write. Is the problem related to the document.write > that is used in the overall HTML file to include all dynamically loaded > content? > > if(isLastFile){ > document.write(htmlString + > "<script>egl.load(RUI_RUNTIME_JAVASCRIPT_FILES, > function(){egl.startupInit();});<\/script>"); > isLastFile = false; > } The problem I stated in design document happens in the bootstrap code you pasted, not in the "includeFile" In current implementation, the "includeFile" is dynamically added to html file in the 2 steps: 1. Get the content by ajax. 2. Paste into html by "document.write" The problem described in the design document happens in step 2. I am changing this to .8 I2, since I think it needs more discussion. I believe our options at this point are: 1) Pass a FileLocator (Java IO) to the HTML Generator so that it can resolve includeHTML files on the EGLpath and include them in the HTML file. The FileLocator is passed to the generator so that it can be configured as necessary by the IDE and SDK independently. Including this information in the HTML file is unfortunate, because it is yet another thing that a user must remember to add in their own HTML file if they are going to be re-using deployed RUIHandlers in the future. 2) The solution proposed in comment 11, where a user invokes an EGL provided load function to synchronously load the content. In this solution, how is the loading made synchronous? Won't the load start, and then the browser will continue on to load the rest of the content in the include file and start running the application? I am wondering if we should expose an 'initial load' list (i.e. RUI_RUNTIME_JAVASCRIPT_FILES, RUI_DEPENDENT_JAVASCRIPT_FILES, etc) through an API (i.e. registerRequiredFile, etc), so that the includeDojo.html file can add a file to the list that is loaded synchronously before the application starts? Assign owner to Jiyong because the problem should be fixed in the HTML generation component. Moving to I3 because dojo 1.7 upgrade introduce a new loading method which may require us design how we load dojo. This task is proved to workable in modular loading prototype Change google runtime to make use of runtime AMD loader (runtime/dojo.js) No need to use API key now. Done as child of bug 363555 close |