Aha - got you. Good plan for offline development - though secondary in terms of priority I'd say to having remote server based solution? NB - is the external based on one of the C based open source server projects?
On 15 September 2010 17:19, Andre Garzia <[email protected]> wrote: > David, > > I think I was misunderstood on the two environment part. When I say web > server and Rev IDE I am not saying remote web server in the sense of a > server far away but a little process running alongside the IDE on the same > machine. Not unlike the mongrel/ruby coupling. > > You'll be working all on client side. No wasted bandwidth or extra CPU > power > required. > > You need, in my opinion, the server running to be able to develop in an > environment that is equal to your deployment option so that you don't end > up > with cycles such as: > > 1 - build stuff in Rev > 2 - convert it to web > 3 - run it and it does not work or does not layout right > 4 - back to Rev > > > If you're constantly building and tweeking inside a HTML5 enabled window, > you get the following benefits: > > 1 - You avoid any conversion need since you are already on the deployed > environment > 2 - WYSIWYG approach, what you see on the canvas is exactly what the client > will see, no need to compile or translate anything > > This way we maintain one of the strongest features of Rev which is being > able to develop incrementally avoiding the overhead of compile-debug-code > loops. > > So in summary: > 1 - the server is there because we need something to output as > real-as-possible data to a RevBrowser window inside Rev IDE where the > development will be done. > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
