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.

"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.

"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.

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.

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.

"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.

"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.

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!

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

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.