"Adam Ruppe" <destructiona...@gmail.com> wrote in message news:jbj23n$p68$1...@digitalmars.com... > Nick Sabalausky Wrote: >> The only problem now is that that would rule out the possibility of >> sharing code between both server and client - Which is *NOT* something I >> want to give up... > > What kind of code is it?
Flash. A demo of it is here: www.attentionworkout.com (Pardon the voiceovers, that's a requirement that's outside of my control.) Basically, there's a series of "activities" that are (by necessity) Flash SWFs (but written in Haxe). These activities collect as much performance information as possible (including various timings, and in the case of the Radio, a log with enough info to "play back" the performance and re-interpret it however desired.) The whole thing was designed to be used in clinical trials on the elderly (which it's currently going through), so data collection/analysis, correctness/reliability, and compatibility were important concerns. (And naturally, flashiness and polish were lower priorities, which is why it...umm...doesn't exactly compete with PopCap in those regards.) For the most part, the shared PHP-server/Flash-client code is things like: - Data structures for all the results data. - Various utility functions (Such as a lerp function. And a string->int function that actually works consistently on server/client and doesn't have the other weirdness of Haxe's built-in string->int. And other such util funcs that's aren't in Haxe's std lib). - Identifiers for and URL-building for various URLs involved in the program. Even the flash apps need to refer to specific URLs now and then. - Much of the code in the custom error-notification system (which automatically logs and emails us about things like unhandled exceptions in both the server and client-side code). This includes the Exception classes. The client version will notify the server instead of recording to log/DB/email directly, but other than that it's mostly the same code on both sides. - The code which takes a log of exactly what happened (and when) during the Radio activity, and gives it an accuracy ranking between 0% - 100%. This, of course, needs to be consistent in both PHP and Flash. We could just simply record the 0% - 100% result the flash app shows to the user, but then we'd lose the ability to re-analyze the old performace data if we decide we want to change the algorithm (well, we *could*, but we'd be forced to do it in flash). Basically the shared code, aside from reducing duplication (which has well-known problems), helps to keep simple things simple, helps with consistentcy, and helps us keep our options open (hell, at some point I could probably even make it work on an iOS browser without rewriting all the client code). > The main reason for the javascript > api thing in my web.d is to help minimize the pain of duplication, > by keeping it all on the server, but still having easy client side > interface. > > Then basically your js is just event glue to various server side > functions. > > > Of course, it keeps the JS down to size... but doesn't actually let you > run code on the client written in D. Yea, actually, I don't use Haxe for JS at all. Like you, I prefer keep my JS usage minimal and hand-tuned, and don't want to pull in a ton of JS libs just to do simple DHTML tricks. (Of course, once JS/HTML5 advance to a point where they can be used as an alternative to Flash, then I'd be more likely to use Haxe->JS for those purposes.)