D For A Web Developer

[Rikki Cattermole via Digitalmars-d]

On Wednesday, 30 April 2014 at 13:48:07 UTC, Adam D. Ruppe wrote:
> On Wednesday, 30 April 2014 at 04:32:33 UTC, Rikki Cattermole 
> wrote:
>> Although I definitely would like to hear more about 
>> asynchronous javascript instead of my synchronous based code 
>> and how I can combine it at some point.
>
> The way it works in mine is the proxy object sets a kinda 
> magical helper value in the URL params, telling it to evaluate 
> the named function instead of just trying to convert the data 
> to the right time.
>
> So for that one, the regular might be /add?a=1&b=2. With the 
> nested call, we want a={the result of /add?a=1&b=2)&b=3.
>
> So it passes it as something like this: "/add?" + 
> urlencode("a=/add?a=1&a=2") + "&b=2&a-type=ServerResult";
>
> So the special "a-type=" tells it that a should not be 
> converted to an integer, but instead parsed and called.
>
> The same url parser deconstructs it into a function call and 
> gets the data out (currently, the implementation does it 
> through string intermediaries for ease; it almost literally 
> replaces that with the result in the URL, then re-parses it).
>
> This avoids extra calls to the server since it is all done in 
> one set. There's also ways to filter the results that way, for 
> example running a querySelector() call on the server to filter 
> a HTML result for JS.
>
>
>
> Then, the JS call itself is either synchronous or asynchronous. 
> The sync calls are done with the .getSync method. This 
> generally sucks so I rarely use it, but one cool thing about it 
> is exceptions from the D side are propagated to the Javascript 
> side, making error handling natural. (This is also the way my 
> web.d.php works - it uses PHP's version of opDispatch to make a 
> little class that translate's PHP function calls to http 
> requests for talking to the server. It always uses synchronous 
> calls.... which sucks btw, but it is awfully easy to use: $a = 
> $Foo->add(1, 2).getSync();)
>
> The asynch ones just do pretty regular AJAX requests with a 
> callback. The only thing that's interesting is I used the apply 
> function in JS to make it kinda nice:
>
>    return callback.apply(callbackThis, ourArguments);
>
> So things like this kinda works sanely, arguments you pass are 
> forwarded, etc.
>
>
> function someFunction(something, another, result) {}
>
> Foo.add(1,2).get(someFunction, "hey", this); // will call 
> someFunction("hey", this, 3);
>
>
> Naturally, there's on error callbacks too that can work the 
> same way. D exceptions are passed as JS objects. (Indeed, in 
> general, all the results from D are passed as objects, it does 
> some JSON.parse action on the JS side and automatic 
> serialization on the D side so many things just work.)

I see I see. I was assuming there wasn't too much changed on the 
server side. And mostly in javascript. Netherless quite 
interesting and advanced usage.
Perhaps it could spawn some changes to the router. And hence the 
ajax route generation.