New widget: the integration action

On our radar
On the moment, when you want to add some external code to your project you need to use the integration studio. It creates some code with stubs for you, you can add your code in an external party code editor (like Eclipse or Visual Studio) and later on import that in Service Studio as just another action. It's great and it works. However, the downside of this is that you need to move from SS and deal with the Integrtation Studio and the code editor.

My idea enrolls around letting it happen in Service Studio itself; no need to switch away from your beloved visual programming environment.

With the help of a new widget, you drag/drop it to your canvas. You set the necessary properties in the property pane (or maybe on a central place) and then after a double click, just program your not-so-visual, plain text code in the code editor.
The code editor will contain the basic functionality you expect a code editor to have.

I have attached an image to further explain my idea. 

P.S. This idea goes well with my other entry about making Service Studio a cross language IDE.

Created on 6 Oct 2010
Comments (3)
Hello Hans,

With this idea you are proposing that when using this widget, the code will belong to the eSpace and not to an Extension that could be shared by several eSpaces.

Although I don't consider it to be a bad idea, I fear that developers not used to OutSystems will tend to use this widget frequently to perform operations that they don't know that exist as built-in functions or that could be done in Service Studio but they don't know how to.
Hi Fernando,

Thank you for your comments. 

As for your first point: I think that it depends on how this would be implemented. I can imagine that during a publish it can be placed in or as an extension. Since the type of the action can be determined, it is possible to execute specific actions.

About your next point: you are probably right. However I think this depends on the 'type' of developer. Some developers that like plain text development above visual development will undoubtly fall into this "trap". 

But, as an adition to my cross platform idea it could be a strong feature. Program flow and organization would be done visual while actual coding can still be plain text.

(Note that the cross platform idea is not meant to be plain text but to give every language a visual intepretation. However I can see f.i. an advantage if someone is using assembler and you don't want to be visual. Although... maybe that is also not totally impossible...)

I like this idea.

It would be good if we just killed integration studio, and integreated all its features into ServiceStudio, now you wouldnt have any problems at all; and the underlining platform will work the same way as it does right now, plus simplifes developer's life.