[Code] WebDialog communication

Dan Rathbun

(More Devil's Advocate)

I do realize it is beta.. but:

[E] Namespace: I will always crab about defining non-Ruby CORE classes within TOPLEVEL_BINDING. This should be considered Ruby's namespace.

Just as ThomThom is defining his subclass within a module namespace TT_Lib2 or whatever he decides, this class needs to go in some namespace.

Temporarily ... with Dev::Test::UI or Beta::UI, just something that does not show newbies that we define classes that will potentially clash with Ruby Core objects, or other wrongly written, custom classes, that are defined at the toplevel.

Think about the WxSU / WxRuby extensions, they have Dialog class, but it is within the Wx namespace. (See the file "wxruby/lib/wx/keyword_defs.rb" in the WxRuby source.)

[F] Classname: The name Dialog, is potentially confusing. Most would think it will refer to native dialogs (Win32/MFC on Windows, Cocoa or Carbon on Mac.)
I was thinking of something like: WebDialogDeluxe or WebDialogEx as a classname. [ see next post ]

Remember that even a class name is a Constant reference, and any plugin author, within their own namespace, can define their own reference to classes in other namespaces, to save typing, (if they so desire.) Ex:

module JoeCoder

  WDE = SKX;;GUI;;WebDialogEx

  @@dlg = WDE.new("Plugin Options", ... )

end # module

On the Javascript side, is using such a common word as a namespace wise ??

(Are we sure this will not clash with any possible framework that an author might wish to use: JQuery, DHTMLSuite, etc.)

Aerilius

I fixed [A], [\B], [C], [E].

@dan rathbun said:

[F] Classname: The name Dialog

The classname was a placeholder to be changed when using the code (I corrected it to avoid misuse).

@dan rathbun said:

You need to think about whether it will be easier to maintain as a pure .js file, [...] rather than a heredoc text block embedded within the Ruby.

The reason was just to have it more compact (one file, no external requirements). But it has grown a lot, and a separate file gives also nicer JS code-highlighting

I have one issue with using an overriden execute_script instead my method because I pass the code string to JavaScript as a String and eval it there. Now this requires that the JS framework is already loaded, but originally I load it with execute_script in the show method... I'm curious about your external script/css injection.

Marriage sounds always good, I think merging the code is better than having several competing less complete solutions.

Dan Rathbun

[off:3k0yoz7n]Side Note: A "wrapper class" and a subclass are two different things.

A wrapper:

class Author;;WebDialog

  attr_reader(;dialog)
  
  def initialize(*args)
    if @dialog.nil?
      @dialog = UI;;WebDialog.new(*args)
    end
    # other init code
  end

  def execute_script(code)
    # do some manipulation to the code string
    result = @dialog.execute_script(code)
  end

end # wrapper class

Basically a "wrapper" mimics the "wrapped class" (with modifications,) and so must contain a "wrapper instance method" for each of the "wrapped class's" instance methods.

A wrapper is usually more work and requires higher diligence in coding to get things to work correctly. But sometimes has advantages over subclassing. Some of the Extended Ruby Library classes are written as a "wrapper" class. (The Delegate classes come to mind.)[/off:3k0yoz7n]

Dan Rathbun

@aerilius said:

I fixed ...

OK.. looking over the new version.

@aerilius said:

But it has grown a lot, and a separate file gives also nicer JS code-highlighting.

Exactly what I was thinking...

[off:3qvw2q1w]I wish Notepad++'s lexer would recognize inline dialects from other languages, and highlight them correctly. It does seem to work for Js embedded into HTML, but not CSS embedded into HTML, everything within the style tag is white. (Maybe we can get the Notepad++ core guys to "invent" some editor hash codes for inline language changes?)[/off:3qvw2q1w]

@aerilius said:

I have one issue with using an overriden execute_script instead my method because I pass the code string to JavaScript as a String and eval it there. Now this requires that the JS framework is already loaded, but originally I load it with execute_script in the show method... I'm curious about your external script/css injection.

This will need to be moved into the show_handler(), just after stylesheeet injection. It will need to be done PRIOR to any "interactive proc" running, in case an author wishes to use your Js framework, in that proc (if they define one.)

@aerilius said:

The reason was just to have it more compact (one file, no external requirements). ... Marriage sounds always good, I think merging the code is better than having several competing less complete solutions.

OK I am reorganizing my code. (One big change is I was actually playing around with patching the actual UI::WebDialog class, but realized their was just no way I could release such a patch. It's a BIG "no-no".)

So I have to make changes so it is a subclass. Which solves some things. We can now define the readyState_callback within the initialize method, simplifying the show_handler method, and other code as well.

It gives access to the constructor arguments, which I need to try to solve another of the UI::WebDialog bugs, but that's low priority for now. Organization comes first.

Multiple files: I learned multiple files are really best, especially while debugging.

[off:3qvw2q1w]Also I use my editor in 2 pane mode, left pane edit, and right pane for referring to code in other files of the plugin. Saves scrolling way up, and way back down, etc.
I move various files back and forth between the left and right editor panes, depending on which one I am editing.
I also use Mike Foster's NPP Session Manager plugin (with custom mouse context-menu,) to quickly load all the files in the project, and save changes (like which pane each file is loaded into.) See the latest help file for his plugin, if you use NPP.

I hate scrolling so much.. that I often insert "section fold" brackets like:
` #{# INSTANCE METHODS

#}#`
... and use the fold shortcuts ALT+level_number_key to quickly expand / contract block levels.[/off:3qvw2q1w]

Anyway I'll need a day or two to re-organize and make some changes, and merge some code.

thomthom

This code would be nice to have on GitHub. @Aerilius : what you think?

Dan Rathbun

@thomthom said:

This code would be nice to have on GitHub. @Aerilius : what you think?

No it would not. I have a GitHub acct. They force a commie-socialist GPL-like license on any code posted.

I currently have a week or more in my part, est ~2500 dollars; and I'm sure Aerilius has at least the same. John has put near 3 days at least into testing as well. We are approaching ~6000 dollars in value invested, and may have even reached this.

I am not willing to let some person(s) or company(ies) just take our code from GitHub, re-brand it, and sell it without compensation.

I know by the time we get through the beta phase, with testing, that we'll have over 10,000 dollars in value into this.

The other issue is forking. The world is full of idiots who do not understand how their fork can "throw a wench into the works."

Go to RubyGems.org, search on "SAX" (which stands for Simple API for XML,) and see how many forks there are for SAXMachine. If you take the time to go to the documentation page for each one, you'll see NONE of these "forkin' idiots" changed the namespace. Nor did any of them even bother to wrap their fork in their author namespace.

I'd like to retain some semblance of control, so I typed up a preliminary EULA, that declares copyright (by our group,) and prohibits re-branding, re-packaging, re-distribution, forking or subclassing. (I am not yet sure about wrapping, still need to think on this.)

But I do not think, at this time, anyone will NEED to do any of these things, as we are making this extension eXtremely fleXible.

I'm not sure but perhaps Google Codesite, may not force GPL-like license on projects, and may be able to use Git now ??
I'm all for making it easier to collaborate, but not at the expense of surrendering my rights.

thomthom

oookay.... BitBucket then?

Dan Rathbun

@thomthom said:

oookay.... BitBucket.org then?

Now that looks alot better! I'll have to read their ToS alot closer, but like they say right up front, private repositories (with access control.) We won't be ready till later in the week for this, let's get past this first major merge here between Aerilius' code and mine.

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.