www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Short forum post on REST API

reply Adam D. Ruppe <destructionator gmail.com> writes:
I just quickly wrote this up describing an idea I had earlier
today on combining rest api calls (example: foo(bar(10)) should be
just one call to the server) on a little forum I post to:

http://www.sveit.com/forum/viewtopic.php?f=11&t=3364

It's not really D specific, but I used D as my language to discuss
the idea, so I figured I'd share it here too. A lot of people I
talk to are surprised that I've been using D2 to write professional
websites and client apps alike for the last year, so I plan to write
more posts like this to explain how I'm doing things.

Like with this, a lot of the ideas are things that /could/ be done
in Javascript, PHP, etc., but it's never as elegant, or IMO as obvious,
to do as it is in D.
Apr 01 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:in63uu$b41$1 digitalmars.com...
I just quickly wrote this up describing an idea I had earlier
 today on combining rest api calls (example: foo(bar(10)) should be
 just one call to the server) on a little forum I post to:

 http://www.sveit.com/forum/viewtopic.php?f=11&t=3364

 It's not really D specific, but I used D as my language to discuss
 the idea, so I figured I'd share it here too. A lot of people I
 talk to are surprised that I've been using D2 to write professional
 websites and client apps alike for the last year, so I plan to write
 more posts like this to explain how I'm doing things.

Nice, common-sense-driven design strategy. Not enterprisey at all. I like it :) And it doesn't toss yet another layer on top the mess of 100 poorly-designed layers that the (aptly named) web is already made^H^H^H^Hhacked together with. A few minor typos: ApiValue!int sueFunction(int a, int b); // <-- I doubt it's really a litigation function umberToString // <-- Funny, but probably not accurate My only concern is how much can multiply-nested calls balloon the query string, and can that be an issue? And what about the feasability of something like this: foo(bar() + 2)
 Like with this, a lot of the ideas are things that /could/ be done
 in Javascript, PHP, etc., but it's never as elegant, or IMO as obvious,
 to do as it is in D.

The only way to make *anything* clean or elegant in JS or PHP is to not use them at all and say you did ;) Well, either that or a change in perspective via self-inflicted brain damage, but I prefer the former.
Apr 02 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:in6i74$16pd$1 digitalmars.com...
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:in63uu$b41$1 digitalmars.com...
I just quickly wrote this up describing an idea I had earlier
 today on combining rest api calls (example: foo(bar(10)) should be
 just one call to the server) on a little forum I post to:

 http://www.sveit.com/forum/viewtopic.php?f=11&t=3364

 It's not really D specific, but I used D as my language to discuss
 the idea, so I figured I'd share it here too. A lot of people I
 talk to are surprised that I've been using D2 to write professional
 websites and client apps alike for the last year, so I plan to write
 more posts like this to explain how I'm doing things.

Nice, common-sense-driven design strategy. Not enterprisey at all. I like it :) And it doesn't toss yet another layer on top the mess of 100 poorly-designed layers that the (aptly named) web is already made^H^H^H^Hhacked together with. A few minor typos: ApiValue!int sueFunction(int a, int b); // <-- I doubt it's really a litigation function umberToString // <-- Funny, but probably not accurate My only concern is how much can multiply-nested calls balloon the query string, and can that be an issue? And what about the feasability of something like this: foo(bar() + 2)
 Like with this, a lot of the ideas are things that /could/ be done
 in Javascript, PHP, etc., but it's never as elegant, or IMO as obvious,
 to do as it is in D.

The only way to make *anything* clean or elegant in JS or PHP is to not use them at all and say you did ;) Well, either that or a change in perspective via self-inflicted brain damage, but I prefer the former.

BTW, I love your signature line over there. :) I know IE gets flamed for not following the standards, and perhaps rightly so, but sometimes the IE-classic-way just makes the standards-way look like shit. Such as the way the mouse-buttons are handles in JS, or what the "width" and "height" attributes refer to. I just had a quick look at YQL. I can't believe they chose SQL to base it off of. If you ask me, SQL is the COBOL/VB of the DB world, except it actually stuck.
Apr 02 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:
 I know IE gets flamed for not
 following the standards, and perhaps rightly so, but sometimes the
 IE-classic-way just makes the standards-way look like shit.

Yup. I always put some slightly inflammatory line in my signature over there (and my avatar is usually ironic in some way). I think the whole web standards thing is a pile of nonsense. Well, it's good to have, but the attitude behind them, especially toward IE, is just ridiculous. Virtually everything "web 2.0" is built on was invented by IE - hence the signature line. There's some new standards fixing the old standard... by making it act like old IE. (box-sizing in CSS is the big one.) But, noooo, IE is evil. If there's something IE started that they don't like, it's OH NOES PROPRIETARY EVILNESS... but if Google does the same thing, it's STILL IE's fault for not instantly cloning Google's proprietary crap! Unbelievable. And, that brings me to something else. I hate the way the browsers are so focused on poorly running DOOM in Javascript, but they all ignore basic usability issues. Take one that got me recently: file uploads don't give feedback. How hard would it be for the browser to put in some kind of progress bar over the form or something instead of just hanging for a few minutes? But noooo, we need WebGL. Oh, I could rant about this all day, better not get too far off topic again!
 If you ask me, SQL is the COBOL/VB of the DB world, except it
 actually stuck.

I don't know, it seems OK enough for the database, though it has issues I hate (hence my recent database.d module). But reinventing it is so weird. Facebook did it too, but they at least had the good sense of ditching their FQL for the most part in favor of the new graph api, which is far more traditional in form.... and far easier to use.
Apr 02 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:in7fuh$2rfu$1 digitalmars.com...
 Nick Sabalausky wrote:
 I know IE gets flamed for not
 following the standards, and perhaps rightly so, but sometimes the
 IE-classic-way just makes the standards-way look like shit.

Yup. I always put some slightly inflammatory line in my signature over there (and my avatar is usually ironic in some way). I think the whole web standards thing is a pile of nonsense. Well, it's good to have, but the attitude behind them, especially toward IE, is just ridiculous. Virtually everything "web 2.0" is built on was invented by IE - hence the signature line. There's some new standards fixing the old standard... by making it act like old IE. (box-sizing in CSS is the big one.) But, noooo, IE is evil. If there's something IE started that they don't like, it's OH NOES PROPRIETARY EVILNESS... but if Google does the same thing, it's STILL IE's fault for not instantly cloning Google's proprietary crap! Unbelievable. And, that brings me to something else. I hate the way the browsers are so focused on poorly running DOOM in Javascript, but they all ignore basic usability issues. Take one that got me recently: file uploads don't give feedback. How hard would it be for the browser to put in some kind of progress bar over the form or something instead of just hanging for a few minutes? But noooo, we need WebGL. Oh, I could rant about this all day, better not get too far off topic again!

Cue sound bite of "Uh-huuh! You go, girl! (three finger snaps here)". One of the things that gets me is the new video tag. The first time I heard about "this great new video tag" my reaction was "What they hell are they talking about? We've already has that since the 90's! It's called the object tag, and it works for more than video." Then later on when I needed to embed sound into a page (not my idea, I assure you) I discovered that the *cough* "good" browsers like Chrome don't support it. I had to embed the damn media into flash - something I'd sworn I'd never do. About the file uploads: I bet they'd rather have it driven by JS and have a DHTML (or canvas tag) progress bar. And most likely driven by a Google API, of course. It would figure: Web people all for standards when it comes to protocols, no mater how bad the standard is, but when it comes to client-driven UI standards it's, "Hell no, we won't be having any of that!" Heck, when was the last time you saw a DHTML menu bar that actually behaved like menu bars on any real OS? The real ones dropdown on a click, always, never on a mouseover (and very thankfully so). Web apps make GTK apps seem like they're actually native (assuming a non-Gnome OS, of course). And what makes all of this truly pathetic (as if it weren't already) is how it's all so blatantly trend-driven that it makes the fasion industry look almost down-to-Earth. God I hate the web.
 If you ask me, SQL is the COBOL/VB of the DB world, except it
 actually stuck.

I don't know, it seems OK enough for the database, though it has issues I hate (hence my recent database.d module). But reinventing it is so weird.

Well, SQL is at least tolerable if you're just doing basic queries: SELECT, INSERT, UPDATE, no nested selects, no TSQL, etc. One you start getting into that other stuff, that's when it really gets irritating (so I avoid such things whenever I can get away with it, even if it is at the expense of a little speed - but everyone else is happily using PHP, so it's not like anyone even cares about speed on a web server anyway.) Although even with those basic queries, SQL's psuedo-English syntax strikes me as uncomfortably COBOL/VB. And I never could shake the impression that INSERT and UPDATE were designed in isolation by two completely separate teams. Meh, at least it's statically-typed. These days, I should be happy just to have that.
 Facebook did it too, but they at least had the good sense of
 ditching their FQL for the most part in favor of the new graph
 api, which is far more traditional in form.... and far easier
 to use.

Yea, thank goodness for non-SQL DB APIs.
Apr 02 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:in7fuh$2rfu$1 digitalmars.com...
 But noooo, we need WebGL.

Heh, yup. Because after all, VRML just went over sooo well.
Apr 02 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky:
 Heh, yup. Because after all, VRML just went over sooo well.

Yeah... "what's old is new again" fits so well to web 2.0. WebGL gets more minus points too since its on shaky technical grounds too. It isn't very 'webby' if you will and may have security implications... but wheee you can make shitty ports of old games to the browser!
Apr 02 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 00:22, schrieb Adam D. Ruppe:
 Nick Sabalausky:
 Heh, yup. Because after all, VRML just went over sooo well.

Yeah... "what's old is new again" fits so well to web 2.0. WebGL gets more minus points too since its on shaky technical grounds too. It isn't very 'webby' if you will and may have security implications... but wheee you can make shitty ports of old games to the browser!

If it helps killing Flash I'm fine with WebGL, HTML5-videotag (I hope google's WebM will win) etc. However that shouldn't be used in serious (non demo/showcase) websites until proper support is ready in all major browsers. As a web developer you should be glad that IE5/6's days are over and browsers are a more standard-conformant - or did you like writing a different version of your websites for each browser? A friend of mine who does web programming complained about having to work around IE6's anomalies a lot until he could finally stop supporting it, so I'm kind of surprised that you and Nick seem to like these old versions of the IE. Cheers, - Daniel
Apr 02 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Daniel Gibson wrote:
 or did you like writing a different version  of
 your websites for each browser?

I've never found that to be actually necessary. Worst problems I ever had as a developer were actually Firefox 2... while IE6 and 7 might have needed a few hacks, they could always do the job. Firefox 2 often left me hanging. I hated that piece of junk. Anyway, with IE6 (IE5 is before my time), the worst that I ever needed was a few isolated lines of javascript - which can be abstracted into reusable functions - and a few little bits of CSS, easily done with conditional comments. It's really very little work, more like 10% more than the 100% more implied by "different version [..] for each browser". Hell, I think I spend more time writing border-radius -moz-border-radius -webkit-border-radius and similar -browser- prefixes over and over again than I spent doing IE6 adjustments. That said, I am happy to see it mostly gone, even if it's replacements still suck in their own ways.
 surprised that you and Nick seem to like these old versions of the IE.

The real surprise is how much of HTML5 is just mimicing IE5's functions! It's a good decision, just an ironic one.
Apr 02 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 01:31, schrieb Adam D. Ruppe:
 Daniel Gibson wrote:
 or did you like writing a different version  of
 your websites for each browser?

I've never found that to be actually necessary. Worst problems I ever had as a developer were actually Firefox 2... while IE6 and 7 might have needed a few hacks, they could always do the job. Firefox 2 often left me hanging. I hated that piece of junk. Anyway, with IE6 (IE5 is before my time), the worst that I ever needed was a few isolated lines of javascript - which can be abstracted into reusable functions - and a few little bits of CSS, easily done with conditional comments. It's really very little work, more like 10% more than the 100% more implied by "different version [..] for each browser".

Yeah, it may not be 100% - however I've heard from other people and read on the web that supporting IE6 was really time intensive - more than 10%. But it's just what I heard/read, I haven't got much experience with web development myself.
 Hell, I think I spend more time writing
 
 border-radius
 -moz-border-radius
 -webkit-border-radius
 
 and similar -browser- prefixes over and over again than I spent
 doing IE6 adjustments.
 
 
 That said, I am happy to see it mostly gone, even if it's
 replacements still suck in their own ways.
 
 surprised that you and Nick seem to like these old versions of the IE.

The real surprise is how much of HTML5 is just mimicing IE5's functions! It's a good decision, just an ironic one.

The functions may be great - as long as they're a standard and everybody supports them. But using functions that only work properly on a single browser sucks.
Apr 02 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:in8c2g$knb$3 digitalmars.com...
 Am 03.04.2011 01:31, schrieb Adam D. Ruppe:
 Daniel Gibson wrote:
 or did you like writing a different version  of
 your websites for each browser?

I've never found that to be actually necessary. Worst problems I ever had as a developer were actually Firefox 2... while IE6 and 7 might have needed a few hacks, they could always do the job. Firefox 2 often left me hanging. I hated that piece of junk. Anyway, with IE6 (IE5 is before my time), the worst that I ever needed was a few isolated lines of javascript - which can be abstracted into reusable functions - and a few little bits of CSS, easily done with conditional comments. It's really very little work, more like 10% more than the 100% more implied by "different version [..] for each browser".

Yeah, it may not be 100% - however I've heard from other people and read on the web that supporting IE6 was really time intensive - more than 10%. But it's just what I heard/read, I haven't got much experience with web development myself.

My experience with IE6 (from back in the day) has been much like Adam's. Yea, sometimes something would be a little bit different on the two or three different browsers that were out there, but I never found it to be a real problem. I suspect that most of the big complaints about it were from people who didn't understand the medium enough to know that being pixel-perfect wasn't (isn't) appropriate.
Apr 02 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:in889j$knb$1 digitalmars.com...
 Am 03.04.2011 00:22, schrieb Adam D. Ruppe:
 Nick Sabalausky:
 Heh, yup. Because after all, VRML just went over sooo well.

Yeah... "what's old is new again" fits so well to web 2.0. WebGL gets more minus points too since its on shaky technical grounds too. It isn't very 'webby' if you will and may have security implications... but wheee you can make shitty ports of old games to the browser!

If it helps killing Flash I'm fine with WebGL,

My immeditate reaction is to agree with you on that, because direct experience as both a flash-user and as a flash-developer has given me a strong personal hatred towards Flash. But, if WebGL is driven by in-browser JS (as I *think* it is, not that I've studied it closely), then I dunno, suddenly Flash doesn't sound quite so bad anymore. Heck, at the very least, Flash is already in byte-code when it's distributed, and the "JS-as-the-web's-asm" idea just gives me a rash. Plus it's cleaner/easier to block flash than to block specific JS features. Etc.
 [If it helps killing Flash I'm fine with] HTML5-videotag

I dunno. The thing that still bugs me about that is we *already* had the object tag, but then ever since YouTube came along everyone just stopped using it, Google outright left it out of Chrome, etc. It was just plain killed off in favor of flash. And now, ages later, they reinvent the object tag and try to convince me it'll finally pull web-A/V out of the flash shackes that *they* had placed web-A/V into in the first place? Even if I did feel that I could trust that claim (a shaky prospect), the fact remains that we *already* had a solution.
 (I hope google's WebM will win) etc.

Oh god yes. I suppose everyone knows I'm, well, not exactly a big Google fan, but the legal ball-and-chain that's welded to H.2[0-9][0-9] (whatever the hell it's called) just leaves it a complete non-option, IMO. I'd sooner use flv and an embedded player - and I've always hated the whole concept of flash video players.
 However that shouldn't be used in serious (non
 demo/showcase) websites until proper support is ready in all major 
 browsers.

 As a web developer you should be glad that IE5/6's days are over and 
 browsers
 are a more standard-conformant - or did you like writing a different 
 version  of
 your websites for each browser?
 A friend of mine who does web programming complained about having to work 
 around
 IE6's anomalies a lot until he could finally stop supporting it, so I'm 
 kind of
 surprised that you and Nick seem to like these old versions of the IE.

I don't really mean to say that I like the old IEs. It's just that: 1. They weren't nearly as bad as the Google/W3C fan brigade would have everyone believe. 2. They did a number of things that put the W3C-sanctioned equivalents to shame. (Things that are rarely acknoledged). 3. The "standards" are only now just starting to catch up in features, which kinda pulls the wind out of HTML5's sails. HTML5 isn't bad, it's just that it takes credit for things that it, 1. Stole from IE, and then 2. Changed in a non-backwards-comptible way (much like MS is often demonized for doing.)
Apr 02 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 08:59, schrieb Nick Sabalausky:
 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:in889j$knb$1 digitalmars.com...
 Am 03.04.2011 00:22, schrieb Adam D. Ruppe:
 Nick Sabalausky:
 Heh, yup. Because after all, VRML just went over sooo well.

Yeah... "what's old is new again" fits so well to web 2.0. WebGL gets more minus points too since its on shaky technical grounds too. It isn't very 'webby' if you will and may have security implications... but wheee you can make shitty ports of old games to the browser!

If it helps killing Flash I'm fine with WebGL,

My immeditate reaction is to agree with you on that, because direct experience as both a flash-user and as a flash-developer has given me a strong personal hatred towards Flash. But, if WebGL is driven by in-browser JS (as I *think* it is, not that I've studied it closely), then I dunno, suddenly Flash doesn't sound quite so bad anymore. Heck, at the very least, Flash is already in byte-code when it's distributed, and the "JS-as-the-web's-asm" idea just gives me a rash. Plus it's cleaner/easier to block flash than to block specific JS features. Etc.

But Flash is a notorious security hole, sometimes crashes the browser, ...
 
 [If it helps killing Flash I'm fine with] HTML5-videotag

I dunno. The thing that still bugs me about that is we *already* had the object tag,

The problem was that there were different codecs for videos (windows media, real media, ...) and often websites prompted you to install their codec.. which sometimes distributed malware etc. It's better to have a video tag with a standard codec that is supplied by the browser.
 but then ever since YouTube came along everyone just stopped 
 using it, Google outright left it out of Chrome, etc. It was just plain 
 killed off in favor of flash. And now, ages later, they reinvent the object 
 tag and try to convince me it'll finally pull web-A/V out of the flash 
 shackes that *they* had placed web-A/V into in the first place? Even if I 
 did feel that I could trust that claim (a shaky prospect), the fact remains 
 that we *already* had a solution.
 
 (I hope google's WebM will win) etc.

Oh god yes. I suppose everyone knows I'm, well, not exactly a big Google fan, but the legal ball-and-chain that's welded to H.2[0-9][0-9] (whatever the hell it's called) just leaves it a complete non-option, IMO. I'd sooner use flv and an embedded player - and I've always hated the whole concept of flash video players.

Flash also supports H.264 and other patented MPEG crap.
Apr 03 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:inaa6r$27f3$1 digitalmars.com...
 Am 03.04.2011 08:59, schrieb Nick Sabalausky:
 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:in889j$knb$1 digitalmars.com...
 If it helps killing Flash I'm fine with WebGL,

My immeditate reaction is to agree with you on that, because direct experience as both a flash-user and as a flash-developer has given me a strong personal hatred towards Flash. But, if WebGL is driven by in-browser JS (as I *think* it is, not that I've studied it closely), then I dunno, suddenly Flash doesn't sound quite so bad anymore. Heck, at the very least, Flash is already in byte-code when it's distributed, and the "JS-as-the-web's-asm" idea just gives me a rash. Plus it's cleaner/easier to block flash than to block specific JS features. Etc.

But Flash is a notorious security hole, sometimes crashes the browser, ...

Yea, like I said, I do hate flash. It's just that pitting it against JS strikes me as the age-old "shit sandwich vs giant doucebag" debate. (/me tips hat to South Park)
 [If it helps killing Flash I'm fine with] HTML5-videotag

I dunno. The thing that still bugs me about that is we *already* had the object tag,

The problem was that there were different codecs for videos (windows media, real media, ...) and often websites prompted you to install their codec.. which sometimes distributed malware etc. It's better to have a video tag with a standard codec that is supplied by the browser.

The W3C could just as easily have said "use the object tag, use the X codec; any using-a-special-codec feature of the object tag is depricated".
Apr 03 2011
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:
 A few minor typos:

Ah, the result of me being slightly lazy and changing the name of the functions. First, I called it "someFunction", then changed my name to the homophone "sumFunction" so it'd actually do something. But, I did changes without proofreading afterward!
 My only concern is how much can multiply-nested calls balloon the
 query string, and can that be an issue?

I'm not sure; I just thought it up yesterday and haven't actually used it yet. But, I'm not too concerned. Odds are most calls would be simple; I rarely want to do much mixing of web api calls anyway. If it's too long for a query string, the same approach works for POST values too - the body of a POST request is encoded the same way as a query string, so same approach works there too.
 And what about the feasability of
 something like this: foo(bar() + 2)

I wouldn't want to build a whole language into the url, so this would have to be offered as function. Then you simply do operator overloading on the ApiValue struct to combine it, all lazily. bar() -> ApiValue!int ApiValue!int.opBinary!("+")(2) -> calls the server side sumFunction, returning an new ApiValue, like seen in the original post. And hah, I think D now is doing something Javascript just can't do. We can hack through dynamic typing, but I don't think the current version has op overloading at all.
 The only way to make *anything* clean or elegant in JS or PHP is
 to not use them at all and say you did

This is basically how I do them... that's one reason why I was writing this. There's not really much need to access the http apis I write through D - I can just "import mymodule;" instead. Exception: I write a client gui app a few weeks ago that worked with the web server, so I used my api functions there. But, I did it by diving into std.concurrency, so it needed a different approach... Now, I wonder if the get() function with callback could do it in a different thread... probably not, the closure would be thread local. But, passing it to some regular function pointer would probably work. Anyway, I'm digressing. Now though, there's some external PHP components on external servers being added to the application, so I've gotta make sure it's accessible from there easily enough too.
Apr 02 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
I just implemented the concept described in that post in my web.d,
and earlier in the week, implemented automatic Javascript bindings
generation.

Here's a live demo:
http://arsdnet.net/apidemo.html

This is the server side implementation:
http://arsdnet.net/apidemo.d

Do not adjust your text editor - it's actually a mere 14 lines long.
You just write D functions.

Most the work is done in the helper modules
http://arsdnet.net/dcode/web.d

Depends on:
http://arsdnet.net/dcode/cgi.d
http://arsdnet.net/dcode/dom.d


(btw the struct members are all static due to a decision decision
I think I've changed my mind on, but haven't changed the code
yet. I think a class would be better though - can slash a lot of
the __traits(compiles) if I just use virtual functions.)

There's other features available in web.d not used here, like
automatic and hookable html form generation, output format
post processing, initialization functions, etc. You can also
accept a Cgi and ReflectionInfo object in the initializer if you
want to do more traditional web things or see what you have
in that struct.

(Originally, the idea was to autogenerate websites, so there's
a lot of code for datatype -> html, html templates, html forms,
etc. All that still works, of course:

http://arsdnet.net/cgi-bin/apidemo/foo

But I've been playing with program access recently, since I actually
prefer the traditional method of making the pages on the whole.
Since they can exist side by side in the same executable, it's
pretty awesome still.)


Anyway, FancyMain just calls three other functions, wrapped up
in a main:

    auto reflection = prepareReflection!(T)(cgi);
    run(cgi, reflection);

ReflectionInfo stores piles of info about your passed object.
All functions (and still to do: enums and structs) are checked
out. Their return type, name, and arguments - both names and types -
are stored. A template also generates a wrapper function that
makes the call from cgi info.

run() takes the cgi pathinfo and get/post data to call the wrapper.
It also catches exceptions to either handle automatically in the
case of html or wrap up for the other system in case of json.


run() also does a little piece of magic. If the path requested
is functions.js... it uses the reflection info to generate a
javascript object that mimics the D struct, along with some
other info:

http://arsdnet.net/cgi-bin/apidemo/functions.js

(See the bottom for the D function wrappers. There's quite a bit
of javascript there that I just wrote in web.d straight up.)

Note how the JS object name matches the D struct name too, and
the argument names match up.

also, if it's compiled in debug mode, the Javascript is made in
debug mode, giving better error messages, etc.


I might write an automatic PHP too, but php can actually call
the api functions without needing a code generator - it has
a feature similar to D's opDispatch. Using web.d's positional
argument support, it can just forward to the server without knowing
anything. (Some vendor's implementations of javascript have this
too, but you can't depend on it, so the codegen is better.)


There's a bunch of helper callbacks there too, to make using
the function return value easier in the async environment.

You can see that in apidemo.html - in the end, it does appendTo(),
which takes the returned string, treats it as html, and appends it
to the given element.

I'm planning on adding better typechecking there - if you return
a Html() or Element in D, it is html. If it's a string, it should
do append text instead. The static types are there - let's use them.




Anyway, enough blabbing. The interesting thing here is what all D
could do to make this work. When I get around to writing my
article, I'll discuss what it can do again, but also go into
how much of a pain it is to do this kind of thing in PHP and other
popular languages for both calling and implementing the web api.

D's built in documentation naturally helps here too. All the stuff
is generated from the same place, so it's easy to doc too.

I saw a php thing that tries to do the same, for example, but
you had to do things just write, had to manually register the
functions, and couldn't just write javascript normally... and, of
course, it's php. Ugh.
Apr 17 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Oh btw, the returned errors kick ass. Exceptions cross the
divide pretty well intact - it just works, and the messages
(in firefox at least) are pretty awesome. Try making errors too!
Apr 17 2011
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Wow... actually, the names aren't always right, including in the
example.

I used a ParameterNamesOf!(), written by a newsgroup member a while
ago (I don't remember who), which cleverly uses typeof().stringof
and parses it to extract parameter names.

Strangely though, dmd seems to use the parameter names off the first
function of that type it sees.

Here, "int num" was first, so it used int num everywhere. If you
switch the second function "int wat" to the first position, dmd
gives that for both of them!


Of course, it works because the program uses the same method
to generate the code as to parse it. It's all consistent so it
works. My PHP based external caller uses positional parameters,
so it doesn't matter either. Only if you were to manually type
the argument names would you notice something fail.

But, I used the arg name for error messages and generated forms,
so it might be  noticeable there - it won't necessarily match up
with the documentation.

Blargh. But hey, it all works anyway! And if your signatures aren't
the same, the names work too. Even if they didn't work at all
though, this is still pretty win, especially if the D functions
return DOM elements!

Still to come: use D's reflection to give more behavior to pure
functions. Memoizing them (that is, using the HTTP cache
automatically) could give a huge benefit here.
Apr 17 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:iog3q7$2hn6$1 digitalmars.com...
I just implemented the concept described in that post in my web.d,
 and earlier in the week, implemented automatic Javascript bindings
 generation.

 Here's a live demo:
 http://arsdnet.net/apidemo.html

 This is the server side implementation:
 http://arsdnet.net/apidemo.d

 Do not adjust your text editor - it's actually a mere 14 lines long.
 You just write D functions.

Heh, sweet :) D's awesome.
Apr 26 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
=46rom talking to our web programmers, each browser still has anomalies that=
 must be worked around. IE is no exception.=20

Sent from my iPhone

On Apr 2, 2011, at 3:30 PM, Daniel Gibson <metalcaedes gmail.com> wrote:

 Am 03.04.2011 00:22, schrieb Adam D. Ruppe:
 Nick Sabalausky:
 Heh, yup. Because after all, VRML just went over sooo well.

Yeah... "what's old is new again" fits so well to web 2.0. =20 WebGL gets more minus points too since its on shaky technical grounds too. It isn't very 'webby' if you will and may have security implications... but wheee you can make shitty ports of old games to the browser!

If it helps killing Flash I'm fine with WebGL, HTML5-videotag (I hope goog=

 WebM will win) etc. However that shouldn't be used in serious (non
 demo/showcase) websites until proper support is ready in all major browser=

=20
 As a web developer you should be glad that IE5/6's days are over and brows=

 are a more standard-conformant - or did you like writing a different versi=

 your websites for each browser?
 A friend of mine who does web programming complained about having to work a=

 IE6's anomalies a lot until he could finally stop supporting it, so I'm ki=

 surprised that you and Nick seem to like these old versions of the IE.
=20
 Cheers,
 - Daniel

Apr 07 2011