Design pattern to control embedded windows user control painting from hosted web application - PART 1.

 

This client develops all of his systems as web applications as a result of EA effort they have been done. As their system architecture recommend, when they need to supply UI that can’t be achieve by HTML they are using windows user control or Java applets. Nowadays their GIS team is develop new infrastructure GIS control that will supply GIS services for systems and let systems enrich the GIS control behavior and display.

 

So together we looked for the best way to do it. We want the user (programmer) to use our visual control on one hand, but enable him to change control visualization form server side code that might use web application state. Actually we want the user control just to paint GIS background and user defined layers (graphic shapes)  while the server side should be embedded inside web application and just create painting instructors to be send to the user control.

 

To enable this one leg in the client side and one lag in server side situation we decide that the user control should access server services by calling dedicate handler that will be embedded inside the hosted web application. This way each hosted web application got his instance of the handler and might interfere with the default behavior by inheriting and overriding certain handler classes.

 

The user control is based on stuck of command, when every command actually responsible for given painting action on the user control. Such painting action could be responsible for painting back ground, line or dot. The user control simply get those command stuck from server side handler and simply paint them as they appear in the stuck. The commands are passed from server side handler to client user control as XML definition and get “deserialize” into commands before commands execute. The uses of commands as intermediate between server and client enable decoupling of client from server. The server will generate painting command as needed while the client side will paint by received paint command regardless who or how paint command created. This usage also enables our solution to be adaptive and enable our user (programmer) to add new paint command. Painting commands are created using CommandFactory that creates painting commands by command name received from parsing the incoming XML string.

 

We still missing how client generate request to server and how the server side handler deals with incoming request in such a way that will enable programmers to enrich the basic code. I’ll deal with those topics tomorrow.

2 Comments

  • Hi Natty,



    Thanks for your blog.



    Have you looked into SVG. This supports pretty much what you are doing. Why create your own drawing routines, when you can just generate the SVG on the fly from the server.



    Blair

  • Hi Blair,



    yes of course,

    1) SVG shows really bad performance when he need to deal with tens of thousands of objects.



    2) it's not the perfect solution for GIS applications. its better to use ESRI or Map Point to generate basic images with request layers. then just to add your own geographical oriented objects.



    Natty.

Comments have been disabled for this content.