I am just wondering. Would it be possible to Servoy implement some kind of functionality that allow us to control the code executed in Server Side and Client Side.
Currently we know the code in the form’s JavaScript is executed locally, and when Servoy needs to access the database because of a query, for example, it will use RMI and go to the server. Also, I am aware it’s possible to control the code executed in the server side through a remote plugin.
However, I am looking for the possibility of writing Servoy (in Servoy, not Java) code that is executable in the server side. If Servoy had a way to do this we would be able to improve much more the performance placing the business logic there, creating facades where within only one remote call I could execute many others calls that would be remote otherwise.
One way to do this is if we had a different kind of object apart from forms, where we could write code, and Servoy would control the execution to be in server side.
I’m looking for some opinions and if all this is suitable for a feature request.
In Servoy 5.1 you can now spawn a headless client (think WebClient without the webbrowser) where you start a method and optionally tell it call back a method in your local solution when it’s done.
You find this functionality in the headlessclient plugin (see plugins node in the solution tree)
I am just wondering. Would it be possible to Servoy implement some kind of functionality that allow us to control the code executed in Server Side and Client Side.
…
One way to do this is if we had a different kind of object apart from forms, where we could write code, and Servoy would control the execution to be in server side.
I’m looking for some opinions and if all this is suitable for a feature request.
Servoy flipping rocks in this area. To give you some ideas, we exchange project data between Final Cut Server and Servoy. This is done by exchanging XML data with FCS via “in” and “out” folders at the server.
Using Servoy batch processor functionality, we have Servoy polling the FCS “out” folder. If a content change is detected, a method is run that processes the new XML files and inserting the data where it needs to go in the Servoy solution. Since we use batch processors quite a bit we’ve even built a generic interface to easily manage batch processes.
[attachment=1]Picture 33.png[/attachment]
For sending data to FCS, we have an interface for building FCS “events” – data mapping and code – which process passed data into FCS xml files and outputs to the FCS “in” folder. FCS continually polls this folder for changes and processes new XML files as they show up. These FCS “events” can be triggered from anywhere in the Servoy solution.
[attachment=0]Picture 32.png[/attachment]
With the new functionality that Robert mentions, triggering code and receiving confirmation is that much easier.
Pretty simple coding for very powerful functionality.
