[Code] Material.names to Webdialog.

jolran

Go ahead!

That is very kind of you! I've never used a for loop before so I'll might rewrite some stuff to the codingstyle I'm used to. Otherwise I'll have a hard time to follow.

@unknownuser said:

Not sure what you mean by this though. Custom interface?

costum UI, [like "jquery-ui-1.8.16.custom.min.js". Download whats needed.

@unknownuser said:

I might just use it as an example for a new blog entry as it deals with a few common issues in communication with webdialogs.

I think you should It's a good example I think. Not too long not too short.
Trying to learn from someone elses script with 500 + lines of ruby + HTML, JS etc can be very time consuming and difficult. And Googles examples leave you in need for more.

thomthom

@jolran said:

That is very kind of you! I've never used a for loop before so I'll might rewrite some stuff to the codingstyle I'm used to. Otherwise I'll have a hard time to follow.

Sure, it's a very quick script that does one job only. A simple proof of concept.

Dan Rathbun

@jolran said:

Dan. Interresting read. Not quite following it all, but if JQ is using innerText(my MS) may that cause problems with MAC?

Sure it can... both Safari and Chrome use WebKit as a rendering engine.
Since I just explained that on Chrome, %(#8000BF)[textContent()] works as expected, whilst %(#8000BF)[innerText()] does not work as I had expected, it may be possible that the same issue exists in Safari (which is used by WebDialogs on the Mac.)

@jolran said:

Although I thought JQUERY took care of platform incompabilities?

That could be a correct assumption, IF jQuery was without bugs. It is not.

On this issue, the JQuery source would need to be checked.
Using Quirksmode.org HTML as a guide, you can see that FireFox never supported %(#8000BF)[innerText()] (all other browesers did.) And... all browsers (but MSIE <9,) support the W3C standard %(#8000BF)[textContent()].

However.. if Thomas can make it work without any problems on both Mac and PC, then NO, you do not have anything to worry about.

thomthom

FIY: I added a [Code] tag to the title for easier searching for code snippet and inserted a link to the code sample in your original post.

jolran

@unknownuser said:

FIY: I added a [Code] tag to the title

Thats great! Hope the topic can help others as well.

@unknownuser said:

That could be a correct assumption, IF jQuery was without bugs. It is not.

Yeah, thats always I possibility. Like you said Thomthom code seams to work, so I will try to do it his way in my way.
Always interesting to read about your deep explorations, Dan. Although I'm not grasping everything.

edited: OT

jolran

Hi again!

ThomThoms code seems to be working very well. I've expanded the code to include lists of layers.name and components.name(from file) as well.
Also I'm sending the JSON.hashes to hidden inputfields in the HTML.

Took like forever to figure out one has to convert the JSON when extracting it from an inputfield or such. With something like:

var containr = eval('(' + $('#container').val() + ')') ;

Code is just for some other "freshy" who's also in distress.

Now comes the question concerning strategy.

I already got it working well but with sending data to multiple inputfields during several "execute_scripts". I suppose it's better/or cleaner to store all data in 1 JSON obj. And the send it to 1 inputfield?
Ideally I would include some other default values in the JSON as well.
However I can't get the syntax right. I've tried with something like:

@vals2JS= {
		"matlist" => self.hash_to_json( self.materials_hash ),
		"layrlist" => self.hash_to_json( self.layers_hash ),
		"complist" => self.hash_to_json( self.comps_hash )
	}

And then try converting the @vals2JS hash to JSON, but to no avail.
Also I'm worried about the maximum message limit. Maybe it's better to send data in chunks like I am? Or does it hurt something?

Update: Ok, i read someone suggesting serialize arrays or hashes with "join" and "split" to be able to put multiple values in hidden inputfields.
Also if I understood it correctly there is only maximum message limit FROM webdialog to Ruby?? For me that won't be a problem if thats true...

Dan Rathbun

@jolran said:

Also if I understood it correctly there is only maximum message limit FROM webdialog to Ruby?? For me that won't be a problem if thats true...

True that there is a limit going back to Ruby because the data is sent via the URI string using %(#8000BF)[window.location.href]

thomthom

Ah, you're using a hidden input field because you're worried about a max size?

There is a limit for sure when you call from WebDialog to Ruby, because it uses an URI to pass the data.

But I'm not so sure if there's a limit by using WebDialog.execute_script... What I do know is that for every time you call WebDialog.execute_script a <SCRIPT> element is inserted into the <BODY> element containing the argument to the method. This is evaluated into JS. Not sure exactly how that <SCRIPT> element is injected, but if you're worried about the size then you can run some tests with dummy data.

Dan Rathbun

@jolran said:

Took like forever to figure out one has to convert the JSON when extracting it from an inputfield or such. With something like:

var containr = eval('(' + $('#container').val() + ')') ;

(1) Get in habit of using the javascritpt function: %(#8000BF)[JSON.parse( *string* )] as it has some built-in safeguards against running code that malicious persons can hide inside strings. If you use %(#8000BF)[eval()], hidden malicious code can be executed.

There is a saying in the javascript world: "eval is evil" because it is an attack vector.

(2) Regarding a hidden input field. I do not not think you actually need to use one. This is usually done when sending data to a webpage via the URI (like how a search engine's form page, sends the search string using %(#8000BF)[?search=someword] .)

You should be able to send the data directly to a javascript object, thus:

dialog.execute_script( %q{dataObject = JSON.parse('} + json_string + %q{')} )

(3) JSOs can be nested, as well as containing nested Arrays, etc., so JSON strings allow the nesting of JSOs and Arrays. ... and so forth. The nested Arrays could wrap more nested JSOs and / or Arrays, etc. (There is a limit to the nesting level but it is huge, and you'll never likely run into the limit.)

Dan Rathbun

There is another topic where we discuss the limit on the number of %(#8000BF)[<SCRIPT>] elements that Microsoft Internet Explorer imposes... and Jim posted a JS cleanup function that removes these %(#8000BF)[<SCRIPT>] elements that SketchUp appends to the %(#8000BF)[<BODY>] element. (They have no ID attribute, so that can serve as a filter if there are %(#8000BF)[<SCRIPT>] elements that you do not want removed.)

See: [Code] Cleanup After execute_script

thomthom

<span class="syntaxdefault"><br />w</span><span class="syntaxkeyword">=</span><span class="syntaxdefault">UI</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">WebDialog</span><span class="syntaxkeyword">.new<br /></span><span class="syntaxcomment">#<UI;;WebDialog;0xed46184><br /><br /></span><span class="syntaxdefault">w</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">set_html</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'Hello'</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">nil<br /><br />w</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">show<br />true<br /><br />w</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">execute_script</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">%{</span><span class="syntaxdefault">alert</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'#{'</span><span class="syntaxdefault">X</span><span class="syntaxstring">'*1_000_000_00}'</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">length</span><span class="syntaxkeyword">);}</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">true<br /><br />w</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">execute_script</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">%{</span><span class="syntaxdefault">alert</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'#{'</span><span class="syntaxdefault">X</span><span class="syntaxstring">'*1_000_000_000}'</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">length</span><span class="syntaxkeyword">);}</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">Error</span><span class="syntaxkeyword">;</span><span class="syntaxdefault"> </span><span class="syntaxcomment">#<TypeError; can't modify frozen string><br /></span><span class="syntaxkeyword">(eval);</span><span class="syntaxdefault">155<br /></span>

In the case of sending a string generated by 'X'*1_000_000_00 I got this alert - as expected:
Alert

When I tried to increase it more you see Ruby spat out an error. That's not an issue with the Ruby -> WebDialog communication, but Ruby struggling to generate such a big string. It's a bit odd it talks about frozen string... Not quite sure what's going on.
But we're talking about nearly a 1GB string here... :s
It worked up until nearly 100MB!

When I tried to run 'X'*1_000_000_00 again after the previous failure I got this from the WebDialog:
JS Memory Error

So, unless you are sending crazy amount of data, hundreds of hundreds of megabyte then there should be no need to send the data via a hidden INPUT field. The INPUT field is only required when you send data from the WebDialog to Ruby.

thomthom

@dan rathbun said:

There is another topic where we discuss the limit on the number of %(#8000BF)[<SCRIPT>] elements that Microsoft Internet Explorer imposes...

?
Limit to the number of SCRIPT elements? I've not heard of that. Got a link to that thread?

(Mind you, I clean them up anyway as I don't want them filling up the DOM space.)

thomthom

@dan rathbun said:

JSON.parse( string )

Support chart: http://caniuse.com/json
All the way back to IE8. (I'd not worry about older IE versions any more - no unless you're doing commercial development and know a significant share of your potential users are stuck with the damned filth.)

Dan Rathbun

@thomthom said:

So, unless you are sending crazy amount of data, hundreds of hundreds of megabyte then there should be no need to send the data via a hidden INPUT field. The INPUT field is only required when you send data from the WebDialog to Ruby.

Just adding that ... technically... you do not actually send this large data to Ruby, instead you notify the Ruby-side that the data is ready, ... and then you read it from the Ruby-side using the dialog.get_element_value() method.

Dan Rathbun

@thomthom said:

Support chart: http://caniuse.com/json
All the way back to IE8. (I'd not worry about older IE versions any more - no unless you're doing commercial development and know a significant share of your potential users are stuck with the damned filth.)

OH! Nice page to bookmark!

@unknownuser said:

Note: Requires document to be in IE8+ standards mode to work in IE8.

Lesson always use a %(#8000BF)[<DOCTYPE>] tag!

If a customer must use IE7, you can always supply the JSON code. (There is an old topic where ThomThom and I discussed this JSON compatibility issue in detail.)

thomthom

@dan rathbun said:

@thomthom said:

So, unless you are sending crazy amount of data, hundreds of hundreds of megabyte then there should be no need to send the data via a hidden INPUT field. The INPUT field is only required when you send data from the WebDialog to Ruby.

Just adding that ... technically... you do not actually send this large data to Ruby, instead you notify the Ruby-side that the data is ready, ... and then you read it from the Ruby-side using the dialog.get_element_value() method.

Yes, though what I was testing now was sending data from Ruby to WebDialog. I wasn't sure if there was a size limit there.

thomthom

@dan rathbun said:

Lesson always use a %(#8000BF)[<DOCTYPE>] tag!

And META tag to trigger IE "edge" mode.

Dan Rathbun

@thomthom said:

Limit to the number of SCRIPT elements? I've not heard of that. Got a link to that thread?

I cannot find it anymore as MS overhauled MSDN (and alot of content disappeared!)

I may be confused with those loaded as resources via %(#8000BF)[<LINK>] tags:
http://technullogy.wordpress.com/2010/03/05/internet-explorer-limits-css-and-script-resources-to-30/

But I thought I saw a message at the bottom of one of the pages, that had to do with dynamically adding elements. I checked the %(#8000BF)[appendChild()] and %(#8000BF)[createElement()] pages, but there is little there now. (They cleaned house!)

Anyway.. we are going off topic... if you clean them up, you'll never hit any limit if there is one.

JD Hill

Just a note on the original topic, it reminded me of once when a user sent me a problem scene that was screwing up my webdialog. The problem turned out being that one of his material names had a leading control character -- unit separator, which is not printable, but which you can enter into a SU material name by hitting ALT+031. I don't recall precisely in what way that was tripping things up, but thought I'd mention it anyway.

jolran

OK! a lot of new stuff to digest. This forum is great.

It seems like I do a lot of things in almost the right way, or the wrong way.

I wasent sure in wich direction there was a message size limit. So to defend against that I interpreted from some topic that you could insert arrays or such in hidden inputfields.
Sending layers, materials and component names it can easily become over 2000 characters. But in reality I won't reach that large amounts like during some tests here from Thomthom.

Dan.
JSON.parse( string ) sound like a better solution then. As long as I accept the user has IE8 +. For Mac that will not be an issue?
I believe that the user is probably working with SU on his or her major workstation which should be up do date.
Still have to figure out how to nest JSON or rather "hashes ready" for JSON in ruby first. Maybe use the method Thomthom already provided if it will work for that purpose.
There is bunch of info regarding " require 'json' ". But that module is not avilable in Sketchup I suppose..

Regarding "code cleanup after script" I saw that thread, and put Thomthoms JQ body-detach script in the "$doc.ready" function. Don't know if theres the right place to put it, but I sure did
Maybe it should be done in a callback

So just to make clear, I can forget about hidden inputfields and just send the data from SU exect.script to a global array in JS then? Like Thomthoms in this topic provided" materials.rb" do.

JD Hill. Thanks.

Sounds a bit like the issue I had before, I was also conserned about the end user going heywild on the keybord with names and such.
I suppose you havent had a look at Thomthoms script? Or maybe you are already doing something similar.
Well anyway, it's cleverly using 1 string stored as .text for display in webdialog and keeping the original SUmaterial.name stored as value. So one send the value to SU from JS.
In case of materials in SU, display.name is used, but I dont think there is nothing stopping you from doing some escaping on that string either, cause it wont affect the value. If one can put anything one like as value or not I havent got a clue..