Web Dialogs -Get string from Ruby before Body loads?
-
I should add I'm not the one developing the webdialogs either. It is a guy who has done a lot of html development. So he is pretty good with it, but definitely in a more typical scenario. So I keep throing him curveballs about how I can and can't interact with his dialogs, etc.
His webpage works great, and I'd love to be able to work within his framework if possible.
-
Could I do something like create a temp webpage that opens, gets (or is given) the path. Then that window opens a child window that has access to the path?
-
Oh!, I think I'm on to something really good from Dan's original comment. More to come once (if) I get it working.
-
WOOOOOHOOOOO!!!!!!! I got it! At least it is working very smoothly on my PC. I'll have to do some Mac testing later today <frightened!>. This is what is working great for me. In ruby, I set the path to the webdialog as a few parts - 'path' + 'filename.html' + '?' + 'index_path' + 'index_filename' so it looks something like this:
@@webdialog.set_file(html_path + "?" + index_path)
Then I grab it really easy in the <head> because the path is included in the url. I parse the document.URL like this:
q_mark_index = document.URL.indexOf("?")
var index_path = document.URL.substring(q_mark_index+1)Is that an ok way to parse it? I am not an expert string parser, that's for sure. But that seems to be working well.
Thanks so far to everyone who has chimed in and read along. I've been working on this little tidbit for too many hours. Dan I would not have got this without your example at the beginning.
-
AH - nice. Query strings, that's a nice way to feed small amounts of data. I like that.
-
@chris fullmer said:
q_mark_index = document.URL.indexOf("?")
var index_path = document.URL.substring(q_mark_index+1)How about:
var index_path = document.URL.split('?')[1]
-
@chris fullmer said:
Is that an ok way to parse it? I am not an expert string parser, that's for sure. But that seems to be working well.
You don't need to parse it, the location object has methods that return all the various parts.
document.url just returns the location object.
see:
http://msdn.microsoft.com/en-us/library/ms535866(v=VS.85).aspx@chris fullmer said:
Thanks so far to everyone who has chimed in and read along. I've been working on this little tidbit for too many hours. Dan I would not have got this without your example at the beginning.
-
Very Cool Dan, thanks for that hint. Using
*string*.search
still returns the question mark at the front, so I had to split that off. But I was able to simplify my js to this,var index_path = document.location.search.slice(1)
And that is so nice compared to all the callbacks and timing issues I was trying to fight with.
-
@thomthom said:
@dan rathbun said:
Also, it occurs to me that you may be able to use the DEFER attribute for a <SCRIPT> element to have it wait, until the page loads, or some event, rather than run immediately.
Does DEFER work for anything other than IE?
@unknownuser said:
Attribute](http://msdn.microsoft.com/en-us/library/ms533719(v)":26da9f6x]
Remarks
Using the attribute at design time can improve the download performance of a document because the client does not need to parse and execute the script and can continue downloading and parsing the document instead.
Standards InformationThis property is defined in HTML 4.0 and is defined in Document Object Model (DOM) Level 1.
-
@unknownuser said:
UA may defer execution of script
@unknownuser said:
When set, this boolean attribute provides a hint to the user agent that the script is not going to generate any document content (e.g., no "document.write" in javascript) and thus, the user agent can continue parsing and rendering.
@unknownuser said:
Originally, this is nothing more than a hint to the browser that the script inside the tags does not modify the content of the web page (by doing a document.write, for instance). Therefore the browser does not need to wait for the entire script to be parsed and evaluated, it can immediately go on parsing the HTML. On older systems this might save some parsing time.
However, Explorer 4+ on Windows has slightly changed the meaning of defer. Any code inside deferred script tags is only executed when the page has been parsed entirely.
-
OK.. so? Are you saying it does not work on Webkit?
or... that it's safer to rely on the DOM onload events to trigger scripts?
IF so I'll agree.. it was just a thought. (I've never seen a need to use DEFER myself. Always triggered functions using the onload event.)
-
@dan rathbun said:
OK.. so? Are you saying it does not work on Webkit?
or... that it's safer to rely on the DOM onload events to trigger scripts?The DOM events are the reliable ones.
defer
has been used only as a fallback for older IE versions that did not support events for when the DOM loaded.@dan rathbun said:
Always triggered functions using the onload event.)
onload triggers after all images loads etc. I prefer to use the event that triggers when the DOM is ready. But run locally there might not be big noticeable difference. guess it depends on how large and many your external resources are. But for websites the DOM makes a big difference.
Since I use jQuery it all comes for free anyway in a cross compatible event. I've even forgotten the name of the DOM event that triggers when the DOM is ready...
@unknownuser said:
IE supports a very handy attribute for the <script> tag: defer. The presence of this attribute will instruct IE to defer the loading of a script until after the DOM has loaded. This only works for external scripts however. Another important thing to note is that this attribute cannot be set using script. That means you cannot create a script using DOM methods and set the defer attribute β it will be ignored.
@unknownuser said:
There is a small problem with this approach. Other browsers will ignore the defer attribute and load the script immediately.
-
OK.. got that cleared up... oh boy does the "Lost Manual" need alot of update.
-
@dan rathbun said:
OK.. got that cleared up... oh boy does the "Lost Manual" need alot of update.
Yea... I have Revision 2 in the works.
-
I have a lot more testing today on this, but my initial run indicates that the Mac might not support the query string in the html file name. It could be some other glitch in the code, but the mac I'm remotely testing on would not load the page. I'll post later when I know more.
-
Since you did not answer my PM regarding whether the project may go commercial in the future...
.. I'll just have to point you to an example you can paste from MSDN (I'm using it in my Lib dialog.)
[HTML Elements: <SELECT>](http://msdn.microsoft.com/en-us/library/ms535893(v)
See the 3rd oem example (just above the "Community Content" section) near the bottom of the page.
The "value" of an option is the datatablefilepath, the "text" of an option, is what shows in the dropdown list.Also obviously, you'll use a onselect event.
onselect="TableFrame.src = this.options[this.selectedIndex].value;"
-
Thanks Dan. I'll look at that and point the html developer to it. In the end we've got it worked out now, but only after some serious extra effort.
Advertisement