[Code] WebDialog communication
-
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.) -
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.
-
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 ??
-
@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.
-
@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 usedlg.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?
-
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 ?
-
@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.
-
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.
-
@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 overriddenshow()andshow_modal(),)2) which calls the appropriate aliased
api_show()orapi_show_modal()methods,
EDIT: No longer aliasing these. Usingsupernow.3) then enters a
UI.start_timerloop, which keeps calling:a)
execute_script()to determine the readyState
(which returnsfalsewhile the document's readyState is "loading", so nothing happens, until the DOM can actually execute the script arg, where upon it returnstrue. 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_scriptto 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 usesuper(at least the way I have it written. I hate to have to duplicate a bunch of code, just to usesuperand avoid aliased methods, but dang sometimes I hate having aliased superclass methods also.)
EDIT: No longer aliasing any api methods. Usingsupernow within any overrides. -
No longer aliasing any api methods. Usingsupernow within any overrides.
Much cleaner code.
-
Great idea to clean up the web-dialog interfacing!
Let me throw one more idea in there: Apparently
post_urldoes not accept any returned data (it just opens it in the embedded browser window). Might be nice to have
get_urland
post_urlfunctions that at least return the data. That could even be expanded into
get_jsonand
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
Advertisement