Implement an API

[thomthom]

Discussions around other issues show that we need an API to the importer and exporter. An API will have multiple purposes:

• Import/Export can be unit tested.
• Import/Export can be profiled - checked for performance.
• Can be called externally without the UI

Any thoughts on the design?

[thomthom]

Reference Issue: #26

(There's at least another - but I cannot find it right now.)

[scottlininger]

First step is to refactor so any UI calls are decoupled from the actual work of importing or exporting. Then start writing unit tests of each method, using optional dependency injection in the constructor to make the tests run instantly and without user interaction.

For example, instead of calling UI.foo inside our code, we'd inject at constructor time a ui_module param, then all internal calls do through @ui_module.foo. If nothing is passed in, it defaults to the usual UI bit. Then you can write your own UI module inside your unit test where UI.messagebox does something predictable.

As for the design of the import/export API itself, I'd need to think about it. Is import always done directly into the model? Should it create and return a new group? Lots of ways...

[scottlininger]

Would it be possible to extend Model.export to understand .stl inherently? That might be the best export API.

[jimfoltz]

Would it be possible to extend Model.export to understand .stl inherently?

Wouldn't that need done on the C++ side? On second thought, could it be done using Ruby by aliasing the export method?

[jimfoltz]

Is import always done directly into the model? Should it create and return a new group?

The way I wrote it is if there is already >0 entities in the model, then a new group is used so as not to interfere. If not, then geometry is added to the model. I think I based it on how the dxf importer worked.

[ChrisFullmer]

Yeah, that is how dwgs import.

On Wed, Nov 21, 2012 at 4:50 PM, Jim Foltz notifications@github.com wrote:

Is import always done directly into the model? Should it create and return
a new group?

The way I wrote it is if there is already >0 entities in the model, then a
new group is used so as not to interfere. If not, then geometry is added to
the model. I think I based it on how the dxf importer worked.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-10620284.

[thomthom]

Wouldn't that need done on the C++ side? On second thought, could it be done using Ruby by aliasing the export method?
You can alias it yes. But what worries me is, what if other exporters do the same. How can they be chained so they do not cause conflicts?

I think I'd prefer if the Ruby API was modified on the SketchUp side of things so that Model.export would query registered sets of Exporters if they can handle the filetype. (Provided we get an Exporter class, similar to Importer.)