[Code] WebDialog communication

thomthom

Only thing is that I'm not sure if BitBucket allow free private repos to have multiple users. But I don't think free public repos enforce any licenses (open source or not). Up to the owner AFIK. (Correct me if I'm wrong.)

Btw, I never noticed that GitHub forced public repos to be open source?

Dan Rathbun

It says 5 users is free.

Dan Rathbun

OK, obviously we need a shorter Js-side namespace name.

Fisrt choice: WDX
I did a search on "+javascript +WDX"

got no hits.
Search acronyms: WDX
It stands for Wavelength Dispersive X-ray spectroscopy. (Not likely to be used as a namespace in Js, at least with SketchUp.)

However... there is also the ".wdx" binary file format. It stands for Wolfram Data Exchange, used by Mathematica. see: http://reference.wolfram.com/mathematica/ref/format/WDX.html
There ARE APIs associated with this, (although they do not yet have ".skp" import/export, they could in the future.)
It is also quite possible someone would create a web interface 'framework' that uses this acronym.

I think we should avoid this one.

Next choice: SWDX ( SketchUp WebDialogX )
No hits at http://www.dictionary.com
or http://acronyms.thefreedictionary.com
or http://en.wikipedia.org/wiki/Special;Search?search=SWDX&go=Go

I think we should use SWDX, on the Js-side.

Thots ?

chrisglasier

@dan rathbun said:

OK, obviously we need a shorter Js-side namespace name.

Excuse me for butting in but the subject relates to what I am trying to do.

I think I asked about this before here but certainly at Stackoverflow.

In a nutshell if I append a new external script file after loading its names overwrite any duplicates in memory. The act of (re-)appending a file defines the namespace (or at least its content) which seems more reliable than human acronymisation (sorry). I suspect there is some dreadful twist to this but I am still looking.

Dan Rathbun

No problem, Chris.

So far we are not unloading an external script, and will be appending the external script via <SCRIPT src='some/path/WebDialogX.js'>, but to the <HEAD> element, and only ONCE, just after the DOM readyState reaches "interactive".

I think there may be a subtle difference between appending to the <HEAD> and <BODY>, ... well for us, at least the big difference is we want the WebDialogX framework out of the line of the <SCRIPT> tag cleanup function.

Also I had mentioned this before... there may be some authors who have <SCRIPT> tags attached to the <BODY>, and do not wish them removed.

So do we test for an id attribute, and leave those tags alone ??

(One thing Aerilius tried to do was, delete only 1 tag at a time, just after execute_script() returned. Kind of making it cleanup after itself.)

chrisglasier

Actually it isn't the external file cleanup I was concerned with, it is trying to avoid uniquely naming a namespace by allowing duplicate names for js objects.

So for example I have a number of devices (plugins), one for positioning, one for timing, one for animation, one for music and so forth. Each device has function start(){...}. When I want to use one I create and append a new script element with the relevant source file. When that is properly loaded its start function overwrites the one in memory, and the same for any other duplicate name.

I know that all the Ruby plugins have to be loaded with Sketchup, but this is not true with the js side of webdialogs.

Dan Rathbun

OK.. well that is all fine and dandy. It should not effect us because all our functions will be within a Js namespace, and your functions will be outside it.

So far the only objects that are global will be 3 vars, that will all probably be prefixed "swdx_" (or a downcase of whatever the namespace will be.)
These 3 vars, I think (correct me if I am wrong,) can be deleted, after the element append is over and done with.
Although I have not tried to do this yet. I suppose it might just as well be easier, if I wrap the routine in an anonymous function, so the vars just go out of scope, when the dirty deed is done?

So I guess my question to you is, are you loading your devices / functions into the global Js namespace, or do you use a Glasier namespace ??

chrisglasier

@dan rathbun said:

OK.. well that is all fine and dandy.

...

So I guess my question to you is, are you loading your devices / functions into the global Js namespace, or do you use a Glasier namespace ??

All variables are parts of three global json objects:

1 - one to hold all the records (eg all properties and attributes of entities, layers and scenes and special collections),

2 - one that holds the main display configuration plus built-in menus and device keys and value options,

3 - one as 2 above but specifically for the only connected device.

Apart from these only functions are global variables. Device functions can be called anything provided they are not prefixed core or mac (dedicated to 1 and 2). Any conflicts with previously loaded devices are resolved by having the active device functions loaded last.

In these circumstances is there any point in having a dedicated namespace?

@aerilius said:

Since the code of all <script> elements goes into memory when the script tag is loaded, it shouldn't matter if we just delete all script tags.

Precisely ... in a way I was responsible for muddying the waters with script id's - sorry.

Aerilius

@dan rathbun said:

So do we test for an id attribute, and leave those tags alone ??

I've added the check for an id (not yet uploaded). Since the code of all <script> elements goes into memory when the script tag is loaded, it shouldn't matter if we just delete all script tags. Except an executing script needs a reference to a <script> element (probably with id, but not necessarily).
A very mild way would be to use dlg.execute_script("/*delete this*/ someCode()")
and then delete script elements if their innerHTML starts with " %(#000000)[/*delete this*/]". We'd like SketchUp not to flood the DOM with script elements, but is the innerHTML approach overdone?

As for a license, I initially thought about keeping the extension relatively open. I'm a bit worried whether we should allow/disallow redistribution and how it makes plugin installation more difficult. Do others think plugins that require separate downloads is not so much a problem?

Dan Rathbun

It makes me wonder if a <script> element with an Id=='myscript', is deleted from from the DOM, what happens when:
document.getElementById('myscript')

Does an error occur ?

Dan Rathbun

@aerilius said:

I'm a bit worried whether we should allow/disallow redistribution and how it makes plugin installation more difficult

You lose revision control, when e1 is distributing different versions.
One or two sites, that hopefully will have update notification, are best. Hoping Dana gets his site up.

What happens if the user already has the latest, and a "rbz package" tries to install an older one ??

@aerilius said:

Do others think plugins that require separate downloads is not so much a problem?

TT is working on an installer, and also Dana, so hopefully soon it will become even easier.

chrisglasier

May I put up another part of my modus operandi (extra Roman flavour) which seems to be parallel to yours.

Here is a copy of the parts I noted before:

@unknownuser said:

**> 1 - one to hold all the records (eg all properties and attributes of entities, layers and scenes and special collections),
2 - one that holds the main display configuration plus built-in menus and device keys and value options,
3 - one as 2 above but specifically for the only connected device.
**

A configurable display and supporting operating functions (prefixed core or mac) live on a web site. These belong to the website owner (a consortium or individual). These functions facilitate the assembly, uploading and downloading of plain text files of the json objects noted with links to external js files for optional devices. In the case of Sketchup the website sits in the webdialog and calls Ruby commands from there.

The text files belong to whoever made them. The device files belong to whoever made them. The power source belongs to the website owner.

Dan Rathbun

@aerilius said:

I have one issue with using an overriden execute_script ...

Yes.. I agree... after I posted, I looked at my code, and realized that we need to keep it as it is.

What I did was:

1) write a private internal show_handler() method, (called from the overridden show() and show_modal(),)

2) which calls the appropriate aliased api_show() or api_show_modal() methods,
EDIT: No longer aliasing these. Usingsupernow.

3) then enters a UI.start_timer loop, which keeps calling:

a) execute_script() to determine the readyState
(which returns false while the document's readyState is "loading", so nothing happens, until the DOM can actually execute the script arg, where upon it returns true. Meanwhile a callback gets the actual readyState value, and stores it in an instance var.)

b) back in the loop, it checks the readystate though query method instance var wrappers:

(i) if the page is still loading, the loop waits the delay interval, and runs again.
(ii) if the readyState is interactive, stylesheets are conditionally injected, and then an "show interactive proc" is run if one has been defined; the loop continues if the page has not yet reached 'complete'.
(iii) if the readyState is complete, the timer is stopped, and the "show complete proc" is run if one has been defined.

So, while the page and content are loading, I need execute_script to run FAST, without any parsing of the argument.
I use a single quoted string so Ruby will not parse it, thus:
%q[window.location="skp:readyState_callback@"+document.readyState]

So anyway.. there's no way to avoid having some aliased " api_" methods, because sometimes we just cannot use super (at least the way I have it written. I hate to have to duplicate a bunch of code, just to use super and avoid aliased methods, but dang sometimes I hate having aliased superclass methods also.)
EDIT: No longer aliasing any api methods. Usingsupernow within any overrides.

Dan Rathbun

No longer aliasing any api methods. Usingsupernow within any overrides.

Much cleaner code.

alexschreyer

Great idea to clean up the web-dialog interfacing!

Let me throw one more idea in there: Apparently

post_url

does not accept any returned data (it just opens it in the embedded browser window). Might be nice to have

get_url

and

post_url

functions that at least return the data. That could even be expanded into

get_json

and

post_json

. Of course, jQuery will do that but a native way might be neater.

It's definitely on my feature request list for SU...

Cheers,
Alex