Web Dialogs -Get string from Ruby before Body loads?

TIG

I have all of my fields set to '' in the html, and then 'populated' [using callbacks] in the '{}' block after the dialog has 'shown'...
The dialog opens and is very very briefly 'empty' before the data fields appear... BUT it is hardly noticeable unless you are looking for it...

Dan Rathbun

@chris fullmer said:

In my example, the line I show in the body is a typical line of this html doc. It refers to the "ds1" variable, which is set based on the path.

Except that index_path is local to the passFromRubyToJavascript() function, and won't be accessible globally.

You need to declare it outside the function first as an empty string value.

Dan Rathbun

@chris fullmer said:

Dan, I think your first example looks good, I'm not quite getting it implemented correctly yet, but I'm still plugging away at it.

You may need to wrap the <INPUT> element within a <FORM> element:

<!DOCTYPE html>
<HTML>
  <HEAD>
  <SCRIPT>
    // globals
    var index_path = "";
    var ds1;

    function init_path(patharg){
      index_path = patharg;
      ds1 = new Spry.Data.XMLDataSet(index_path,"tag",{sortOnLoad; "@file", sortOrderOnLoad; "ascending", distinctOnLoad; true});
    }
  </SCRIPT>
  </HEAD>
  <BODY>
    <FORM onload="init_path(IndexPath.value);">
      <INPUT type="hidden" id=IndexPath name="IndexPath" value="" />
    </FORM>
    <DIV>
      <TABLE name="DataTable">
      </TABLE>
    </DIV>
  </BODY>
</HTML>

Chris Fullmer

Ahh, or the ds1 variable points to a spry xmldataset. What if when the page loads, I point it to a temp xml file that I provide with the install, swo that the ds1 variable can be set correctly. Then once the page loads, I re-set the ds1 variable to point to the real path.

Maybe I'll poke around with that idea.

-oh, TIG just posted -
@TIG

I like that way of doing it just fine. I'm not sure what I would need to tell my html developer guy to do to make that work on his end. Right now he is using spry to be able to dynamically change the values shown in the boxes. I'm not sure how to leave the fields blank until the page loads. The spry thingy seems to want to populate as it loads, I guess?

@Dan - yes, that is the way I showed it in what I posted. I am actually declaring it first outside the method, thanks for checking that. I've also been writing it to a blank field in the html just to verify it does come in right. And it does, I think, its just coming in too late for the ds1 declaration.

Dan Rathbun

Anyway Chris ... back to basics: Are you just wanting to display a table of data ??

Does the applet need to be cross-platform ??

If so there's a better way to do this.

Chris Fullmer

Yes please, back to basics

I have a file that contains a list of xml files. Those xml files have the data that I want to display in the webpage. The wbpage has a dropdown box and a table. The dropdown box lets you select which xml file to view, the xml file has the data that populates the table.

The file with the list of xml files is my index_path I'm trying to pass in. When I hardcode it in, all the fields populate correctly, the dropwdown box works great, I can switch between all the listed xml files.

So, a simpler cross-platform solution might be great.

Dan Rathbun

Ok...

Is the index file always the same.. or does it change from session to session, or within the session ?

Does the data in the individual XML files change and therefore need to change the cell values in the tables dynamically while the table is displayed, or do the XML tables just represent "post operation" data displayed "after the fact." ??

Chris Fullmer

The index file is written to a temp_folder, and that path is always different on different user's systems. But other than that, the name and location will not change during the SketchUp session, or while the window is open.

The xml files will not change either while the window is open. The window is setup to be the system where the user can enter data, press submit, and it will then update the xml files with the newly entered data.

Chris Fullmer

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.

Chris Fullmer

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?

Chris Fullmer

Oh!, I think I'm on to something really good from Dan's original comment. More to come once (if) I get it working.

Chris Fullmer

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.

thomthom

AH - nice. Query strings, that's a nice way to feed small amounts of data. I like that.

thomthom

@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]

Dan Rathbun

@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.

Chris Fullmer

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.

Dan Rathbun

@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 Information

This property is defined in HTML 4.0 and is defined in Document Object Model (DOM) Level 1.

thomthom

Scripts in HTML documents

(www.w3.org)

@unknownuser said:

UA may defer execution of script

Scripts in HTML documents

(www.w3.org)

@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.

JavaScript - Placing JavaScripts

(www.quirksmode.org)

@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.

Dan Rathbun

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.)

thomthom

@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...

dean.edwards.name

(dean.edwards.name)

@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.