My name is Jurica, currently I am a M.Sc student at the Faculty of Electrical Engineering and Computing (FER).
After Adis has left the project, Vedran assigned me to continue development of the Visualizer.
Therefore, I am looking forward to work with the PowerTAC community.
After my brief introduction, let's discuss about the Visualizer.
The main purpose of this thread is to discuss Visualizer refactoring.
First of all, after hearing about moving the whole PowerTAC to Spring/Java, Vedran and I decided to develop Visualizer in Spring as well.
We think that using the same technology will provide easier integration with the PowerTAC server.
First step in our work is to look for things in the old Visualizer that will be useful for the new one.
Our basic idea of Visualizer refactoring are expressed with the following bullets:
-Fully reuse of Visualizer's web design: Most of the HTML and CSS can and will be easily ported into the Spring.
-Getting rid of periodic page refresh and using Ajax instead for better user experience.
-Web design update to meet PowerTAC's requirements.
-Application logic based on Grails will not be refactored, but some of the ideas might be reused (such as MVC architecture, use of services etc.).
-We are expecting an interface/proxy on the server-side with which Visualizer will be able to communicate with the PowerTAC server. Dummy interface (simple messeage generator) for interaction between server and Visualizer would be much appreciated.
I would like you to comment on our ideas, post your own ideas for Visualizer or things that you did not like in the old Visualizer, so we can use your feedback to build succesfull solution.
Your plan looks fine to me. I especially like the intent to get rid of the periodic page updates.
The broker proxy and visualizer proxy should be simple ports of the existing grails versions. I have started a wiki page to discuss the conversion process that you might find helpful. I have not yet had time to work on the proxy code; it would be very nice if someone else could take over that part of the porting effort.
So far, I have found the porting to be relatively painless, and the resulting code runs much faster. The performance improvement is especially noticeable when running tests. Other than the ones that purposely used delays, they all run in milliseconds.