Anyway the decision is not mine, I have to provide a working web client bringing the functionality of modify features, so I need a WFS-t in the backend. Moreover I need to provide a wfs-t accessible without a proxy for architecture reasons since the web browser and the web server will be embebbed in a C++ standalone application and we cannot modify the web server to host a proxy.
The need for a proxy is dictated by security features of the browser. Most browsers will not do cross-domain XHR for very very good reasons. Its a pretty strange server that cant host a proxy. What is the servlet container that hosts your the WFS server?(and why cant the proxy live in that?). If the only WFS features you are dealing are hosted on embedded server, then you may be able to configure so request is not cross-domain. Might also depend on what exactly this embedded web browser actually is. The alternative would be protocol.script but you will be writing a lot of code to work around its limitations. Effective web apps work to principle of having the server do most of the computing so I am curious as to how serverside works for your application. I would have to say that using embedded web-server and browser + OL for a standalone C# mapping application is a pretty strange choice. OL has to work around web limitations that simply dont exist to a standalone C# application.
Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. _______________________________________________ Users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/openlayers-users
