SketchUp Ruby API Extension Library

[Chris Fullmer]

OK, I found it in an earlier post that you specify that the developer would use the library with

require 'skx/entities.rb'

essentially requiring eacf file they would like to use. Would be interested in also having a loader file included so they could just require one file in the root skx folder and it auto loads all files, just in case someone regularly wants to load nearly every file? Or is that just overkill and problems waiting to happen?

Chris

[Jim]

Can I ask if skx is intended for people like Ericschimel from this topic? If so, would sets of javascript/ruby interaction couplets be what you have in mind for the repository. I could do that over time provided I didn't have to learn too much more codelling.
Chris

Chris,

I would like to see some cross-platform methods of passing values between javascript and ruby, so clearly would involve a ruby part and a javascript part. There seems to be a general acceptance that passing strings as JSON is the best way to go, but nothing has materialized as far as I know. Most of us are using comma or semi-colon delimited strings.

It might be cool to have a set of html widgets to use in WebDialogs if you need something basic and quick.

I would also like to provide a predictable location for installing existing javascript libraries. I know Thomthom is using jQuery in citygen, for example and I am using it on a yet unreleased plugin. Chris Phillips was also considering it for the next SketchyPhysics (but may use wxSU.)

Along the same line, there are so many useful methods (libraries) already availablein the Ruby standard library, it would be a shame to ignore - or worse repeat the effort. I was thinking we could also provide a standard location for using them. As an example, the singleton.rb file which ensures there is ever only one instance of a class - is useful for creating Observers where you really only want a single instance per model. Instead of everyone creating their own Observers, we can provide them via some kind of generator (factory?).

Observers are another entire area that could use work.

I got a little off-topic, but I hope I answered your questions.

[Jim]

OK, I found it in an earlier post that you specify that the developer would use the library with

require 'skx/entities.rb'

essentially requiring eacf file they would like to use. Would be interested in also having a loader file included so they could just require one file in the root skx folder and it auto loads all files, just in case someone regularly wants to load nearly every file? Or is that just overkill and problems waiting to happen?

Chris

I don't think it is over-kill. Each folder can have a 'loader' that requires all the files in that folder. And there can be a 'skx.rb' that loads everything, if you want.

This is one of the things that needs considered when the final layout is decided. Having lots of small files in folders gives the most flexibility (IMO). You can pick and choose single methods as needed (require 'skx/group/definition'), include all the methods in a class (require 'skx/group'), or include the while library ('require 'skx/skx'). The choice is left to the user of the library.

[Jim]

Don't forget about this thread Jim. I think Alex and you worked out a great system here for making it so ALL scripts take advantage of the new start_operation flag speed.

viewtopic.php?f=180&t=19372&start=0&st=0&sk=t&sd=a

Chris

I haven't forgotten. I am wondering if the script-timeout I was experimenting with could be incorporated into start_operation. That way, a user would be able to set their own time-out tolerance (i.e. 10 seconds) which would then be automatically enforced by any plugin that currently uses start_operation.

[Jim]

Oh and I was thinking we could provide a mechanism to handle script configuration options - get them all in one place (or menu.) Like the /etc directory with some type of interface (if you are familiar with Unix.)

[Chris Fullmer]

I am updating the wiki right now, and finding that we need to specify the file that each method is in so that the developer can know what files to require if they want to keep it minimal.

Do you think that you will be able to get RDoc worked out to do a wiki update directly from the RDoc's? That would be very cool.

Chris

[thomthom]

I don't think it is over-kill. Each folder can have a 'loader' that requires all the files in that folder. And there can be a 'skx.rb' that loads everything, if you want.

No need for a loader for that, require_all should do the trick.


A good JSON solution would be good. I've been using a crude look-alike for one script. I was talking to one of the Google heads that was also in need of JSON. I'll see if they found a solution.

[Chris Fullmer]

No need for a loader for that, require_all should do the trick.

Ahh, good point.

Ok, Ive updated the wiki docs now for the methods I added.

Chris

[thomthom]

So are we still doing a file per method?

[ScottLininger]

So are we still doing a file per method?

I'd like to hear everyone's votes. One-file-per-method is more flexible, but it could become overwhelming with so many little files. Also, I could imagine scenarios where one extended method might need to call another, so including only a single one might not always work.

I'd argue that if you're wanting to exclude a certain part from loading, then that certain part probably doesn't belong in the project. But please don't take my opinion as law.

Thoughts?

On the WebDialog topic...

We wrote a somewhat generic bridge between JS and Ruby that we used for Dynamic Components. I learned a lot from that and would have some thoughts on how to build a new one that's truly generic and easy to use. That's almost worthy of its own big thread.

One note: I think it would be work for the JS code side of a bridge to be stored in the ruby and then dumped into the WebDialog via execute_script, so JS code side of things would call something like this:

Code: Select all

window.location.href='skp:initialize_bridge';

...and then from there would have access to whatever JS methods we implement.

[Chris Fullmer]

I think I prefer the single file approach instead of multiple files approach on this project. I am not terribly familiar with code libraries though, so this is not based on much experience.

Chris

PS I'm working on the readme.txt file. Check it out in 30 minutes or less.

[chrisglasier]

On the WebDialog topic...

We wrote a somewhat generic bridge between JS and Ruby that we used for Dynamic Components. I learned a lot from that and would have some thoughts on how to build a new one that's truly generic and easy to use.

As someone who would greatly benefit from such a resource my question is whether ease of use is Ruby/Javascript oriented or the other way round. In the case where webdialogs are used in a new form of word processing -- adding all kinds of data to models -- would an outsider (allowed?) be able to look up the JS function that imitates real world action or forced to go through the class by which Ruby implements it?

CG

[chrisglasier]

I would like to see some cross-platform methods of passing values between javascript and ruby, ....

Methods are hardly within my grasp but I am concerned and hopefully can contribute to an actionable approach to webdialogs and related resources (not just code). Please see above.

Thanks

Chris

[thomthom]

I think my vote is for one file per class/module.
I see it as either you have the skx extension - or you haven't.

[thomthom]

I'd just like to bring attention to this discussion over at the Google Code pages: http://code.google.com/p/skx/source/det ... 325827e97d

[Jim]

Any ideas on how to create a test suite for these methods? Is it needed?

[RickW]

I think my vote is for one file per class/module.
I see it as either you have the skx extension - or you haven't.

Code: Select all

# One file per object
votes += 1

# One big skx file
rick = "not so sure about that"

[thomthom]

I didn't intend one large skx file, but one file per class/module - instead of one file per method and one folder per class/module.

[ScottLininger]

Any ideas on how to create a test suite for these methods? Is it needed?

For now, I think we can move forward without a test suite. We have some internal tools that we might be able to share... I'll check.

Unit tests are a wonderful, wonderful thing, and eventually we will thank ourselves if we build them. But we can get away without 'em for a bit.

[Jim]

It seems my basing skx directory structure on Facets structure was premature:

From the facets readme file:

the extension methods are no longer stored on a per-method basis. While dividing the extension methods up on a per-method basis had certain advantages, not the least of which was a simple organization, it proved too granular --more "subatomic" than "atomic". With 2.0 we have address this issue. All the extension methods have now been organized into small tightly related groups.

Now if you get in and look at many of the files in facets, they contain a single line requiring the 'tightly related groups' file. This is not what I intentioned.

So, I do not have an issue consolidating what is already there into fewer files containing related methods.

Is anyone suggesting a single file? It may be an option for 'core' methods that provide essential methods and API fixes.

[thomthom]

I don't think I want one large file. But one per class/module sound like a natural way to keep related (grouped) methods organized. It's easier to get an overview of the skx library as well, if they are all stored in the skx root rather than in many sub folders.

[ScottLininger]

I don't think I want one large file. But one per class/module sound like a natural way to keep related (grouped) methods organized. It's easier to get an overview of the skx library as well, if they are all stored in the skx root rather than in many sub folders.

I agree.

[Jim]

I've asked Csaba for a separate forum for this project, so hopefully soon we can have more than one topic...

[thomthom]

I've asked Csaba for a separate forum for this project, so hopefully soon we can have more than one topic...

Good idea.