www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How To Dynamic Web Rendering?

reply Matthew Ong <ongbp yahoo.com> writes:
Hi,

What is the counterpart in D for replacing JSP/ASP/JRuby on Rail or some sort
of dynamic web base development?

How to compile a D code into dll to be used by apache or MS IIS?

How to also code digitally sign the DLL  that was compiled in D?

Matthew Ong
May 12 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
 What is the counterpart in D for replacing JSP/ASP/JRuby on Rail or
 some sort of dynamic web base development?

I use D for web work by using the standard CGI interface and sometimes an embedded http server. It's the best thing I've ever used.
 How to also code digitally sign the DLL  that was compiled in D?

The same way you sign any other dll/exe.
May 12 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
Hi Adam,

Thanks again for the sharp pointed answer.
 What is the counterpart in D for replacing JSP/ASP/JRuby on Rail or
 some sort of dynamic web base development?

I use D for web work by using the standard CGI interface and >sometimes
an embedded http server. It's the best thing I've ever used.

 How to also code digitally sign the DLL  that was compiled in D?

So we use external tool to do that and not a build in one?? In java, we use jarsigner with some keygen. Please bear in mind I am new to D.
May 12 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
 Could you share how or show an URL that provide sample code to do
 that in D?

Check out my D api demo: http://arsdnet.net/cgi-bin/apidemo/ Here's the source code (about 50 lines of D) http://arsdnet.net/apidemo.d And the HTML templates it uses: http://arsdnet.net/apidemo-document.html http://arsdnet.net/apidemo-javascript.html The libraries it imports are available here http://arsdnet.net/dcode/ That demo shows something relatively new I made to provide same source access to HTML and Javascript that uses D's reflection to auto-generate almost everything. You can also do more traditional style web apps. Here's a gradient generator written in D: http://arsdnet.net/cgi-bin/gradient?w=100&h=100&c1=ff0000&c2=00ff00&c4=ffff00&t=50 Source: http://arsdnet.net/gradient.d It uses my cgi.d from the dcode folder above. This code has a few features so it isn't the simplest demo, about 150 lines. It makes the png and sends it right out over the web. Hello world with cgi.d looks like this: import arsd.cgi; void main() { auto cgi = new Cgi(); cgi.write("Hello, world!"); cgi.close(); } In all my examples though, I used mixins for main functions instead of writing them directly because the mixin adds try/catch for exceptions and handles the create and close too. This would look like: import arsd.cgi; void run() { cgi.write("Hello, world!"); } mixin GenericMain!run; I also often use my D DOM library in web code too, which you see in the first example. That library is available in my folder too.
 So we use external tool to do that and not a build in one??

Yes, something like signtool.exe from Microsoft works for Windows programs. Generally, if you can do it to a C++ program, you can do it to a D program too.
May 12 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-12 16:45, Adam Ruppe wrote:
 Could you share how or show an URL that provide sample code to do
 that in D?

Check out my D api demo: http://arsdnet.net/cgi-bin/apidemo/ Here's the source code (about 50 lines of D) http://arsdnet.net/apidemo.d And the HTML templates it uses: http://arsdnet.net/apidemo-document.html http://arsdnet.net/apidemo-javascript.html The libraries it imports are available here http://arsdnet.net/dcode/

How is it working out with a static type system, compared to a dynamic, for web development? -- /Jacob Carlborg
May 13 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:iqilmh$7tk$1 digitalmars.com...
 On 2011-05-12 16:45, Adam Ruppe wrote:
 Could you share how or show an URL that provide sample code to do
 that in D?

Check out my D api demo: http://arsdnet.net/cgi-bin/apidemo/ Here's the source code (about 50 lines of D) http://arsdnet.net/apidemo.d And the HTML templates it uses: http://arsdnet.net/apidemo-document.html http://arsdnet.net/apidemo-javascript.html The libraries it imports are available here http://arsdnet.net/dcode/

How is it working out with a static type system, compared to a dynamic, for web development?

<bias amount="very-large" inflammatory="potentially"> Much better I would imagine, since dynamic type systems suck &donkeyballs;. </bias>
May 13 2011
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 13/05/2011 08:09, Jacob Carlborg wrote:
 On 2011-05-12 16:45, Adam Ruppe wrote:
 Could you share how or show an URL that provide sample code to do
 that in D?

Check out my D api demo: http://arsdnet.net/cgi-bin/apidemo/ Here's the source code (about 50 lines of D) http://arsdnet.net/apidemo.d And the HTML templates it uses: http://arsdnet.net/apidemo-document.html http://arsdnet.net/apidemo-javascript.html The libraries it imports are available here http://arsdnet.net/dcode/

How is it working out with a static type system, compared to a dynamic, for web development?

How many times, while using a dynamically typed language, do you ever change the type of a variable? I've written a fair amount of PHP, and I rarely, if ever want my string to suddenly become an integer (if I do it generally needs validation/conversion anyway). When using my own and others code I frequently see type checks/conversions etc, it just makes the code ugly - with a staticly typed system you remove this overhead. Also, there's the auto keyword, and easily accessible function templates. -- Robert http://octarineparrot.com/
May 13 2011
parent "Nick Sabalausky" <a a.a> writes:
"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:iqjer9$1mai$1 digitalmars.com...
 On 13/05/2011 08:09, Jacob Carlborg wrote:
 How is it working out with a static type system, compared to a dynamic,
 for web development?

How many times, while using a dynamically typed language, do you ever change the type of a variable? I've written a fair amount of PHP, and I rarely, if ever want my string to suddenly become an integer (if I do it generally needs validation/conversion anyway). When using my own and others code I frequently see type checks/conversions etc, it just makes the code ugly - with a staticly typed system you remove this overhead. Also, there's the auto keyword, and easily accessible function templates.

And templates for when you want a function to accept multiple types, and Variant for the few times when changing a variable's type might actually be useful.
May 13 2011
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Jacob Carlborg wrote:
 How is it working out with a static type system, compared to a
 dynamic, for web development?

It's *much* better, especially for rapid development. The compiler will tell me if my changes anywhere break things anywhere else, so I can modify with confidence. I can't tell you how many times I've made a minor mistake in PHP, Ruby, or Visual Basic and had it slip through to production because the code path was obscure enough to evade testing. Sometimes, something similar does happen in D - to!int("") throws - but, the compiler catches the majority of incompatible changes instantly. If I had int addUser() and change it to User addUser(), I don't have to hunt every instance down myself. Just hit compile and the compiler tells me where the change causes problems. (Rarer than you might think - thanks to auto, a lot of the program is already duck typed in a way. The actual return value name is rarely used.) It also helps documentation to have good types. I often see stuff like this in dynamic language docs: function doSomething(options); What does it return? What options are available? Maybe the text will tell us that options is an associative array. UGH, I hate that! Now, there's even less knowing what's going on. D's documentation is a lot more helpful, and easier to keep up to date. string doSomething(Options options); // not much better yet.... struct Options; int speed; bool strictMode; bool caseSensitive; Ahhh, now I know! Another thing that the static types enable that I don't think is possible with dynamic functions is the automatic forms you see on my link. http://arsdnet.net/cgi-bin/apidemo/get-a-box I didn't write any html for that. The library made it for me. In the source, you can see it's prototype: http://arsdnet.net/apidemo.d Element getABox(Color color); The reflection was able to say "it needs a Color, and there's only a handful of valid Colors - enum Color - so I can automatically create a <select> box for this." Dynamic types for return values can still do most the stuff my api generator does. Whether it's a static function/template toHtml or a dynamic property doesn't matter much. But the parameters... I don't think it can be done without the static types there. (Another nice thing is the library checks the type too. Coming off the request parameters, you have strings; dynamic types. But going into the function, it knows it must be a Color, so it checks. If not, an exception is thrown. By the time you're inside the function, you can be guaranteed that Color color is indeed a Color. Thus, to!string() to insert it into the html attribute that I did here is perfectly safe. It's a whitelist based filter, all done automatically.) There are a few cases where dynamic types are helpful or needed. D lets us opt in to them with only a minimal amount of fuss. The places where I use it are: 1) Data from the user. Form variables are of type string coming into the program. Once decoded, you have string[][string]. Your program probably wants something else. The to!() template in Phobos makes this pretty easy, or if you want default value and get/post combined, my cgi class has a request template: int a = cgi.request!int("a"); That's similar to this in PHP: $a = 0; if(isset($_POST['a'])) $a = (int) $_POST['a']; else if(isset($_GET['a'])) $a = (int) $_GET['a']; PHP is so outrageously verbose. And the PHP is buggy compared to the D... if you do cgi.request!int("a", 10) and the user does a=txt, the PHP result is wrong. It's not quite fair to compare a function to a code collection though. A php function could do it right too. Annnnyway, I'm digressing. Hell, I'm going on about weak types instead of dynamic types! Even in Ruby, you'd have to do a to_i since the url value simply is a string. Back to dynamic types. The three other places where you see them are databases and interfacing with external services. 2) Databases With databases, you probably expect a certain type anyway. If the column is typed as INTEGER, you probably don't want 'lol' in there. But, the database takes care of that for you. In my libs, I just use strings. auto line = mysql.query("SELECT id FROM users WHERE id = 10").front; res[0] == "10" Conversions are now done the same as URL parameters: int id = to!int(res[0]); Oftentimes, I don't really care about it though; if I'm outputting it to html, I'll just say: table.appendRow(res["id"], res["name"]) and the like anyway. You want a string there, so it just works. (appendRow is in fact a variadic template so it'd just work regardless, but you get the idea anyway). Thanks to static checks though, if I were to later change my mind and wanted ints, or made the database return Variants or whatever, no problem - the compiler will point out trouble spots to me. Inserting data is the same: mysql.query("INSERT INTO users (id) VALUES (?)", 10); // works mysql.query("INSERT INTO users (id) VALUES (?)", cgi.post["id"]); // works too Or using the data object class: auto obj = new DataObject(mysql, "users"); obj.id = 10; // works obj.id = "10"; // works just as well obj.commitChanges(); (The DataObject can read too, offering database fields as obj.id style properties. They always return string, just like plain query, but are also read/write.) DataObject can also be specialized automatically to use static types if you like. db.sql: create table users(id integer primary key, name varchar(30)); file.d: // parse out that create table to map the names and types automatically alias DataObjectFromSqlCreateTable!(import("db.sql"), "users") User; User a; a.id = "12"; // type mismatch, fails to compile a.name = "hello"; // works a.nmae = "sad" // typo caught at compile time a.commitChanges(); // otherwise it is still based on DataObject In short, I have the best of both worlds, with the only extra effort being writing to!() here and there and that one line to import the sql definition. 3) HTML I *want* strict typing when working with html in almost all cases. It helps catch encoding bugs. The one place where I want dynamics - fetching an element off the html template - I have it, this time provided through classes. auto table = cast(Table) document.getElementById("data-table"); assert(table !is null); // fails if it isn't a <table> tag // use the table class's special functions Forms, Links, and other types of nodes are handled similarly. The Element base class though does most the simple operations. Being plain old inheritance, the virtual functions act dynamically enough. Of course, if the HTML changes, that assert/enforce will trigger at run time. We're still ahead of dynamic languages though: the compiler will tell me what breaks if I remove the cast, with one exception: I use an opDispatch there for attributes. That will break some functions. Table t = ...; t.caption = "Hello!"; // changes the <caption> tag child Element t = ...; t.caption = "Hello!"; // sets a caption="" attribute But meh, in this case, I like the flexibility of accessing attributes like that. The compiler still catches more than it doesn't - we're still ahead of the mistakes possible in dynamic languages while keeping the convenience. 4) External services This is where dynamic types are the most useful. Accessing Facebook, Twitter, etc., returns xml or json with types that change based on a lot of things. Is the user logged in? What url is it? In this case, it's like the database, but the types tend to be more complex. Simple string cowboying won't cut it. Thankfully, D's Variant is up to the task. Variant userRet = fbGraph(token, "/me"); // we know /me returns a json object from the docs, so fetch it: auto user = userRet.get(Variant[string]); auto name = user["name"].get!string; // name is a string == "Adam D. Ruppe" Not terribly hard. Robert Jacques IIRC has written an improved std.json patch to make this work almost just like Javascript: auto user = fbGraph(token, "/me"); user.name.get!string; // same as above So D's definitely up to the job. The only difference is that final use of get!string. I believe Phobos' to! works as well. In the end, there's nothing web related in my experience that a dynamic language can do that D can't do almost or just as well, and plenty that D and it's static types can do that dynamic types can't do, or require piles of painful tests and manually written code or documentation to do. D kicks the Web's ass. (And my web related libraries go even further than seen here. My custom DOM offers a lot of things that are way cool, enabling new CSS stuff, filling forms easily, in about 1/10 the code of doing it similarly in PHP, and without mucking up the HTML. The web api/site generator makes D accessible through urls, forms, javascript - view the source here for a glimpse of that lib: http://arsdnet.net/cgi-bin/apidemo/javascript 20 kb of javascript, including the auto generated API bindings! And more stuff is packed in there too. Best of all: D, through CGI, consistently does well or better than mod_php in my speed benchmarks. I've barely tried to optimize too; there's a lot of untapped potential. If your host doesn't suck, dive into D on the web. You won't want to go back.)
May 13 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:iqji6m$1se1$1 digitalmars.com...
 Jacob Carlborg wrote:
 How is it working out with a static type system, compared to a
 dynamic, for web development?

It's *much* better, especially for rapid development. The compiler will tell me if my changes anywhere break things anywhere else, so I can modify with confidence. I can't tell you how many times I've made a minor mistake in PHP, Ruby, or Visual Basic and had it slip through to production because the code path was obscure enough to evade testing.

Yea, it all just comes from dynamic being sloppy and overly-permissive. Before I switched my web development to Haxe (not remotely as good as D, but it beats the hell out of straight PHP/ActionScript), I had to do some stuff in ActionScript2. Anytime anything would go wrong (other than a syntax error), the compiler would accept it, and the *runtime* would accept it and just simply ignore it and move on. Not even an exception or log notice or anything. That alone turned development into an absolute nightmare. Nothing ever worked, you never had the slightest clue why, and it took forever to track the problem down to something that, invariably, would turn out to be something D would have caught immediately, usually at compile-time. And that was all in the name of being "forgiving". Blech. Bottom line, whether dynamically-typing or anything else: being overly-permissive sucks. What D permits you to do is tighten the damn leash.
 The to!() template in Phobos makes this pretty easy, or if you
 want default value and get/post combined, my cgi class has a request
 template:

to!() is absolutely awesome. OTOH, thanks to to!(), the conversion functions in every other language out there seem irritatingly poorly designed. ;) Anytime I have to do a conversion in Haxe, I always end up needing to reach for the std API reference. And even Haxe's API for conversions is pretty good compared to some other langauges.
 int a = cgi.request!int("a");

 That's similar to this in PHP:

 $a = 0;
 if(isset($_POST['a']))
  $a = (int) $_POST['a'];
 else
 if(isset($_GET['a']))
  $a = (int) $_GET['a'];


 PHP is so outrageously verbose. And the PHP is buggy compared to
 the D... if you do cgi.request!int("a", 10) and the user does a=txt,
 the PHP result is wrong. It's not quite fair to compare a function
 to a code collection though. A php function could do it right too.

Be glad it's not VB6, or worse, VBScript. I've had to do a lot of web dev in those languages in the past, and as horrible as PHP is overall, for outright verbosity it doesn't even compare to VB6/VBScript. auto myVar = "foo"; $myVar = "foo"; vs: Dim myVar As String myVar = "foo" Seriously?! And don't get me started on VB's million-and-one different things you have to check for to see whether or not a string actually contains anything. And then there's its arrays, which wouldn't be *too* bad if they didn't allow the staring index to be chosen completely at random. So, wanna find the length of an array? In D it's: myArray.length In PHP it's probably about the same as D. In VBScript, if you want to do it correctly, it's: (UBound(myArray) - LBound(myArray))+1 Or you can do UBound(myArray)+1 and just pray that some stupid jackass doesn't actually try to use the "choose your array's lower bound", ahem, "feature". I can just feel my sanity fading...
 auto table = cast(Table) document.getElementById("data-table");
 assert(table !is null); // fails if it isn't a <table> tag

 // use the table class's special functions


 Forms, Links, and other types of nodes are handled similarly. The
 Element base class though does most the simple operations. Being
 plain old inheritance, the virtual functions act dynamically
 enough.

You know, I used to absolutely love doing the rails-like thing of using HTML templates. And Terence Parr's StringTemplate even managed to convince me for awhile that such templates shouldn't have imperative logic. But the more I watch your DOM approach and then continue using HTML templates (very mercifully, one that thankfully *does* allow imperative logic), the more fed up I'm starting to get with the template approach. Granted, I haven't used it yet, but I think you've got the right approach with your DOM stuff.
 And more stuff is packed in there too. Best of all: D, through
 CGI, consistently does well or better than mod_php in my speed
 benchmarks. I've barely tried to optimize too; there's a lot of
 untapped potential.

One of the things I've noticed never even seems to get mentioned is that even though CGI has had a stigma of high startup costs, *MANY* php installations, even on commercial shared hosting, have php set up to run as CGI. So even if php interpretation wasn't much slower than good compiled code, it *still* wouldn't usually have the speed advantage people have attributed to it.
 If your host doesn't suck, dive into D on the web. You won't want
 to go back.)

Won't want to go back to dynamic web scripting? Hell, I haven't even done any D CGI beyond a trivial hello world (for which I had to jump through *enormous* hoops to get working with my damn shared web hosts - and one of them, turns out, won't even support compiled CGI at all), and yet, I just plain don't want to *remain* with dynamic web scripting. :) Another thing, too, that's really good about D being faster is that you can do a lot more before Apache/PHP/whatever decides to kill you off for taking too long. And you can realistically try to anticipate it, finish up any atomic operations, and die gracefully instead of risking corruption from broken atomicity. That's getting to be a problem in my Haxe/PHP stuff. I have my code set up so that when there's an unhandled exception, it automatically tries to log it to three separate places: a logfile, the DB, and email. (And if any one of those fails, it still attempts the others and then tries to notify the others that the one failed. I'm really proud of the whole system :)) And, of course, a stack trace is included. But the problem is, this all takes (noticable) time, especially on PHP, so I risk loosing all the info that anything even went wrong at all just because the server killed it off for taking too long. And that's actually happened a few times on my local dev system (I *hope* it hasn't happened on the server...) Heck, I can usually tell when it's crashed even before I get the error page just because it'll take noticably longer than usual. But what makes all that really bad is there seems to be a bug in either Haxe or PHP that causes stack traces to include *all* the functions called...ie, even the ones that have returned, instead of just the current call stack. So the *ahem* "call stack" ends up huge (and hard to use). And there's two things that make it far bigger than it even needs to be: 1. There's a big data structure I sometimes need (data that doesn't actually change - so it's converted automatically at build-time from a raw datafile to a direct hard-coded Haxe source file). But Haxe, and presumably PHP, doesn't allow compex literals. And even if it did, there's no such thing as pre-compiled PHP, so there's no such thing as a statically-initialized data segment. So the generated Haxe code has to actually build up the data structure at runtime. And the structure is somewhat large...and there's a limit on function size (don't recall if it's a Haxe or PHP limit)...so each piece of the data-building has to be put into it's own function. And there's currently hundreds of these little functions. So that makes the "broken stack trace" that much bigger and slower to build. 2. Haxe has runtime reflection, which is needed for it's, rather good, object database API. But the reflection works by keeping the info stored as...get this...XML...and then the XML is parsed to retrieve the actual data. Which is incredibly stupid, of course, but that's how it's done. And, of course, there's recursion involved in that XML parsing, so that bloats the big slow broken stack trace even more. Although, all that reminds me, servers (especially shared hosts) can also have memory limits on scripts and CGI. But D's GC likes to just keep grabbing system RAM and only release back to the OS when really necessary, or when you tell it to. And even that can be blocked by false pointers. Have you had any problems with server memory caps and D's memory behavior?
May 13 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:
 Be glad it's not VB6, or worse, VBScript.

Oh, I know it! One of my side jobs I picked up this year is maintaining somd old VBS program, using classic ASP. There's so much nonsense. It doesn't help that the original author was horribly incompetent - he never used functions/subs, just copy and pasted everything. Over and over and over again. (And to make it worse, the authors apparently didn't know HTML. Not a single standard link or form. *everything* is done as javascript or client side vbscript - mixed at random - calls in href attrs.) My biggest problem when writing code for them though is that I instinctively put semicolons at the end of thoughts....
 CGI has had a stigma of high startup costs

I'm now convinced almost all of CGI's bad reputation is actually Perl's problems that got misattributed. Starting a process is quite fast. Starting a process, reading a script, compiling it, and interpreting it... that's kinda slow. Moreover, Linux used to be slower at forking new processes than it is today, so improvements to the kernel help today too. While my own benchmarks have shown a difference between mod_php and cgi hello world.... those differences disappear once you start using it on a real network. The slowdown of cgi is nothing next to even a fast network ping. Now, none of the sites I've worked on have had millions of users. Maybe the tiny difference adds up. I doubt it, but I can't prove it. But, let's face it. Virtually none of us have millions of users anyway. And if I did, I'm sure I can spare a few days to profile and fix the problem (either moving to persistent processes, or profiling Apache or whatever) in between my cash showers and golden baths. There's nothing inheriently slow about a D web site - quite the opposite, actually.
 Have you had any problems with server memory caps and D's memory
 behavior?

No, but at the same time, I don't process huge datasets yet abd run most everything on servers I have root on. (there is a portion that runs on a shared host and my D does work there, it has very light duties so I don't know what would happen if it hit the limit.) CGI programs tend to be fairly short lived though, so the GC might not be necessary at all. Once the request is complete, the process terminates, releasing everything at once.
May 13 2011
parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:iqkbm3$8gc$1 digitalmars.com...
 Nick Sabalausky wrote:
 Be glad it's not VB6, or worse, VBScript.

Oh, I know it! One of my side jobs I picked up this year is maintaining somd old VBS program, using classic ASP. There's so much nonsense. It doesn't help that the original author was horribly incompetent - he never used functions/subs, just copy and pasted everything. Over and over and over again. (And to make it worse, the authors apparently didn't know HTML. Not a single standard link or form. *everything* is done as javascript or client side vbscript - mixed at random - calls in href attrs.)

Ouch. I've been to sites that couldn't figure out how to make a link without JS. It gives you the same sort of feeling as watching a perfectly healthy grown adult be unable to...I dunno, insert anything blatantly obvious that most toddlers have mastered here. ;)
 My biggest problem when writing code for them though is that I
 instinctively put semicolons at the end of thoughts....

Heh, I have the exact same problem anytime I use a no-semicolon language. :)
 CGI has had a stigma of high startup costs

I'm now convinced almost all of CGI's bad reputation is actually Perl's problems that got misattributed.

Yea, I don't that. Especially since I've started noticing at least one shared web host that took "CGI" to mean "Perl and Python".
May 14 2011
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
 I haven't used it yet, but I think you've got the right approach
 with your DOM stuff.

For people who haven't read about this, I just wrote up a quick document about it: http://arsdnet.net/web.d/dom.html I really rambled at points, but I wanted to cover all the bases.
May 13 2011
next sibling parent reply albatroz <rmcjustino gmail.com> writes:
This should be also be posted on the Announce list!

I'm considering D for web develoment and your libs provide a nice solution, 
the only issue is until now we would have to dig on this NewsGroup for your 
posts (the big ones), so that we could have an ideia how to use them. 

I would also like to suggest to you if possible, start hosting your scripts 
using a VCS, would be nice to spot your updates and changes.

Any way thank you for sharing your amazing work.

Adam D.  Ruppe wrote:
 For people who haven't read about this, I just wrote up a quick
 document about it:
 
 http://arsdnet.net/web.d/dom.html
 
 I really rambled at points, but I wanted to cover all the bases.

May 14 2011
parent Adam Ruppe <destructionator gmail.com> writes:
Yea, I'm going to start storing or at least linking some of my writings
in that new web.d directory so it will be easier to find.

For a version control system though, blargh, it always feels like
extra work to me. I very rarely use them at all. Most my basic libs
though are pretty stable now. cgi.d and dom.d are both in good shape.
(cgi.d did recently get new cache control functions. I discussed that
in a forum post here: http://www.sveit.com/forum/viewtopic.php?f=25&t=3407

But, the core of it, is pretty much done to me.)

The actual web.d file though - the site/api generator - has been getting
a lot of changes these last couple weeks. It's in a state of rapid
change now since I've started using it on some more projects.


Once that part is solid, I'll write about it in that new folder and
post some links to the announce group.
May 14 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-14 04:17, Adam D. Ruppe wrote:
 I haven't used it yet, but I think you've got the right approach
 with your DOM stuff.

For people who haven't read about this, I just wrote up a quick document about it: http://arsdnet.net/web.d/dom.html I really rambled at points, but I wanted to cover all the bases.

I can agree with some of this but not all of it. I quite like Rails' Model-View-Controller pattern which allows the view layer to contain logic but which you should try to avoid as much as possible. I guess this fall under "PHP (Disciplined)". I don't see anything wrong with the view layer containing simple logic, like this (written in HAML): %ul - posts.each do |post| %li= post.title Or, if you prefer, you can a partial: posts.html.haml: %ul = render posts _post.html.haml: %li= post.title -- /Jacob Carlborg
May 15 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Jacob Carlborg wrote:
 I don't see anything wrong with the view layer containing simple
 logic, like this (written in HAML):

I don't think it's bad - I just think it isn't as good as we can get.
May 15 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-15 17:46, Adam D. Ruppe wrote:
 Jacob Carlborg wrote:
 I don't see anything wrong with the view layer containing simple
 logic, like this (written in HAML):

I don't think it's bad - I just think it isn't as good as we can get.

Correct me if I'm wrong but you don't like to have logic in the view layer. Instead you move the view layer into the model or controller layer. How's that any different? -- /Jacob Carlborg
May 16 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
 Instead you move the view layer into the model or controller
 layer. How's that any different?

Is that really what's happening? Any template has variables made available to it from the model. I'm just making them available at a higher level (pre-wrapped in semantic tags and grouped together). The actual layout and styling, sometimes even data formatting - the stuff I think of as the view - is still done entirely in the separate html and css files. I realize this isn't a perfect argument, but it's still worth it to me to have those other processing options available.
May 16 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-16 15:43, Adam D. Ruppe wrote:
 Instead you move the view layer into the model or controller
 layer. How's that any different?

Is that really what's happening? Any template has variables made available to it from the model. I'm just making them available at a higher level (pre-wrapped in semantic tags and grouped together). The actual layout and styling, sometimes even data formatting - the stuff I think of as the view - is still done entirely in the separate html and css files. I realize this isn't a perfect argument, but it's still worth it to me to have those other processing options available.

I got the impression that you basically did all HTML with D methods, maybe I don't understand your work flow. -- /Jacob Carlborg
May 16 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:iqt6kb$1nd1$1 digitalmars.com...
 On 2011-05-16 15:43, Adam D. Ruppe wrote:
 Instead you move the view layer into the model or controller
 layer. How's that any different?

Is that really what's happening? Any template has variables made available to it from the model. I'm just making them available at a higher level (pre-wrapped in semantic tags and grouped together). The actual layout and styling, sometimes even data formatting - the stuff I think of as the view - is still done entirely in the separate html and css files. I realize this isn't a perfect argument, but it's still worth it to me to have those other processing options available.

I got the impression that you basically did all HTML with D methods, maybe I don't understand your work flow.

AIUI: 1. It starts out as ordinary HTML with no special non-standard tags or anything. But it might use id and class attributes to mean certain things. 2. In D, that HTML is loaded and parsed into an HTML DOM. 3. In D, the data is filled into the HTML DOM. Sometimes this might involve a amall amount of adding HTML tags/attributes or other weird tweaking if necessary. 4. The new HTML DOM is written out as straight HTML. Basically just like DHTML, except on the server and using D.
May 17 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:iqtarl$229l$1 digitalmars.com...
 "Jacob Carlborg" <doob me.com> wrote in message 
 news:iqt6kb$1nd1$1 digitalmars.com...
 On 2011-05-16 15:43, Adam D. Ruppe wrote:
 Instead you move the view layer into the model or controller
 layer. How's that any different?

Is that really what's happening? Any template has variables made available to it from the model. I'm just making them available at a higher level (pre-wrapped in semantic tags and grouped together). The actual layout and styling, sometimes even data formatting - the stuff I think of as the view - is still done entirely in the separate html and css files. I realize this isn't a perfect argument, but it's still worth it to me to have those other processing options available.

I got the impression that you basically did all HTML with D methods, maybe I don't understand your work flow.

AIUI: 1. It starts out as ordinary HTML with no special non-standard tags or anything. But it might use id and class attributes to mean certain things. 2. In D, that HTML is loaded and parsed into an HTML DOM. 3. In D, the data is filled into the HTML DOM. Sometimes this might involve a amall amount of adding HTML tags/attributes or other weird tweaking if necessary. 4. The new HTML DOM is written out as straight HTML. Basically just like DHTML, except on the server and using D.

And AIUI, it can also be thought of as being like an HTML templating engine, except instead of working with proprietary tags and text subsitution, it works with id/class attributes and an enhanced HTML DOM.
May 17 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-17 10:16, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:iqtarl$229l$1 digitalmars.com...
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:iqt6kb$1nd1$1 digitalmars.com...
 On 2011-05-16 15:43, Adam D. Ruppe wrote:
 Instead you move the view layer into the model or controller
 layer. How's that any different?

Is that really what's happening? Any template has variables made available to it from the model. I'm just making them available at a higher level (pre-wrapped in semantic tags and grouped together). The actual layout and styling, sometimes even data formatting - the stuff I think of as the view - is still done entirely in the separate html and css files. I realize this isn't a perfect argument, but it's still worth it to me to have those other processing options available.

I got the impression that you basically did all HTML with D methods, maybe I don't understand your work flow.

AIUI: 1. It starts out as ordinary HTML with no special non-standard tags or anything. But it might use id and class attributes to mean certain things. 2. In D, that HTML is loaded and parsed into an HTML DOM. 3. In D, the data is filled into the HTML DOM. Sometimes this might involve a amall amount of adding HTML tags/attributes or other weird tweaking if necessary. 4. The new HTML DOM is written out as straight HTML. Basically just like DHTML, except on the server and using D.

And AIUI, it can also be thought of as being like an HTML templating engine, except instead of working with proprietary tags and text subsitution, it works with id/class attributes and an enhanced HTML DOM.

That would require a lot of otherwise (possibly) unnecessary id/class attributes (if they aren't removed). If you're not careful with your CSS you can accidentally style tags. -- /Jacob Carlborg
May 17 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Jacob Carlborg wrote:
 That would require a lot of otherwise (possibly) unnecessary
 id/class attributes (if they aren't removed).

Not that much in the sites I've done. Here's another real example, that new d web site discussed on the newsgroup a while ago: Dynamic page: http://arsdnet.net/d-web-site/ The HTML template it manipulates with DOM: http://arsdnet.net/d-web-site/index.html There's only three dynamic elements on that page, so the template is almost identical to the finished page. There's three placeholders getting filled in: <div id="announcements" /> <div id="commits" /> and <form id="code-runner"> And the relevant code: form: auto f = cast(Form) document.getElementById("code-runner"); f.setValue("code", `void main() { assert(0, "Hello, world!"); }`); It fills the form, without caring about how the form is written. This does name="code" and sets value to that string given. It doesn't care how the HTML is written - here, it's a <textarea>, but this code remains the same if it's an <input> or <select>. The view controls how the data is presented, the dom just tells it what to present. Announcements and commits are done with more dom calls, but still, not much. void addAnnouncements(Element holder) { auto document = holder.parentDocument; foreach(announcement; getAnnouncements()) { auto h = holder.addChild("div"); auto date = std.date.parse(announcement.date); h.addChild("span", formatDate(date)); h.appendText(" - "); h.appendChild(new Link(announcement.url, announcement.subject)); } } Commits is a little longer since it has more data, but same idea. Arguably, this crosses the line into presentation, especially with that appendText call. (I guess it could do an #announcements > span:after in css, but that's not reliable) But, you can see that the vast majority of html is far away from here. The #announcements id used to fill it in is also used to style the inside: #announcements > div { style each announcement } #announcements > div > span { style the date } #announcements > div > a { style the link } (man, css nesting is such a good thing to have!) Side note: obviously, you don't *have* to do web apps my way, even with my libraries. cgi.d is template-agnostic. dom.d isn't going to kill you if you ask it to add logic to templates or do string replacement instead. My way is just one possibility of many.
May 17 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:iqua65$rm2$1 digitalmars.com...
  auto f = cast(Form) document.getElementById("code-runner");
  f.setValue("code", `void main() { assert(0, "Hello, world!"); }`);

Minor suggestion: There should be an overload of getElementById that's defined like this: T getElementById(T)(string str) if(is(T:WhateverYourBaseNodeTypeIs)) { auto node = cast(T) getElementById(str); if(node) return node; else throw new ElementNotFoundException(T.stringof, str); } class ElementNotFoundException : Exception { this(string type, string str) { super("Element of type '"~type~"' matching '"~str~"' not found."); } } That way if it's missing, you get an accurate message instead of an awful null pointer exception. Or maybe call it requireElementById. Or, of course, if it's in a class and can't have templated members (I really hate that limitation. Templated class members would be so much more useful than being able to ship .obj's and .lib's without the original source), then: T getElementById(T)(WhateverYourBaseNodeTypeIs root, string str) if(is(T:WhateverYourBaseNodeTypeIs)) { ... } And, of course, just use the original getElementById if you want to allow the element to be optional. Another separate thought: What happens if you want to (or try to) put the same data in more than one place? Maybe there should be a way to detect and error if there's more than one of the same thing. Or maybe better yet, getElementById could return a special collection that contains all matching elements. And it could expose the same interface as a single element, but automatically applies it to all matched elements. Of course, you couldn't use "id=" for that since that's really not supposed to have duplicates. So you'd have to use "class=" instead. Which opens the possibility, if you're not doing this already, for the HTML importing (and maybe the DOM, too, or at least serializing the DOM at the end) to detect and error on multiple instances of the same "id=".
May 17 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:
 There should be an overload of getElementById that's defined like
 this:

Aye, I've been thinking about that for a while, but could never think of a name I like (yeah, petty reason). I've just trained myself to use assert to avoid the null pointers.
 Or maybe call it requireElementById.

That's a pretty good idea.
 Or, of course, if it's in a class and can't have templated members

It is a class, but the requireElementById (and it's counterpart, requireSelector*) could always be final. I can't think of a reason to override them anyway, especially since the underlying implementation in getElementById is still overridable anyway. (same reason why I'm ok with opDispatch - it just forwards to set/getAttribute) This is definitely good though, it has the best cost/benefit ratio of things on the todo list. I take your name! side note:: * After looking at haml yesterday, I'm tempted to do a nothrow requireSelector. Again, can't think of a name. But what it'd do is try to get the first element that matches the css syntax. If it's not there, it starts from the best path that does exist and creates the rest. So if you have a blank element <html></html> and you do: makeSelector("html"); // that root node is returned since it exists makeSelector("div > span.date"); That doesn't exist, so it does a return document.root.addChild("div").addChild("span").className("date"); Though, I don't think I have a use for it; it'd be harder to use than just writing the html yourself in the template file. :: end side note
 What happens if you want to (or try to) put the same data in more
 than one place?

Use a class or a custom attribute instead of id, then loop through the collection: foreach(e; document.getElementsBySelector("div.announcements")) addAnnouncements(e); Sometimes I do that even when there's just one because the return value there is guaranteed to never include null.
 Which opens the possibility, if you're not doing this already, for
 the HTML importing (and maybe the DOM, too, or at least
 serializing the DOM at the end) to detect and error on multiple
 instances of the same "id=".

No, it doesn't check that right now. It treats id as just another attribute for the most part. (getElementById returns the first one it sees in the tree.) It always could, but I haven't felt it's worth the time yet.
May 17 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-05-17 22:12, Adam D. Ruppe wrote:
 side note::

 * After looking at haml yesterday, I'm tempted to do a nothrow
 requireSelector. Again, can't think of a name.

 But what it'd do is try to get the first element that matches the
 css syntax. If it's not there, it starts from the best path that
 does exist and creates the rest.

 So if you have a blank element<html></html>  and you do:

 makeSelector("html"); // that root node is returned since it exists

 makeSelector("div>  span.date");

 That doesn't exist, so it does a

 return document.root.addChild("div").addChild("span").className("date");


 Though, I don't think I have a use for it; it'd be harder to use
 than just writing the html yourself in the template file.

 :: end side note

Sounds more like jQuery than HAML. -- /Jacob Carlborg
May 17 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-05-17 10:11, Nick Sabalausky wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:iqt6kb$1nd1$1 digitalmars.com...
 On 2011-05-16 15:43, Adam D. Ruppe wrote:
 Instead you move the view layer into the model or controller
 layer. How's that any different?

Is that really what's happening? Any template has variables made available to it from the model. I'm just making them available at a higher level (pre-wrapped in semantic tags and grouped together). The actual layout and styling, sometimes even data formatting - the stuff I think of as the view - is still done entirely in the separate html and css files. I realize this isn't a perfect argument, but it's still worth it to me to have those other processing options available.

I got the impression that you basically did all HTML with D methods, maybe I don't understand your work flow.

AIUI: 1. It starts out as ordinary HTML with no special non-standard tags or anything. But it might use id and class attributes to mean certain things. 2. In D, that HTML is loaded and parsed into an HTML DOM. 3. In D, the data is filled into the HTML DOM. Sometimes this might involve a amall amount of adding HTML tags/attributes or other weird tweaking if necessary. 4. The new HTML DOM is written out as straight HTML. Basically just like DHTML, except on the server and using D.

Ok I see. -- /Jacob Carlborg
May 17 2011
prev sibling next sibling parent reply Alexander <aldem+dmars nk7.net> writes:
On 13.05.2011 17:19, Adam D. Ruppe wrote:

 It's *much* better, especially for rapid development. The compiler
 will tell me if my changes anywhere break things anywhere else,
 so I can modify with confidence.

Sure, there are many pros. And one significant drawback - it couldn't be easily embedded into HTML code. Either, you have to generate all your pages from inside of CGI script, or use templates - but the main advantage of PHP is that you can mix it with page text. Unfortunately, this is not really possible with D (or C, or C++ etc) - because the code needs to be compiled first, and that could be difficult to do if it is embedded into the page. /Alexander
May 14 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Alexander wrote:
  Sure, there are many pros. And one significant drawback - it
  couldn't be easily embedded into HTML code.

Two notes: 1) actually, you can. 2) You don't want to. 1) I wrote a little program called dhp.d - write D in a PHP style. http://arsdnet.net/dhp.d About 100 lines of D - not exactly a fancy program - but it shows a way you could do it. Use dhp as an interpreter for your "script". You write html here <?d // D code here ?> // back to html When dhp is run, it compiles the file on the fly. (This implementation doesn't cache, but it could and should) Then, it passes control to the newly compiled file, which runs and outputs your stuff. Literal html outside the <?d ?> tags is passed through just like php. This is implemented by putting quotes around it and cgi.writting it in the generated code. 2) While you could do it, you shouldn't do it. This is bad form even in PHP. See part of my DOM template writeup for a brief on why: http://arsdnet.net/web.d/dom.html Basically, it gets ugly, fast.
May 14 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 14.05.2011 17:13, Adam Ruppe wrote:

 1) I wrote a little program called dhp.d - write D in a PHP style.

Not really a solution. It doesn't work like PHP/ASP do - the result cannot communicate with other pages even if you implement the caching. Basically, you have to implement the whole framework around this, and somehow find a way to share the data etc - which is not so trivial in D right now.
 2) While you could do it, you shouldn't do it. This is bad form even
 in PHP. See part of my DOM template writeup for a brief on why:
 http://arsdnet.net/web.d/dom.html

Sorry, not very convincing. There are many people and many solutions, your is not universal, unfortunately. When I say "not universal" - I mean simply "not everyone will like and use it" (I don't like DOM and XML, for instance - so I try to avoid them as much as possible). Different developers do things in different way, that's why embedding code in web-pages (PHP/ASP way) is (for some people and/or applications, at least) is more preferred or productive.
 Basically, it gets ugly, fast.

Depends on how you do this ;) /Alexander
May 14 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
   Not really a solution. It doesn't work like PHP/ASP do - the result
 cannot communicate with other pages even if you implement the caching.

Can you show me a PHP example showing what you mean? I can't think of anything you can do in PHP that D can't do at least as well. If by communicating with other pages you mean something like php's include(), that's trivial (just include the file here too!)
May 14 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 14.05.2011 23:20, Adam Ruppe wrote:

 Can you show me a PHP example showing what you mean? I can't think
 of anything you can do in PHP that D can't do at least as well.

Something like this: http://core.trac.wordpress.org/browser/trunk/wp-content/themes/twentyten/header.php
 If by communicating with other pages you mean something like php's include(),
that's trivial (just include the file here too!)

No, I mean state/data exchange. Say, somewhere on the page you set a variable, and it's values is visible on all other pages. /Alexander
May 15 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Alexander wrote:
  Say, somewhere on the page you set a variable, and it's values is
 visible on all other pages.

My simple implementation does that. The way it works is say you have this file: === <?d auto title = "hello"; ?> <title><?= title ?></title> === It scans through and turns the stuff outside <??> into string literals and wraps the whole thing in a main function. So that becomes: /* snip imports */ void main() { auto title = "hello"; write("<title>"); write(title); write ("</title>"); } When it runs, you get the result you expect coming from PHP. Thank's to D's nested functions, classes, etc., you can do just about anything with the language, despite it all being inside one big main function once generated. In PHP, pages share data by having one include the other. Even Wordpress templates ultimately work that way - the main code includes the template's code after defining a bunch of functions and variables. If you did the same here, the variables from before would be visible in your scope. auto title = "hello"; write("<title>"); write(title); write ("</title>"); // include a similar file that says <?= replace(title, "h", "H"); ?> write(replace(title, "h", "H"); And it'd work - the title variable hasn't disappeared. There is one thing Wordpress does that would *not* work here though: including a file based on a dynamic variable. include("file.dph"); // works fine - the string can be pulled out // by the preprocessor and compiled include(file-from-user); // wouldn't work You could make it work by providing a pool of available files though, then picking one of them from the list. I only wrote that little program as a toy a while ago. Someone on the newsgroup said it was impossible... I rather like showing the possible in D instead, even if I find it useless. But since I do find it pretty useless, I never finished it. Still, even in it's unfinished state, most of this works already. Sharing data is easy.
May 15 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 17:04, Adam D. Ruppe wrote:

 In PHP, pages share data by having one include the other. Even
 Wordpress templates ultimately work that way - the main code
 includes the template's code after defining a bunch of functions
 and variables.

This is not what I mean. What I mean is something like: page-a.html: <?d var = "value" ?> page-b.html: <?= var ?> And this I expect to work. Just an example of what I mean, of course. I.e., *all* pages share the same namespace, and all values stored on one page are accessible on all other pages *and* persistent. Sure, we can use database or shared memory to implement persistence - but this will be way too slower comparing to some in-memory state, not talking about complex objects which cannot be stored (easily) in the database. To implement this, you would need a "bit" more than your dhp does (while PHP and ASP provide out of the box). /Alexander
May 15 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Alexander wrote:
 page-a.html:
 <?d var = "value" ?>
 page-b.html:
 <?= var ?>

 And this I expect to work.

That doesn't work in PHP nor ASP. In them, you *must* have page-a include page-b, or a parent page include both, unless you are populating the var from the session (see below). Try it. It's identical to dhp's preprocessor approach.
 *and* persistent.

That never works in PHP nor ASP, not even with php's register_globals. You have to use an explicit session to keep variables around between calls. Note that PHP's register_globals, if you're actually using it, is a huge huge mistake that they've deprecated in new versions.
May 15 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 18:17, Adam D. Ruppe wrote:

 That doesn't work in PHP nor ASP. In them, you *must* have page-a
 include page-b, or a parent page include both, unless you are
 populating the var from the session (see below).

Don't take my example literally, please - I just wanted to point that there is some globally visible storage accessible to all pages, be it session or something else, but which exists while the server is running and is very fast (i.e. not in DB).
 That never works in PHP nor ASP, not even with php's
 register_globals. You have to use an explicit session to keep
 variables around between calls.

Again - session data s something that is transparently (more or less) accessible to all pages. dhp doesn't do this, as far as I can see. If application is a set of pages, there should be a way to share data between pages without using complicated or expensive persistent storage. /Alexander
May 15 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Alexander wrote:
 If application is a set of pages, there should be a way to share
 data between pages without using complicated or expensive
 persistent storage.

FYI, PHP uses files on the hard drive for sessions by default... optionally, it can use a database too. AFAIK, there is no in-memory option beyond the options the kernel or database provide for file/table caching.
 Again - session data s something that is transparently (more or
 less) accessible to all pages. dhp doesn't do this, as far as I can
 see.

Nope, it'd be provided by an external library. Like I said in another sub-thread, I thought about cloning PHP's approach for a while. (There's a small amount of code to this end still commented out in my cgi.d and phphelpers.d modules) But, I never finished it, because I use sessions so rarely. Most usages of it don't match well with the web's stateless design - if someone opens a link on your site in a new window, can be browse both windows independently? Changing one *usually* shouldn't change the other. The two exceptions are logging in, which barely requires session data at all - matching session id and other identifiers to user id is all that's really necessary. Another big exception is something like a shopping cart. In cases like that, I prefer to use the database to store the cart anyway. So I've had no need for a fancy session system, and thus, never finished mine. It provides some session ID functions, but lets you do whatever you want with it beyond that. I can use them to store temporary files, as keys into the database, whatever. (BTW, PHP's automatic session handling *only* uses the session id. This leaves it open to trivial session hijacking. In web.d, the session functions automatically check IP address and user agent as well as cookies. It can still be hijacked in some places, but it's a little harder. To prevent hijacking in all situations, https is a required part of the solution, and the cgi library can't force that unilaterally. Well, maybe it could, but it'd suck.) I have considered adding a library for some persistent stuff though. One example is a service that pushes updates to clients. (The client uses ajax long polling or something similar to work around the limitations of the web environment.) I've written two programs in D that work like this - a real time web chat server and the more generic (and incomplete) D Windowing System's ajax bridge. But neither one simply broadcasts messages to waiting http clients. This would be useful for doing updates like Facebook. If someone posts a new wall post, it shows up on everyone's browser, pretty quickly. The usage code would look like this: broadcaster.push(channelId, message); The waiting clients run javascript that looks like so: var listener = new Listener("channelId"); listener.messageReceived = function(message) { ... }; Very simple. Maybe I'll write that today. There's two other things a longer running process is good for: 1) Session storage (see, on topic!). You speak a protocol to it... it's basically a reinvention of a database engine using memory tables. Might as well just use a real database engine with in-memory tables, or temporary files, relying on the kernel to keep them in memory. I'm in no rush to write this, since there's little need and existing stuff does it well when you do want it. If you have complex objects, you might want to keep them in memory. In that case, you can just use an embedded http server instead of cgi. My cgi class lets you do this without changing the bulk of your client code, and I've written an embedded http server in D to go with it. 2) Doing work that takes a long time or needs to be scheduled. There's three approaches to this, all of which work today: a) fork() your process, letting the child do the work while the main cgi program finishes. This is very convenient to program: // prepare stuff runInBackground( { // write code here to run, using variables prepared above }); // terminate, not worrying about the background process. It will // live on without you. The downside is I *believe* it doesn't scale to massiveness. Then again, most our sites aren't massive anyway, so does it matter? Also, I'm not sure if it scales or not, since I haven't tried. The most I've actually done using it for real was about 20 concurrent users. It did fine there, but everything does fine for small n. Another downside is communicating with it is hard. Could be solved by adding some message passing functions to the library, or combining it with the persistent notifier service described above. You would have to store it's process ID or the name of a pipe to talk to it though. Also, remember if it is doing work, you don't want to talk to it again. A cross-process lock is probably desired. Such is not handled automatically either. Finally, long running processes can't be updated. You have to kill them and restart, but if their state is only in memory, this means you lose data. Still, it is quite convenient! b) The way most PHP sites do things is to write out work to do later to the database, then depend on a cron job to check it and execute the stored commands. While it still takes care to ensure things are locked, communication is a little easier - instead of talking to the process, you poll the work list in the database. It could also use the persistent notification service. The cron job may be triggered by a lot of things. Page views (ugh), including automatic refreshes (double ugh), a real cron daemon, or user action, such as hitting ok on a schedule screen then doing it in the foreground, or a desktop application. One of my work projects went with the latter. The server cron app was moved to the user's desktops. Thanks to it all being written in a real programming language like D, reusing the code from the server app in a compiled GUI application was no trouble. I imported the same modules and compiled them for distribution. The users didn't have to install an interpreter or an httpd. 3) Use a persistent process in the first place, and run long work in a background thread, or even a foreground thread that isn't killed off by timeouts or disconnections. An embedded http server and std.concurrency can help with this. While all of these are possible, I usually stick with the traditional cron approach. It's simple enough, it's effective, and it's pretty resilient to things like the server going down. The worklist is still in the db so it can be restarted later. wow, I went off at length again.
May 15 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:iqp7gu$7l6$1 digitalmars.com...
 (BTW, PHP's automatic session handling *only* uses the session id.
 This leaves it open to trivial session hijacking. In web.d, the
 session functions automatically check IP address and user agent
 as well as cookies. It can still be hijacked in some places, but
 it's a little harder. To prevent hijacking in all situations,
 https is a required part of the solution, and the cgi library can't
 force that unilaterally. Well, maybe it could, but it'd suck.)

My understanding is that you CANNOT assume different requests in the same session from the same computer are coming from the same IP. Apperently there are a lot of networks, such as corporate networks and anonymizing networks, which will cause different requests from the same user to wind up coming from different IPs. The *ONLY* reliable way to prevent session hijacking without breaking your site for many users is to force everything (and I mean EVERYTHING) through https from the time the session is created to the time the session is killed. Yes, that does suck, but you'll certainly never see me claim that the web isn't the absolute worst, piece of shit excuse for an "applications platform" in history. One of the reasons for this particular mess (besides the whole "shoving applications through a stateless protocol" bullshit) is idiotic limitations of cookies. More specifically, there isn't nearly enough you can do to restrict the URLs for which the browser will send a particular cookie.
May 15 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
 My understanding is that you CANNOT assume different requests in
 the same session from the same computer are coming from the same IP.

Yea, I've heard of that, but it seems to work. phpBB has an option to only check some of the IP, which would probably work even better. Worst case is if I get a bug report from someone saying "I can't log in" and it not just that the user forgot his password... it's a trivially easy change to make.
May 15 2011
prev sibling parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 20:54, Adam D. Ruppe wrote:

 FYI, PHP uses files on the hard drive for sessions by default...
 optionally, it can use a database too.

Not really. There are different options to keep the session data, though - so some of them may resort to store something in the disk. Both cases (disk/db) terribly slow down everything. I don't know how many visitors your websites have, but if you have several visits per second - you will feel it.
 AFAIK, there is no in-memory option beyond the options the kernel or database
provide for file/table caching.

There are several, again - like memcache. Believe me, once you have at least 500k page requests/month (excluding images and other static content, of course), you will change your mind about where (and how) to store data.
 But, I never finished it, because I use sessions so rarely. Most
 usages of it don't match well with the web's stateless design -
 if someone opens a link on your site in a new window, can be
 browse both windows independently?

Web is stateless as long as you have static content only. What about web-commerce, shopping, applications like Google AdWords, web-mail etc? How can you handle it? But what do you mean by "independently"? Sure you can browse both, just any changes in session state (like, adding something to shopping cart) will be propagated to all windows eventually.
 Changing one *usually* shouldn't change the other.

Sorry? Do you ever do some shopping online? ;) If I have many windows open, with different items, I *expect* that all of them will go into *one* shopping cart - "usually" :)
 Another big exception is something like a shopping cart. In cases like that, I
prefer to use the database to store the cart anyway.

Ah, here we are. Sure, you will need to store into DB - but only *if* there are changes. For any data which is not changing, but requested quite often, each access to the database will slow things down.
 In web.d, the session functions automatically check IP address and user agent
 as well as cookies. It can still be hijacked in some places, but it's a little
harder.

This is exactly what well-designed application and libraries do.
 To prevent hijacking in all situations, https is a required part of the
solution, and the cgi library can't
 force that unilaterally. Well, maybe it could, but it'd suck.)

It *can* enforce, by refusing non-encrypted connection, or redirecting to https when access is done by http.
 The downside is I *believe* it doesn't scale to massiveness. Then
 again, most our sites aren't massive anyway, so does it matter?

Most of our are massive enough, so - it does matter :)
 Finally, long running processes can't be updated. You have to kill them and
restart, but if their state is only in memory, this means
 you lose data.

Not really - process should flush any dirty data to persistent storage and quit, so new copy may catch on. /Alexander
May 16 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Alexander wrote:
 I don't know how many visitors your websites have, but if you have
 several visits per second - you will feel it.

Two notes here: #1 several visits per second means over 5 million views a month. That's actually very rare. The way I do optimizations is I write it just however comes to mind first (which usually isn't half bad, if I do say so myself), then watch it under testing. If it proves to be a problem in real world use, then I'll start watching the times. IE9 has things built in to watch on the client side. D has stuff built in to watch the server side code. I sometimes just sprinkle writefln(timestamp) too for quick stuff. I'm sometimes right about where the problem was, and sometimes quite surprised. It's those latter cases that justify this strategy - it keeps me from barking up the wrong tree. (except once, a week or so ago. I was tracking down a bug that I believed to be in druntime. So I recompiled druntime in debug mode. At that point, it was 1am, so I went to bed. When I woke up the next day... I forgot it was still in debug mode. So I went to the site, and was annoyed to see it took almost 30 seconds to load one of the features. That's unacceptable. It was a new feature with some fairly complex code, so it didn't occur to me to check druntime. I did the profiling and found a few slow parts in dom.d. Fixed them up and got a 20x speedup. But, it was still taking several seconds. Then, I remembered about druntime! Recompiled it in the proper release mode, and it was back to the speed I'm supposed to get - single digit milliseconds. Yeah, it's still 20x faster than it was, but 40 ms isn't /too/ bad... Oh well though, while it was unnecessary, the profiling strategy did still give good returns for the effort put in!) I've had problems with database queries being slow, but they have always been either complex queries or poorly designed tables. I've never had a problem with reading or writing out sessions. Another profiling story with the db query, but I'll spare you this time. Then again, I only write sessions once when a use logs in, and reads are quick. So even if the system was slow, it wouldn't matter much. Fun fact: the fastest page load is no page load. Client side caching is built into http... but it seems to be rarely used. If you mix code and data, you're screwed - you can't write out an HTTP header after output has been generated! My cgi.d now includes more than just the header() function though. It keeps an updatable cache time, that you can set on each function, and is output as late as possible. That means you can set caching on the individual function level, making it easy to manage, and still get a good result for the page as a whole. Caching static content is obviously a plus. Caching dynamic content can be a plus too. I've gotten some nice usability speed boosts by adding the appropriate cache headers to ajax calls. Even expiring in just a few minutes in the future is nice for users. (Of course, the fastest javascript is also no javascript... but that's another story.)
 But what do you mean by "independently"?

Let me give an example. I briefly attended college with a "web app" that was just a barely functional front end to an old COBOL app on the backend. The entire site was dependent on that flow - it kept a lot of state server side. If you click add class in a new window, then go to view schedule in the current window... both windows will fail. The view schedule will error out because that's not a proper add class command. Add class window will fail because it errored out in the other window. The thing was a godawful mess to use. You have to do it linearly, in just one window, every time. Ugh. If it were better designed, each individual page would contain all the state it needed, so each tab works without affecting the other. This is an extreme example, and there's some times where a little bit of sharing is appropriate. But, even then, you should ask yourself is server side sessions are really the right thing to do.
 *snip*
 Ah, here we are.

Yeah, you didn't have to do a line by line breakdown for something I discussed in the following paragraph. Though, I will say handling things like adwords and webmail don't need sessions beside logging in and maybe cookies, and if you use them, your site is poorly designed. Database access vs a session cache is another thing you'd profile. I suspect you'd be surprised - database engine authors spend a lot of time making sure their engine does fast reads, and frequently used tables will be in a RAM cache.
 It *can* enforce, by refusing non-encrypted connection, or
 redirecting to https when access is done by http.

My point is it requires server setup too, like buying and installing a certificate. You can't *just* redirect and have to work.
 Not really - process should flush any dirty data to persistent
 storage and quit, so new copy may catch on.

Indeed - you're using some kind of database anyway, so the advantage of the long running process is diminished.
May 16 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:iqrj55$24d8$1 digitalmars.com...
 Alexander wrote:

 Database access vs a session cache is another thing you'd profile.
 I suspect you'd be surprised - database engine authors spend a lot
 of time making sure their engine does fast reads, and frequently
 used tables will be in a RAM cache.

Yea, that's really one of the main points of a DBMS: Efficient access to large amounts of data. Although I'd imagine accessing a DB for simple things could easily end up slower if the DB is on a different server. Big companies will often have setups like. Then again, if the network is all designed as set up well, and not congested, and the DB does have the data in RAM cache, then I'd imagine the lack of needing to do physical disk I/O could still make it faster.
 It *can* enforce, by refusing non-encrypted connection, or
 redirecting to https when access is done by http.

My point is it requires server setup too, like buying and installing a certificate. You can't *just* redirect and have to work.

That's not as bad as you may think, I've done that for my server recently. I *highly* recommend StartSSL. Most SSL/TLS certs are pretty expensive, but StartSSL has a free one: http://www.startssl.com/?app=1 The only real limitations are: - You have to renew it every 1 year. - Each cert is only good for one domain, and no subdomains (although the "www" subdomain is included for free, in addition to "no subdomain"). - The only validation it does is validation of the domain and contact email. There are, naturally, some hoops to jump through when setting it up (generating/installing a client certificate first so you can authenticate with their site). But their site walks you through everything step by step, and if you just follow the directions you can have it all done in minutes. Their system does require JS, and doesn't really handle using multiple tabs, but they don't do any annoying flashiness with the JS, and even my notoriously JS-hating self still finds it well worth it. I've been using it on my site for a little over a year and haven't had any problems. It's been great.
May 16 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky:
 Then again, if the network is all designed as set up well, and
 not congested, and the DB does have the data in RAM cache, then I'd
 imagine the lack of needing to do physical disk I/O could still
 make it faster.

Yeah, I work with two setups like that, but in my cases the db servers are on very fast local network links, so it wasn't a problem. It comes back to the same key of optimization though: profile it in real situations, since there's a lot of factors that are hard to guess by gut alone.
 That's not as bad as you may think, I've done that for my server recently.

Yeah, I've recently started using startssl too. They seem to be doing it the way it ought to be done!
May 16 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqm4ru$qj3$1 digitalmars.com...
 On 13.05.2011 17:19, Adam D. Ruppe wrote:

 It's *much* better, especially for rapid development. The compiler
 will tell me if my changes anywhere break things anywhere else,
 so I can modify with confidence.

Sure, there are many pros. And one significant drawback - it couldn't be easily embedded into HTML code. Either, you have to generate all your pages from inside of CGI script, or use templates - but the main advantage of PHP is that you can mix it with page text.

That's not an advantage at all. That was considered an advantage of PHP (and ASP) ages ago, but then web developers quickly discovered that was a horrible, horrible thing to do and caused nothing but terrible code. Even the PHP/ASP worlds have pretty much abandoned that, and for good reason.
May 14 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 14.05.2011 21:48, Nick Sabalausky wrote:

 That's not an advantage at all. That was considered an advantage of PHP (and 
 ASP) ages ago, but then web developers quickly discovered that was a 
 horrible, horrible thing to do and caused nothing but terrible code.

*All* developers? ;) Sorry, I've to disagree - still there are way too many projects where this is not considered "horrible" (just two quite popular examples - Drupal & Wordpress).
 Even the PHP/ASP worlds have pretty much abandoned that, and for good reason.

Many examples in documentation (both for PHP and ASP), including various tutorials, show how to mix the code and the data - this means "abandoned"? Perhaps, you could tell me this "good reason"? I see no good reasons, to be honest. /Alexander
May 14 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
  *All* developers? ;) Sorry, I've to disagree - still there are way
 too many projects where this is not considered "horrible" (just two
 quite popular examples - Drupal & Wordpress).

#1: Wordpress /is/ horrible. One of the worst projects I have to deal with for work... (in the OT subthread where I talked about immutable $_POST, that was inspired by some awful code inside Wordpress!) The template system (see next) has lots of required boilerplate and ugliness too. Take a look at twentyten/header.php for some examples. #2: Even Wordpress doesn't mix code with output very often - it uses a template system too - the themes folder. Sure, PHP is it's template language, but it does separate the main code from the template code. It fits under the category of disciplined php I touched upon in my document. I don't know drupal so I can't comment on that.
May 14 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 01:25, Adam Ruppe wrote:

 #1: Wordpress /is/ horrible. One of the worst projects I have to deal with for
work...

It works, and does it well enough. There are many projects which look horrible in the code, but the fact is - they work. But, perhaps, you may suggest an ideal blog engine? Where everything is done right?
 #2: Even Wordpress doesn't mix code with output very often - it uses
 a template system too - the themes folder. Sure, PHP is it's template
 language, but it does separate the main code from the template code.

That's where I see the mixture of language and templates. XML templates look horrible - but this is just a question of taste :) In some of my projects, I want to have code on pages, so I can transform and manipulate the data - because sometimes business logic fits perfectly into pages, not the application, especially when you don't have source for application and want to change/extend something. If someone would ever make D to work exactly like PHP or ASP does (I mean - integration into templates) - then it would be perfect for me. Yes, may be "horrible" (to you or some others) - but I'll be more productive than with DOM-XML templates :) /Alexander
May 15 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Alexander wrote:
 XML templates look horrible - but this is just a question of taste

But Wordpress' code *is* an xml template, just with other crap mixed in. One of the downsides of me writing my document in notepad is adding code examples in a pain. I didn't want to manually write &lt;div&gt; over and over again, so I just sidestepped it. But, here's a template from my D demo: http://arsdnet.net/apidemo-document.html It's standard HTML, nothing more. The same stuff you'd write in an ugly PHP file, but without the ugly PHP. The main difference is I didn't have to repeat myself over and over. Didn't have to separate the header, the footer, and the content (though, I could have. Most my real sites actually do that.) I didn't have to write <div id="page-content"> <?php output_page_content(); ?> </div> And a corresponding function in the code. The id on the div is everything it needed to know. Another one: <table class="striped" id="our-data"> </table> That's all that's needed to be said in the template. The program uses the ID to fill in the data, and the class is caught in a generic post-processor to add class="odd" to every other row. (that is like unobstructive javascript for progressive enhancement, but done server side instead of on page load.) Such with PHP's Smarty templates would look like this: <table> {foreach from=$rows item=row} <tr class="{cycle values="odd,even"}"> <!-- output data here --> </tr> {/foreach} </table> Ugh. (and I forgot a closing tag there in my first draft! Would have broken the site. With the DOM, such things are rare since you write less xml (ironically), cleaner code, and if you mess up anyway, you get a clear message on where the missing tag is.) The D side, btw, looks like so: auto table = cast(Table) document.getElementById("our-data"); foreach(row; data) table.appendRow(row...); Much easier than the PHP equivalent too - it's all clear. And all properly closed and entity encoded with zero effort.
May 15 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 17:36, Adam D. Ruppe wrote:

 But Wordpress' code *is* an xml template, just with other crap mixed in.

Not really "XML template". XML template, in my view, is something that is pure XML, without any code in it. In WordPress, those are mix of HTML and code, nothing more.
 One of the downsides of me writing my document in notepad is adding code
examples in a pain. I didn't want to manually write &lt;div&gt;
 over and over again, so I just sidestepped it.

Well, normally, code examples are not something which is displayed on (say) internet shop pages ;) I couldn't even remember when I had to do this last time, to be honest - so quoting is not a concern for me. Perhaps, you don't need it, but I do want to have an option to modify application logic on the fly, in the template or any other dynamic page, that's why I like mix of code and data - especially when the code is insignificant fraction of data.
 The D side, btw, looks like so:
 
 auto table = cast(Table) document.getElementById("our-data");
 foreach(row; data)
    table.appendRow(row...);

 Much easier than the PHP equivalent too - it's all clear. And all properly
closed and entity encoded with zero effort.

"all clear" to you - who is the author :) To me, this all is not so clear - as I don't know (=see) where exactly in the document all this happens. The whole reason to mix code with templates is to see where specific values are written, that's why to me code like: <div id="page-content"> <?php output_page_content(); ?> </div> is much more clear - whatever it is - PHP, ASP, D or something else. You may call it ugly, bad practice, incorrect, etc - that's, probably, is true for you - but not for everyone out there. People have different preferences :) Some even like to write HTTP servers in bash or postscript, and, though this is doable - it is not really practical to anyone who is used to something different - that's what I want to say. /Alexander
May 15 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Alexander wrote:
  Perhaps, you don't need it, but I do want to have an option to
  modify application logic on the fly, in the template or any other
  dynamic page, that's why I like mix of code and data - especially
  when the code is insignificant fraction of data.

I think you'll feel differently once you see people abuse that option. It becomes hard to follow what's going on. Then, when the customer reports a bug or a change, you spend all night pounding your head over it instead of 5 minutes doing it, then goofing off arguing on newsgroups for the rest of the day :P
 all clear" to you - who is the author :) To me, this all is not
 so clear - as I don't know (=see) where exactly in the document
 all this happens.

You're also not used to it. (When I write this for newbies, I often put a comment in there: <!-- filled by program -->) It's an easy pattern though: an empty element with an ID is meant to be filled in, and the ID should be descriptive enough to make a good guess at what it's doing. (at least no worse than guessing a function's behavior based on it's name. Similarly, knowing what ID to use is the same as knowing what function to use.) I sometimes get concerned that the id's will get out of sync, or the new guy won't understand what's going on, but it hasn't been a problem in practice. After you see it used once, it's not a mystery anymore.
May 15 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 19:36, Adam D. Ruppe wrote:

 I think you'll feel differently once you see people abuse that option. It
becomes hard to follow what's going on.

Sure I will feel differently, that's why I've said "if used correctly" - and I do use it correctly :)
 You're also not used to it. (When I write this for newbies, I often put a
comment in there: <!-- filled by program -->)

That kind of a comment made me crazy many times - because then I had to dig inside the program to find the place where it was filled :)
 It's an easy pattern though: an empty element with an ID is meant to be filled
in, and the ID should be descriptive enough
 to make a good guess at what it's doing.

If at some point I want to change output from table view to something else - then I've to change the application as well, as it generates series of tr/td elements, which I don't need anymore. To me, it is much easier to change it in place - i.e. where this is done actually. Bouncing from template to code is quite annoying, to be honest, especially when that code is not your own :)
 After you see it used once, it's not a mystery anymore.

It is not a mystery, just something that is blocking my productivity :) I just don't like it - and because of this I am less productive. From my point of view, it makes no sense to say "that is wrong" or "that is bad" - unless there is *objective* (and only) way to do something *right* - which is not the case in web development (and any software development in general). So, to some people (including myself) unless and until D may be embedded like PHP/ASP, it will be a show stopper. For some others - it will not, that's all. For this reason, I prefer to use D as a backend only (=performance critical), and frontends will be in PHP or ASP (=UI only). Though, currently I evaluate option to use D to host a server (HTTP) with dmdscript as server-side scripting language. What blocks me is the absence of good, robust and high-performance socket/file I/O framework for D2. /Alexander
May 15 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Alexander:
 That kind of a comment made me crazy many times - because then I
 had to dig inside the program to find the place where it was filled

Meh, is it any worse than digging into the program to figure out what a function referenced in the template does?
 If at some point I want to change output from table view to
 something else - then I've to change the application as well

Not necessarily - you could add format strings to the html, or have the output dependent on the tag name. The Javascript access to my code I pointed to earlier includes this: HTML, using a custom formatter provided by the Person object: http://arsdnet.net/cgi-bin/apidemo/get-people?startingId=0&format=html String, using a part custom, part automatic formatter: http://arsdnet.net/cgi-bin/apidemo/get-people?startingId=0&format=string Table, using an automatic formatter: http://arsdnet.net/cgi-bin/apidemo/get-people?startingId=0&format=table Json, using an automatic formatter: http://arsdnet.net/cgi-bin/apidemo/get-people?startingId=0&format=json The D function simply returned a Person[]. The formatting is flexible, automatic in a lot of cases, hookable by the object if needed. But, in a lot of cases, you have to change the model to change the data you're showing anyway... the view only has what's available to it. Even when mixed php code/data, you're going to either repeat yourself a lot, or be limited by what's available in existing functions or in the database. The semantics of the data won't change without touching app code, so the tags at this low level probably won't either. Changing their appearance is done by CSS. Take this table: http://arsdnet.net/cgi-bin/apidemo/get-people?startingId=0&format=table Want to show it as a list? Use CSS: table { display: block; border: none; padding-left: 2em; } thead { display: none; } tr { display: list-item; } th, td { display: inline; border: none; margin-left: 0.2em; } Boom, the table now looks like an unordered list. Semantically though, it's still tabular data, and the markup reflects that. See it live here: http://arsdnet.net/get-people.htm
 What blocks me is the absence of good, robust and
 high-performance socket/file I/O framework for D2.

When I wrote my http code, one of which is a kind of proxy/webapp build in one, so it does server and client work, I just used the appropriate C functions. Everything accessible from C is also accessible from D, so even if phobos isn't quite up to it, you can always do without. I agree it will be nice when phobos' offering improves though.
May 15 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
I wrote:
 When I wrote my http code,

I just spent a little time updating this. It's still built on my old netman.d, which uses Linux system calls so prolly linux only (it does select() and friends directly, should be easy enough to port to WinSock or std.socket but I wrote what I knew and left it at that). Removed some of the logic since the CGI class does it in a more structured way, and added support for HTTP 1.0 and better support for non-conforming clients. These steps aren't really necessary to work - today's browsers know to use \r\n and HTTP 1.1, but the ab program - apache benchmark - does not, and I wanted to see what happens when I attack it. Cache headers (if-modified, etc.) are not handled properly on the server, and cgi.d doesn't expose them at this time. This thing isn't meant to be used in production, unless it's in the back end, behind something more battle tested and standards conformant, like Apache. That said, ab's results weren't too bad if and only if the handler runs quickly. The reason for that is it is single-threaded. (the network manager class is based on a cooperative multitasking setup - each connection gets it's onDataReceived function called when new data comes in. It needs to look at it and return as soon as possible. Fine when it's all simple code, but with more complex websites it probably won't be.) While it's only a couple hundred lines long so I can't complain too much, this concurrency issue will have to be addressed before I can say it's really suitable for serious work. ... but, it is good enough to function as a notification server! Async notifications are fast, even if single threaded. Anyway while the implementation needs work, I am pretty happy with the api. Here's some code: import arsd.httpd; // the handler function is identical to one written with standard // CGI void handler(Cgi cgi) { cgi.write("Hello!"); cgi.write(to!string(cgi.get)); // show dynamic output cgi.close(); } // but instead of mixing in GenericMain or whatever, we call // serveHttp. void main() { // function pointer to handler, port to listen on serveHttp(&handler, 5000); } Nice and simple!
May 15 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-05-15 21:19, Adam D. Ruppe wrote:
 But, in a lot of cases, you have to change the model to change
 the data you're showing anyway... the view only has what's available
 to it.

Depending on what needs to be changed this is the job of the controller, to get the necessary data, for a specific view, out of the model. But, of course, if the model doesn't have the data in the first place that would be impossible. -- /Jacob Carlborg
May 16 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqp58d$3lh$1 digitalmars.com...
  From my point of view, it makes no sense to say "that is wrong" or "that 
 is bad" - unless there is *objective* (and only) way to do something 
 *right* - which is not the case in web development (and any software 
 development in general).

That's just plain rediculous. Software development isn't some damn hippie commune where "There are never any wrong answers, just different opinions! Tee hee hee :) :) :)". There *are* better ways and worse ways to do many things. Despite what everyone seems to have been brainwashed into believing these days, not everything is a matter of personal preference or opinion. Fuck, what's next? "Well, *for me* I like to have 2+2 equal 5, you can't say it's wrong, it's just my preference and my opinion." If some city architect decided to make the primary structural frame of a giant high-rise out of wood because "I like it, and it works well for me", that stupid screw-up would get fired on the spot, drummed out of the industry, and for good reason.
May 15 2011
parent Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 22:53, Nick Sabalausky wrote:

 That's just plain rediculous. Software development isn't some damn hippie 
 commune where "There are never any wrong answers, just different opinions! 

It is. There are *many* ways to do the same thing in software, using different languages, technologies and patterns.
 There *are* better ways and worse ways to do many things.

OK, turning 2 into 1 and vice versa, assuming X always holds 2 or 1: 1. 3 - X 2. X ^ 3 Which one is better? Expand this to couple dozens of languages - which is better, which is worse?
 Despite what everyone seems to have been brainwashed into believing 
 these days, not everything is a matter of personal preference or opinion. 

Sure, not everything. But software development - is. There are, sure, better and worse ways to do things, but still, there are *many* of them - on both sides.
 If some city architect  decided to make the primary structural frame of a
giant high-rise out of 
 wood because "I like it, and it works well for me", that stupid screw-up 
would get fired on the spot,
 drummed out of the industry, and for good reason.

Nope. There are *many* ways for architects to build. Many materials, and as long as one or another does whatever is expected from it - it works. This is not only about "works for me" - this is about - "works as ordered by the customer", "works as it should" and "works according to specifications". And surely, there are *many* ways to achieve *same* results - in many different areas, including architecture. /Alexander
May 15 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-05-15 20:11, Alexander wrote:
 On 15.05.2011 19:36, Adam D. Ruppe wrote:

 I think you'll feel differently once you see people abuse that option. It
becomes hard to follow what's going on.

Sure I will feel differently, that's why I've said "if used correctly" - and I do use it correctly :)
 You're also not used to it. (When I write this for newbies, I often put a
comment in there:<!-- filled by program -->)

That kind of a comment made me crazy many times - because then I had to dig inside the program to find the place where it was filled :)
 It's an easy pattern though: an empty element with an ID is meant to be filled
in, and the ID should be descriptive enough
 to make a good guess at what it's doing.

If at some point I want to change output from table view to something else - then I've to change the application as well, as it generates series of tr/td elements, which I don't need anymore. To me, it is much easier to change it in place - i.e. where this is done actually. Bouncing from template to code is quite annoying, to be honest, especially when that code is not your own :)
 After you see it used once, it's not a mystery anymore.

It is not a mystery, just something that is blocking my productivity :) I just don't like it - and because of this I am less productive. From my point of view, it makes no sense to say "that is wrong" or "that is bad" - unless there is *objective* (and only) way to do something *right* - which is not the case in web development (and any software development in general). So, to some people (including myself) unless and until D may be embedded like PHP/ASP, it will be a show stopper. For some others - it will not, that's all. For this reason, I prefer to use D as a backend only (=performance critical), and frontends will be in PHP or ASP (=UI only). Though, currently I evaluate option to use D to host a server (HTTP) with dmdscript as server-side scripting language. What blocks me is the absence of good, robust and high-performance socket/file I/O framework for D2. /Alexander

BTW, someone modified MiniD to support the <% %> syntax to embed it in html. -- /Jacob Carlborg
May 16 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqobn4$1h7v$1 digitalmars.com...
 On 15.05.2011 01:25, Adam Ruppe wrote:

 #1: Wordpress /is/ horrible. One of the worst projects I have to deal 
 with for work...

It works, and does it well enough. There are many projects which look horrible in the code, but the fact is - they work.

It *barely* works. And I *did* stop using it specifically because it worked so poorly.
May 15 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 22:56, Nick Sabalausky wrote:

 It *barely* works. And I *did* stop using it specifically because it worked 
 so poorly.

Don't get it too personally, but probably, you didn't read the manual? ;) It works perfectly, even for those who are *not* familiar with software of web development. /Alexander
May 15 2011
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 15/05/2011 22:44, Alexander wrote:
 On 15.05.2011 22:56, Nick Sabalausky wrote:
 It *barely* works. And I *did* stop using it specifically because it worked
 so poorly.


+1
    Don't get it too personally, but probably, you didn't read the manual? ;)

    It works perfectly, even for those who are *not* familiar with software of
web development.

 /Alexander

It most definitely does not work perfectly. You highlight those that are not familiar with web development? They're the ones that use it. Visual Studio defaults to not using it now, there's a reason for that. I don't know about PHP IDEs. -- Robert http://octarineparrot.com/
May 15 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 16.05.2011 01:25, Robert Clipsham wrote:

 It most definitely does not work perfectly. You highlight those that are not
familiar with web development? They're the ones that use it.
 
 Visual Studio defaults to not using it now, there's a reason for that. I don't
know about PHP IDEs.

I am sorry, but do we talk about the same thing? How is WordPress related to Visual Studio, especially how could it "use it"? /Alexander
May 16 2011
parent Robert Clipsham <robert octarineparrot.com> writes:
On 16/05/2011 09:54, Alexander wrote:
 On 16.05.2011 01:25, Robert Clipsham wrote:

 It most definitely does not work perfectly. You highlight those that are not
familiar with web development? They're the ones that use it.

 Visual Studio defaults to not using it now, there's a reason for that. I don't
know about PHP IDEs.

I am sorry, but do we talk about the same thing? How is WordPress related to Visual Studio, especially how could it "use it"? /Alexander

My bad, I was rather tired when I posted this, I thought I was replying to something else. Sorry! -- Robert http://octarineparrot.com/
May 16 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqmrh6$22b0$1 digitalmars.com...
 On 14.05.2011 21:48, Nick Sabalausky wrote:

 That's not an advantage at all. That was considered an advantage of PHP 
 (and
 ASP) ages ago, but then web developers quickly discovered that was a
 horrible, horrible thing to do and caused nothing but terrible code.

*All* developers? ;) Sorry, I've to disagree - still there are way too many projects where this is not considered "horrible"

There's always shitty programmers out there. *Especially* in web development.
 (just two quite popular examples - Drupal & Wordpress).

Not familiar with drupal. Wordpress is pure shit. And no, popularity does *not* equate to quality.
 Even the PHP/ASP worlds have pretty much abandoned that, and for good 
 reason.

Many examples in documentation (both for PHP and ASP), including various tutorials, show how to mix the code and the data - this means "abandoned"?

You're being extremely nitpicky.
  Perhaps, you could tell me this "good reason"? I see no good reasons, to 
 be honest.

Do it professionally for a few years and you'll see the reasons.
May 14 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:iqnl10$au2$1 digitalmars.com...
 "Alexander" <aldem+dmars nk7.net> wrote in message 
 news:iqmrh6$22b0$1 digitalmars.com...
 On 14.05.2011 21:48, Nick Sabalausky wrote:

 That's not an advantage at all. That was considered an advantage of PHP 
 (and
 ASP) ages ago, but then web developers quickly discovered that was a
 horrible, horrible thing to do and caused nothing but terrible code.

*All* developers? ;) Sorry, I've to disagree - still there are way too many projects where this is not considered "horrible"

There's always shitty programmers out there. *Especially* in web development.

As an example, I once worked at a place where the code was all VB6, it was filled with meaningless variable names like "stbbb" and "aaa", and they frequently used the following idiom: If {condition} Then {do stuff} Goto label End If {do stuff} label: All of that *was considered acceptable practice*. But the fact they found it acceptable obviously doesn't change the fact that those are horrible practices: it just meant they were a bunch of complete fucking amateur morons. And such people are *all over* web development. Full time, with a salary. It's pathetic, but very, very true. So no, of course not "all" developers consider classic-style-PHP code/html-mixing to be horrible, but the ones who actually have at least somewhat of a clue what the hell they're doing certainly do.
May 14 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 06:42, Nick Sabalausky wrote:

 All of that *was considered acceptable practice*. But the fact they found it 
 acceptable obviously doesn't change the fact that those are horrible 
 practices: it just meant they were a bunch of complete fucking amateur 
 morons.

Until and unless we have clear definition of "good practice", which is acceptable and practiced my majority, the definition of "good" and "bad" is purely point of view and extremely subjective. Sorry, but the only thing I wanted to say - is that in some cases D is not good for dynamic web (don't want to repeat myself - why). You don't think so? Good, follow whatever you believe is good - no questions, no problems. Just recognize that there are many people and many opinions and practices, which are good or bad for any particular application - that's all. Really, I don't want to start a flame - what is good or bad. Just expressing my opinion :) /Alexander
May 15 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqocgq$1iko$1 digitalmars.com...
 On 15.05.2011 06:42, Nick Sabalausky wrote:

 All of that *was considered acceptable practice*. But the fact they found 
 it
 acceptable obviously doesn't change the fact that those are horrible
 practices: it just meant they were a bunch of complete fucking amateur
 morons.

Until and unless we have clear definition of "good practice", which is acceptable and practiced my majority, the definition of "good" and "bad" is purely point of view and extremely subjective.

And like I said at the beginning, the old-style-PHP/ASP of mixing code and HTML is one of the things that *HAS* become widely accepted as bad practice. Just because there are some amateurs and incompetent "professionals" around that still don't know any better doesn't change that fact.
  You don't think so? Good, follow whatever you believe is good - no 
 questions, no problems. Just recognize that there are many people and many 
 opinions and practices, which are good or bad for any particular 
 application - that's all.

Ugh, I never could stand that hippie rhetoric. Despite what society's been brainwashed into believing, there *ARE* opinions out there that are just plain moronic, and yes, *wrong*.
May 15 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 23:05, Nick Sabalausky wrote:

 And like I said at the beginning, the old-style-PHP/ASP of mixing code and 
 HTML is one of the things that *HAS* become widely accepted as bad practice. 

Could you please back your claims with something? I know already that you are the kind of person who knows better, and you are used to speak for everyone, but that's just words.
 Just because there are some amateurs and incompetent "professionals" around 
 that still don't know any better doesn't change that fact.

And you are professional? Show me something that is professional, so I can learn.
 Ugh, I never could stand that hippie rhetoric. Despite what society's been 
 brainwashed into believing, there *ARE* opinions out there that are just 
 plain moronic, and yes, *wrong*.

And yours is always *right*? ;) /Alexander
May 15 2011
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 15/05/2011 22:46, Alexander wrote:
 On 15.05.2011 23:05, Nick Sabalausky wrote:

 And like I said at the beginning, the old-style-PHP/ASP of mixing
 code and HTML is one of the things that *HAS* become widely
 accepted as bad practice.

Could you please back your claims with something? I know already that you are the kind of person who knows better, and you are used to speak for everyone, but that's just words.

I can't be bothered collecting lots of references, but having done web development both professionally (not as much as Nick) and non-professionally, I can tell you that it *is* widely accepted as bad practice. I've found the people that don't agree with that are either (reasonably) new to web development, or don't really know what they're doing.
 Just because there are some amateurs and incompetent
 "professionals" around that still don't know any better doesn't
 change that fact.

And you are professional? Show me something that is professional, so I can learn.
 Ugh, I never could stand that hippie rhetoric. Despite what
 society's been brainwashed into believing, there *ARE* opinions out
 there that are just plain moronic, and yes, *wrong*.

And yours is always *right*? ;)

Meet the seasoned web developer - 99.9% of other web developers are idiots who can't code, and anyone who does it differently to you is wrong. After a certain amount of time working with the web, and several code bases that started as quick hacks to get the job done but evolved into entire websites with a good few users, you realize that most of the code out there is terrible. It gets the job done, sure, but it takes a lot of effort to debug or add new features. Anything you add to the code base just makes it harder to maintain, even if you start writing things properly. Want to re-factor something? Chances are you can't do it without breaking something. If you're curious, add: error_reporting(-1); To the start of most PHP applications, and see the large number of notices/warnings/errors which scroll past in your error log - over time the PHP developers (not developers that use PHP) have realized how many things can go wrong (register_globals, magic_quotes, safe_mode, etc), and added more warnings, notices and errors which aren't shown by default. I've encountered a good few developers which have said I shouldn't have enabled it and it's not their problem when working with their code. Note that things like wordpress use error_reporting() elsewhere, so adding error_reporting(-1); won't make any difference as it will be overridden. Of course, I'm not saying Nick is always right (I happen to disagree with him on a few things, just mention javascript to him to see what I mean :D), but you now have 3 developers with varying experience with the web telling you it's not the right thing to do. Sure, it's fantastic for quick sites, nice and fast to put something together... But when it evolves into a something bigger it will be a nightmare. Using a decent framework is just as fast, and it's easy to maintain later on. As for using D for web development... I'd use it even without a web framework, purely for the maintainability/error reporting issues mentioned earlier on. There are no frameworks available that I'm aware of other than Adam's currently (which I believe he's using professionally, so it has to be reasonably good), but something is better than nothing. I'm also working on my own, progress is slow though due to time constraints. Give it a few months and it might be workable.
 /Alexander

Seems I managed quite a rant there. Oops :D -- Robert http://octarineparrot.com/
May 15 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Robert Clipsham:
 which I believe he's using
 professionally, so it has to be reasonably good)

Indeed, cgi.d, mysql.d, and dom.d have both been used on a few of my client's live sites for about a year now. If they have serious bugs, I've subconsciously learned to avoid them, since there's been little problems with them. sqlite.d and postgres.d seem to be ok, but haven't gotten as heavy use as mysql. The newer web.d, that I've been linking to as the apidemo, is used for some in development apps, but nothing that's launched yet. (Everyone is very excited about these in-dev apps though, it's been excellent during internal testing and I've made excellent time developing new features with it.) There's a number of helper modules too that work well, but are more tied to the application itself, so I haven't released them. (If there's potentially anything proprietary in a file at all, I hold the whole thing back unless I can find the time to carefully comb through it.) The two most likely to go public before too long are: email.d for talking to sendmail, Gmail relays, and recently added, Amazon SES. Also minimal includes MIME attachment support and a html to text converter for automatically making multipart messages. (they write html emails but I loathe them.) oauth.d for interacting with Facebook's apis (oauth 2) and Twitter, LinkedIn, and (buggy) AWeber (oauth 1). As of last night, it also has a minimal oauth 1 server implementation. Needs lots of testing. It's a pretty wide collection of stuff, with the base reasonably well tested. Most of it is nothing fancy though.
May 15 2011
prev sibling parent reply Alexander <aldem+dmars nk7.net> writes:
On 16.05.2011 01:21, Robert Clipsham wrote:

 I can't be bothered collecting lots of references, but having done web
development both professionally (not as much as Nick) and non-professionally, I
can tell you that it *is* widely accepted as bad practice.

Accepted as bad practice by whom? Looks like there is very small fraction of "real" web developers, who is deciding what is "bad practice", as almost anything which is public widely using it. Times change, and something was considered as "good practice" may change to "bad practice" in few years, and vice versa - I've seen that enough in last 20 years.
 ...but you now have 3 developers with varying experience with the web telling
you it's not the right thing to do.

I am sorry, but I didn't see any works of those web developers (I mean - the code), so I couldn't make my mind - what is *good* practice, and why it is better than anything else (again - *if done properly*). Good practice, from my point of view, is something that: - Easy to understand; - Easy to maintain; - Easy to extend; - Does its job well (according to specifications); - Has good performance; - Doesn't have any holes. So, it doesn't matter, how exactly specific solution is implemented, as long as all of those point are met. I can mix code with data or use DOM templates - as long as I fulfill the above stated requirements, it really doesn't matter. It is like my recent question about class member declaration order - I find it harder to understand the code, when members are not declared before use, though, others (on this list) tend to disagree with me. Who is right here? /Alexander
May 16 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqqq9p$ka6$1 digitalmars.com...
 On 16.05.2011 01:21, Robert Clipsham wrote:

 I can't be bothered collecting lots of references, but having done web 
 development both professionally (not as much as Nick) and 
 non-professionally, I can tell you that it *is* widely accepted as bad 
 practice.

Accepted as bad practice by whom? Looks like there is very small fraction of "real" web developers, who is deciding what is "bad practice", as almost anything which is public widely using it.

The vast majority of web developers *are* very, very, poor coders. Being correct and being in the majority have absolutely *nothing* to do with each other.
  Times change, and something was considered as "good practice" may change 
 to "bad practice" in few years, and vice versa - I've seen that enough in 
 last 20 years.

That's an enormous oversimplification.
 ...but you now have 3 developers with varying experience with the web 
 telling you it's not the right thing to do.

I am sorry, but I didn't see any works of those web developers (I mean - the code), so I couldn't make my mind - what is *good* practice, and why it is better than anything else (again - *if done properly*). Good practice, from my point of view, is something that: - Easy to understand; - Easy to maintain; - Easy to extend; - Does its job well (according to specifications); - Has good performance; - Doesn't have any holes. So, it doesn't matter, how exactly specific solution is implemented, as long as all of those point are met. I can mix code with data or use DOM templates - as long as I fulfill the above stated requirements, it really doesn't matter. It is like my recent question about class member declaration order - I find it harder to understand the code, when members are not declared before use, though, others (on this list) tend to disagree with me. Who is right here?

When you're not doing trivial stuff, the traditional mix-code-and-html approach fails miserably at: - Easy to maintain; - Easy to extend; - Doesn't have any holes. And it also causes this to become a bigger and bigger problem as a project progresses: - Easy to understand; All of that, in turn, makes this MUCH, MUCH harder than it would otherwise be: - Does its job well (according to specifications);
May 16 2011
parent Alexander <aldem+dmars nk7.net> writes:
On 16.05.2011 12:23, Nick Sabalausky wrote:

 The vast majority of web developers *are* very, very, poor coders. Being 
 correct and being in the majority have absolutely *nothing* to do with each 
 other.

Sorry, but I still don't get it - who is defining what is correct and what is not? And why?
 When you're not doing trivial stuff, the traditional mix-code-and-html 
 approach fails miserably at:
 
 - Easy to maintain;
 - Easy to extend;
 - Doesn't have any holes.

Why it fails here? Why it doesn't fail for me? Or some other people? Sure there are always poor coders who could fail anything, but not everyone.
 And it also causes this to become a bigger and bigger problem as a project 
 progresses:
 
 - Easy to understand;

As long as you follow some simple rules when coding, nothing bad happens. On the other hand, there always people who don't understand your code, and you - theirs. What is difficult for you, may be piece of cake for someone else, and vice versa - it is all bound to how your barin works :) Some people easily and in few minutes do sophisticated stuff in languages like BrainFuck, while for me that will be exactly what name of this language means. Exactly the same thing applies to web development (and any development) - is it easy to understand or not, depends on who is trying to understand. And no, you simply cannot make something very complex so easy that anyone will understand it like you (the author) do.
 All of that, in turn, makes this MUCH, MUCH harder than it would otherwise 
 be:
 
 - Does its job well (according to specifications);

I know personally at least one project, which fail miserably in many, many points - but does it's job *very* well for more than 10 years. How is this linked then? Or, look at djb code (qmail & co) - the code itself is terrible, still, one of the most used - and less buggy that many "well designed" and "good practiced" projects. The only example of good code and good practice that I ever knew is cryptlib, though this is not exactly related to web development... /Alexander
May 16 2011
prev sibling parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 06:28, Nick Sabalausky wrote:

 There's always shitty programmers out there. *Especially* in web development.

Looks like most of them are, right? :)
 Not familiar with drupal. Wordpress is pure shit. And no, popularity does
*not* equate to quality.

From end user point of view, "quality" is something that defines how good application is performing, not how it is written. IMHO.
  Perhaps, you could tell me this "good reason"? I see no good reasons, to be
honest.

Do it professionally for a few years and you'll see the reasons.

WordPress developers (not all, of course, but some) do it professionally for many years, still, whatever they do, you call it "pure shit", and they don't see the reasons you see. That's why I asked about "good reason" - a guideline to follow, which is rational for anyone. /Alexander
May 15 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqoc6r$1hqu$1 digitalmars.com...
 On 15.05.2011 06:28, Nick Sabalausky wrote:

 There's always shitty programmers out there. *Especially* in web 
 development.

Looks like most of them are, right? :)

Unfortunately, yes.
 Not familiar with drupal. Wordpress is pure shit. And no, popularity does 
 *not* equate to quality.

From end user point of view, "quality" is something that defines how good application is performing, not how it is written. IMHO.

I've *been* a WordPress end user. It performed like shit. I got rid of it. I don't doubt there are many amateurs out there who could look straight at a total POS and not see the obvious problems. Just look at all the Apple fans.
  Perhaps, you could tell me this "good reason"? I see no good reasons, 
 to be honest.

Do it professionally for a few years and you'll see the reasons.

WordPress developers (not all, of course, but some) do it professionally for many years, still, whatever they do, you call it "pure shit", and they don't see the reasons you see.

Like I described in another post, I've *worked with* people who did web development professionally who still undeniably had nearly zero real competence. So you can't tell me just because they do it professionally indicates they actually have a clue what they're doing.
  That's why I asked about "good reason" - a guideline to follow, which is 
 rational for anyone.

Nothing is "rational for anyone" because most people are irrational imbeciles.
May 15 2011
next sibling parent reply Alexander <aldem+dmars nk7.net> writes:
On 15.05.2011 23:13, Nick Sabalausky wrote:

 I've *been* a WordPress end user. It performed like shit. I got rid of it.

There are many people who dislike Windows too - for the same reasons. But now, I want to know - which universe you are from? I never had any problems with WordPress nor Windows, despite the fact that forums are full of screams. Perhaps, you could tell me, what exactly doesn't work, so majority of users didn't notice and still use it? ;)
 I don't doubt there are many amateurs out there who could look straight at a 
 total POS and not see the obvious problems. Just look at all the Apple fans.

Sure, Apple has his share of problems. But they are rich and popular. Do you, with your "perfect solutions"? ;)
 Nothing is "rational for anyone" because most people are irrational imbeciles.

Thank you, Nick. Now I know who I am :) /Alexander
May 15 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqpi2b$pc7$1 digitalmars.com...
  Sure, Apple has his share of problems. But they are rich and popular. Do 
 you, with your "perfect solutions"? ;)

Sorry, I forgot that what's popular is always right and what's right is always popular.
May 15 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqpi2b$pc7$1 digitalmars.com...
 Nothing is "rational for anyone" because most people are irrational 
 imbeciles.

Thank you, Nick. Now I know who I am :)

FWIW, I didn't intend anything I've said as anything personal against you. It probably did came across that way though. Wasn't my intent.
May 15 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-05-15 23:13, Nick Sabalausky wrote:
 Like I described in another post, I've *worked with* people who did web
 development professionally who still undeniably had nearly zero real
 competence. So you can't tell me just because they do it professionally
 indicates they actually have a clue what they're doing.

That seems to especially true with web development. -- /Jacob Carlborg
May 16 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-13 17:19, Adam D. Ruppe wrote:
 Jacob Carlborg wrote:
 How is it working out with a static type system, compared to a
 dynamic, for web development?

It's *much* better, especially for rapid development. The compiler will tell me if my changes anywhere break things anywhere else, so I can modify with confidence. I can't tell you how many times I've made a minor mistake in PHP, Ruby, or Visual Basic and had it slip through to production because the code path was obscure enough to evade testing.

That's what I really miss when doing web development in a language with a dynamic type system. It's hard to do any refactoring, always the possibility to break some code you had no idea would be affected.
 Sometimes, something similar does happen in D - to!int("") throws -
 but, the compiler catches the majority of incompatible changes
 instantly.

 If I had int addUser() and change it to User addUser(), I don't
 have to hunt every instance down myself. Just hit compile and
 the compiler tells me where the change causes problems. (Rarer than
 you might think - thanks to auto, a lot of the program is already
 duck typed in a way. The actual return value name is rarely used.)


 It also helps documentation to have good types. I often see stuff
 like this in dynamic language docs:

 function doSomething(options);

 What does it return? What options are available? Maybe the text
 will tell us that options is an associative array. UGH, I hate
 that! Now, there's even less knowing what's going on.

Actually that's one thing I really like with Ruby and Rails, that you can put different types of values in arrays and hashes. But I can agree, sometimes it's hard to know what options are available.
 D's documentation is a lot more helpful, and easier to keep up to
 date.

 string doSomething(Options options); // not much better yet....

 struct Options;
 int speed;
 bool strictMode;
 bool caseSensitive;


 Ahhh, now I know!

But that way you would need to declare different types of Options structs all over the place?
 Another thing that the static types enable that I don't think is
 possible with dynamic functions is the automatic forms you see
 on my link.

 http://arsdnet.net/cgi-bin/apidemo/get-a-box

 I didn't write any html for that. The library made it for me.

 In the source, you can see it's prototype:
 http://arsdnet.net/apidemo.d
 	Element getABox(Color color);


 The reflection was able to say "it needs a Color, and there's only
 a handful of valid Colors - enum Color - so I can automatically
 create a<select>  box for this."

 Dynamic types for return values can still do most the stuff my
 api generator does. Whether it's a static function/template toHtml
 or a dynamic property doesn't matter much.

 But the parameters... I don't think it can be done without the
 static types there.

 (Another nice thing is the library checks the type too. Coming
 off the request parameters, you have strings; dynamic types. But
 going into the function, it knows it must be a Color, so it
 checks. If not, an exception is thrown.

 By the time you're inside the function, you can be guaranteed that
 Color color is indeed a Color. Thus, to!string() to insert it into
 the html attribute that I did here is perfectly safe. It's a
 whitelist based filter, all done automatically.)



 There are a few cases where dynamic types are helpful or needed.
 D lets us opt in to them with only a minimal amount of fuss.

 The places where I use it are:

 1) Data from the user. Form variables are of type string coming
 into the program. Once decoded, you have string[][string]. Your
 program probably wants something else.

 The to!() template in Phobos makes this pretty easy, or if you
 want default value and get/post combined, my cgi class has a request
 template:

 int a = cgi.request!int("a");

 That's similar to this in PHP:

 $a = 0;
 if(isset($_POST['a']))
    $a = (int) $_POST['a'];
 else
 if(isset($_GET['a']))
    $a = (int) $_GET['a'];


 PHP is so outrageously verbose. And the PHP is buggy compared to
 the D... if you do cgi.request!int("a", 10) and the user does a=txt,
 the PHP result is wrong. It's not quite fair to compare a function
 to a code collection though. A php function could do it right too.

I think there are other languages available that is far better than PHP that you could compare with instead. Ruby on Rails: a = params[:a].to_i Depending on what you need this might not be the best way to write it. If :a doesn't exist in "params" it would return "nil" and "nil.to_i" would give you 0. If you use the Rails methods it will to the right thing most of the times without you need to worry about it. For example: Post.find(params[:a]) This will try to find a Post with the given id and automatically converted the given value to an integer. If it fails to convert the value to an integer it will return 0 (this is not the best solution and I don't like it). When it can't find a Post with the given value (you most likely won't have a an id in the database with the value 0) it will through an exception.
 Annnnyway, I'm digressing. Hell, I'm going on about weak types
 instead of dynamic types! Even in Ruby, you'd have to do a to_i
 since the url value simply is a string.



 Back to dynamic types. The three other places where you see them
 are databases and interfacing with external services.

 2) Databases

 With databases, you probably expect a certain type anyway. If the
 column is typed as INTEGER, you probably don't want 'lol' in there.
 But, the database takes care of that for you.


 In my libs, I just use strings.

 auto line = mysql.query("SELECT id FROM users WHERE id = 10").front;

 res[0] == "10"


 Conversions are now done the same as URL parameters:

 int id = to!int(res[0]);


 Oftentimes, I don't really care about it though; if I'm outputting
 it to html, I'll just say:

 table.appendRow(res["id"], res["name"])

 and the like anyway. You want a string there, so it just works.
 (appendRow is in fact a variadic template so it'd just work
 regardless, but you get the idea anyway).

I've been thinking for a while to try and create something similar as Rails' ActiveRecrod for D but every time I tried to do it turns out to work quite badly with a static type system. Either you would need to specify the columns and the types in the model class (which I would like to avoid) or you would have to use Variants all over the places. And if you use Variants all over the place then I don't so much reason in using a language with a static type system compared to a dynamic type system.
 Thanks to static checks though, if I were to later change my mind
 and wanted ints, or made the database return Variants or whatever,
 no problem - the compiler will point out trouble spots to me.


 Inserting data is the same:

 mysql.query("INSERT INTO users (id) VALUES (?)", 10); // works
 mysql.query("INSERT INTO users (id) VALUES (?)", cgi.post["id"]); // works too


 Or using the data object class:

 auto obj = new DataObject(mysql, "users");

 obj.id = 10; // works
 obj.id = "10"; // works just as well

 obj.commitChanges();

 (The DataObject can read too, offering database fields as obj.id
 style properties. They always return string, just like plain query,
 but are also read/write.)


 DataObject can also be specialized automatically to use static
 types if you like.

 db.sql:
 create table users(id integer primary key, name varchar(30));

 file.d:

 // parse out that create table to map the names and types automatically
 alias DataObjectFromSqlCreateTable!(import("db.sql"), "users") User;

 User a;

 a.id = "12"; // type mismatch, fails to compile
 a.name = "hello"; // works
 a.nmae = "sad" // typo caught at compile time

 a.commitChanges(); // otherwise it is still based on DataObject



 In short, I have the best of both worlds, with the only extra effort
 being writing to!() here and there and that one line to import the
 sql definition.


 3) HTML

 I *want* strict typing when working with html in almost all cases.
 It helps catch encoding bugs.

 The one place where I want dynamics - fetching an element off
 the html template - I have it, this time provided through classes.

 auto table = cast(Table) document.getElementById("data-table");
 assert(table !is null); // fails if it isn't a<table>  tag

 // use the table class's special functions


 Forms, Links, and other types of nodes are handled similarly. The
 Element base class though does most the simple operations. Being
 plain old inheritance, the virtual functions act dynamically
 enough.

 Of course, if the HTML changes, that assert/enforce will trigger
 at run time. We're still ahead of dynamic languages though: the
 compiler will tell me what breaks if I remove the cast, with one
 exception: I use an opDispatch there for attributes. That will
 break some functions.

 Table t = ...;

 t.caption = "Hello!"; // changes the<caption>  tag child

 Element t = ...;

 t.caption = "Hello!"; // sets a caption="" attribute


 But meh, in this case, I like the flexibility of accessing
 attributes like that. The compiler still catches more than it
 doesn't - we're still ahead of the mistakes possible in dynamic
 languages while keeping the convenience.


 4) External services


 This is where dynamic types are the most useful. Accessing Facebook,
 Twitter, etc., returns xml or json with types that change based
 on a lot of things. Is the user logged in? What url is it?

 In this case, it's like the database, but the types tend to be more
 complex. Simple string cowboying won't cut it.

 Thankfully, D's Variant is up to the task.


 Variant userRet = fbGraph(token, "/me");

 // we know /me returns a json object from the docs, so fetch it:

 auto user = userRet.get(Variant[string]);

 auto name = user["name"].get!string;

 // name is a string == "Adam D. Ruppe"


 Not terribly hard. Robert Jacques IIRC has written an improved
 std.json patch to make this work almost just like Javascript:

 auto user = fbGraph(token, "/me");

 user.name.get!string; // same as above


 So D's definitely up to the job. The only difference is that final
 use of get!string. I believe Phobos' to! works as well.

As I said above, I don't see the big advantage if I have to use Variants all over the place .
 In the end, there's nothing web related in my experience that a
 dynamic language can do that D can't do almost or just as well,
 and plenty that D and it's static types can do that dynamic types
 can't do, or require piles of painful tests and manually written
 code or documentation to do.


 D kicks the Web's ass. (And my web related libraries go even further
 than seen here. My custom DOM offers a lot of things that are way
 cool, enabling new CSS stuff, filling forms easily, in about 1/10
 the code of doing it similarly in PHP, and without mucking up the
 HTML. The web api/site generator makes D accessible through urls,
 forms, javascript - view the source here for a glimpse of that
 lib:
 http://arsdnet.net/cgi-bin/apidemo/javascript

 20 kb of javascript, including the auto generated API bindings!

 And more stuff is packed in there too. Best of all: D, through
 CGI, consistently does well or better than mod_php in my speed
 benchmarks. I've barely tried to optimize too; there's a lot of
 untapped potential.


 If your host doesn't suck, dive into D on the web. You won't want
 to go back.)

I don't know what your experiences are but since you mention PHP a lot I can agree with you, PHP sucks. Compared to PHP you can do a lot better, also with a dynamically typed language. Actually all the "native" languages in web development (HTML, CSS, JavaScript) are quite horrible. I don't know if it's just me but I try to hide those native languages as much as possible. I'm currently now uses Ruby on Rails with the following languages: * Ruby as the server side script (obviously) * HAML, generates HTML - http://haml-lang.com/ * SASS, generates CSS - http://sass-lang.com/ (I'm using the sass syntax and not the scss syntax) * CoffeeScript, generates JavaScript - http://jashkenas.github.com/coffee-script/ Every language is compiled to its native format automatically when needed and cached in production. I just tried Rails 3.1 beta yesterday and now SASS and CoffeeScript are default. I think these languages make web development a less of a pain, but in the end they all compile to their native languages and there is no way to get away from that. -- /Jacob Carlborg
May 15 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Jacob Carlborg wrote:
 But that way you would need to declare different types of Options
 structs all over the place?

Sometimes, but most functions are fine with regular argument lists, to me, using enums for options where appropriate.
 I think there are other languages available that is far better than
 PHP that you could compare with instead. Ruby on Rails:

Come to think to fit, PHP's $_REQUEST() would have worked here too and shaved off a couple lines. Anyway, I've used Ruby before, but never Rails. The to_i and to_s things are familiar.. me forgetting to write them caused many problems in that project. I hate dynamic languages so much. That Ruby project is what put the nail in the coffin. I want to get an idea of how Rails works though, so see how well my approaches stack up. But, aside from discussions like this one, I haven't had a chance to get into it.
 This will try to find a Post with the given id and automatically
 converted the given value to an integer.

This is similar to how my database libs work. It actually lets the database do the conversion though.
 I've been thinking for a while to try and create something
 similar as Rails' ActiveRecrod for D but every time I tried to do
 it turns out to work quite badly with a static type system.

Have you seen Piotr Szturmaj's Postgres code? http://www.digitalmars.com/d/archives/digitalmars/D/learn/D2_postgresql_interface_-_Phobos2_23693.html#N23695 (there's more posts than that on it too if you search) It might give you some ideas. I went the other way; I don't mind writing SQL. (I always find automatic mappings the other way to be inefficient and lacking anyway.)
 As I said above, I don't see the big advantage if I have to use
 Variants all over the place .

The thing is it's not *all* over the place. There's a small area where you use them, and you get the static type benefits everywhere else. Even with the variant areas, the static type system helps a little bit. At least misspelled variable names are caught ahead of time by the compiler.
 HAML, generates HTML - http://haml-lang.com/

Syntax and indenting aside, concepturally, that's similar to how my DOM based code works. auto profile = holder.addChild("div").className("profile"); auto left = profile.addChild("div").className("left column"); left.addChild("div", print_date).id("date"); left.addChild("div", current_user.address).id("address"); One big difference, semantically, is my code always escapes HTML by default. Looks like haml uses &= for escaping, while = does not.... so their homepage example is both incorrect and open to XSS attacks! (I offer two ways to write HTML: some functions take arguments of type Html, like Table.appendRow: table.appendRow("&nbsp;", Html("&nbsp;")); First column appears as literally &nbsp;. Second column shows up as a non breaking space. But, mostly, if you want to mess with html, you use the innerHTML property. It's a pain to use because outputting HTML is, 9 times out of 10, wrong. Any template system that doesn't do this gets a big point against it in my book, similarly to any database library that makes mixing unescaped text in the easiest way...) Anyway, their syntax is certainly brief. I can see the appeal in that. Curious though, how does haml handle forms? Looking through the documentation, it doesn't seem to at all. This is one of the nicest things about my DOM approach. You can write the form in standard HTML, with default values written there if you want, and the code will fill it in later.
 * SASS, generates CSS - http://sass-lang.com/ (I'm using the sass
 syntax and not the scss syntax)

Heh, I looked at that not long ago. I'm annoyed by CSS's lack of nesting. Not annoyed enough to introduce Ruby to the project, although I rather like what they did here. I'll probably spin my own version eventually.
 * CoffeeScript, generates JavaScript -

Eh, I thought about something along these lines, write some of it, but I decided against going far with it. There's two reasons: a) If you're writing enough Javascript to make using a replacement worth it, you're writing too much Javascript. b) Javascript's biggest problem is that it's loosely and dynamically typed, not that it's whitespace is ignored. The auto-generated javascript to access my D code make using it almost easy anyway http://arsdnet.net/cgi-bin/apidemo/javascript <button onclick=" CoolApi.getABox('green').appendTo('playground'); " type="button">Get a green box</button> Those are all basic examples. The idea is the server does most the work, and Javascript simply plugs it in somewhere in the document - the same way the page is built on the server side. appendTo's argument can be a string for a trivial ID or an element as returned by any of the built in browser functions (such as querySelector - no need to load up a big piece of shit like jQuery to have that.) The generic get() function does partial application so it's reusable with other functions: function fadeIn(parent, speed, html) { ... } CoolApi.getABox('green').get(fadeIn, this.parentNode, 10); Since the server might return data, such might not always work. That's where the format modifier comes in: CoolApi.getPeople(0).format('table').get(fadeIn, this.parentNode, 10); Thus, javascript functions become fairly trivial and/or reusable, so you don't have to deal with the language very much at all. I also toyed with generating Javascript from D: auto js = new ClientSideScript(); js.alert("Hello, world!"); js.var("wat") = 10; js.alert(js.wat); That kind of thing. Each method call to the js object builds a code string inside it. D variables passed as arguments are converted to Javascript literals and added to the code. It actually kinda works, and I use it from time to time, but only for little things. For the big, I don't think it's worth it.
May 15 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-15 19:15, Adam D. Ruppe wrote:
 Jacob Carlborg wrote:
 But that way you would need to declare different types of Options
 structs all over the place?

Sometimes, but most functions are fine with regular argument lists, to me, using enums for options where appropriate.

In Rails basically every view helper function takes two hashes of options, one related to the function and one for html attributes.
 I think there are other languages available that is far better than
 PHP that you could compare with instead. Ruby on Rails:

Come to think to fit, PHP's $_REQUEST() would have worked here too and shaved off a couple lines. Anyway, I've used Ruby before, but never Rails. The to_i and to_s things are familiar.. me forgetting to write them caused many problems in that project. I hate dynamic languages so much. That Ruby project is what put the nail in the coffin. I want to get an idea of how Rails works though, so see how well my approaches stack up. But, aside from discussions like this one, I haven't had a chance to get into it.

I think you really should give it a try. This is a good place to start: http://guides.rubyonrails.org/
 This will try to find a Post with the given id and automatically
 converted the given value to an integer.

This is similar to how my database libs work. It actually lets the database do the conversion though.

I don't know if it's rails or the database that does the conversion.
 I've been thinking for a while to try and create something
 similar as Rails' ActiveRecrod for D but every time I tried to do
 it turns out to work quite badly with a static type system.

Have you seen Piotr Szturmaj's Postgres code? http://www.digitalmars.com/d/archives/digitalmars/D/learn/D2_postgresql_interface_-_Phobos2_23693.html#N23695 (there's more posts than that on it too if you search) It might give you some ideas.

I probably have seen that post but since you have to manually specify the columns in a table I didn't like it.
 I went the other way; I don't mind writing SQL. (I always find
 automatic mappings the other way to be inefficient and lacking
 anyway.)

I really like how it works in Rails.
 As I said above, I don't see the big advantage if I have to use
 Variants all over the place .

The thing is it's not *all* over the place. There's a small area where you use them, and you get the static type benefits everywhere else. Even with the variant areas, the static type system helps a little bit. At least misspelled variable names are caught ahead of time by the compiler.

I guess you're right.
 HAML, generates HTML - http://haml-lang.com/

Syntax and indenting aside, concepturally, that's similar to how my DOM based code works. auto profile = holder.addChild("div").className("profile"); auto left = profile.addChild("div").className("left column"); left.addChild("div", print_date).id("date"); left.addChild("div", current_user.address).id("address");

Don't know why but I think this is verbose and it's more difficult to visualize how the HTML will look like.
 One big difference, semantically, is my code always escapes HTML
 by default. Looks like haml uses&= for escaping, while = does
 not.... so their homepage example is both incorrect and
 open to XSS attacks!

That depends on how it's configured. In addition to that Rails provides functions for escaping.
 (I offer two ways to write HTML: some functions take arguments
 of type Html, like Table.appendRow:

 table.appendRow("&nbsp;", Html("&nbsp;"));

 First column appears as literally&nbsp;. Second column shows up
 as a non breaking space.


 But, mostly, if you want to mess with html, you use the innerHTML
 property. It's a pain to use because outputting HTML is, 9 times
 out of 10, wrong. Any template system that doesn't do this gets
 a big point against it in my book, similarly to any database
 library that makes mixing unescaped text in the easiest way...)



 Anyway, their syntax is certainly brief. I can see the appeal in
 that.


 Curious though, how does haml handle forms? Looking through the
 documentation, it doesn't seem to at all.

With %from like it handles any other HTML tag ...
 This is one of the nicest things about my DOM approach. You can
 write the form in standard HTML, with default values written there
 if you want, and the code will fill it in later.

... but usually you use the "form_for" or "form_tag" helper that Rails provides: = form_for post do |f| = f.label :title = f.text_field :title In the above example :title have to be a column in the Post model. If the post instance has a title the text field will have the title as its value. There's also a plugin called "formtastic" that should make it even simpler (although I've never used it): https://github.com/justinfrench/formtastic
 * SASS, generates CSS - http://sass-lang.com/ (I'm using the sass
 syntax and not the scss syntax)

Heh, I looked at that not long ago. I'm annoyed by CSS's lack of nesting. Not annoyed enough to introduce Ruby to the project, although I rather like what they did here. I'll probably spin my own version eventually.

Then I think you should checkout LESS: http://lesscss.org/ Basically the same thing as SASS but without the Ruby dependency.
 * CoffeeScript, generates JavaScript -

Eh, I thought about something along these lines, write some of it, but I decided against going far with it. There's two reasons: a) If you're writing enough Javascript to make using a replacement worth it, you're writing too much Javascript.

I use coffeescript at work where we use the jqgrid library. It's basically a fancy table with inline editing, and it can do a whole bunch of other things as well. I have around 450 lines of coffeescript to control the grid the way we want to have it. We use a lot of custom cell views and cell formatters.
 b) Javascript's biggest problem is that it's loosely and dynamically
 typed, not that it's whitespace is ignored.

Well, I don't use CoffeeScript because it uses indentation for scoping. I use it for its other features. I don't know what I like best in CoffeeScript but I think it's the syntax for anonymous functions, just an arrow: ->. Another thing I really like is it's built in support for rebinding the "this" variable. In JavaScript if you use an instance method as a callback to an event function the "this" variable is now no longer the class instance, instead it's the object that raised the event. If you use => instead of -> in CoffeeScript it will rebind the "this" variable back to the instance making it behave all the other languages. It also has a class based object model which is then translated into the prototype model used by javascript.
 The auto-generated javascript to access my D code make using it
 almost easy anyway

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

 <button onclick="
    CoolApi.getABox('green').appendTo('playground');
 " type="button">Get a green box</button>


 Those are all basic examples. The idea is the server does most the
 work, and Javascript simply plugs it in somewhere in the document -
 the same way the page is built on the server side. appendTo's
 argument can be a string for a trivial ID or an element as returned
 by any of the built in browser functions (such as querySelector -
 no need to load up a big piece of shit like jQuery to have that.)

 The generic get() function does partial application so it's reusable
 with other functions:

 function fadeIn(parent, speed, html) { ... }

    CoolApi.getABox('green').get(fadeIn, this.parentNode, 10);


 Since the server might return data, such might not always work.
 That's where the format modifier comes in:

    CoolApi.getPeople(0).format('table').get(fadeIn, this.parentNode, 10);



 Thus, javascript functions become fairly trivial and/or reusable,
 so you don't have to deal with the language very much at all.

Correct me if I'm wrong but that would require a request for bascially every function call? I don't like that, and I don't like the inline javascript.
 I also toyed with generating Javascript from D:

 auto js = new ClientSideScript();

 js.alert("Hello, world!");

 js.var("wat") = 10;

 js.alert(js.wat);


 That kind of thing. Each method call to the js object builds a
 code string inside it. D variables passed as arguments are
 converted to Javascript literals and added to the code.

 It actually kinda works, and I use it from time to time, but
 only for little things. For the big, I don't think it's worth it.

Ok. -- /Jacob Carlborg
May 16 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Jacob Carlborg wrote:
 I think you really should give it a try. This is a good place to start:

Cool, thanks!
 Don't know why but I think this is verbose and it's more difficult
 to visualize how the HTML will look like.

That's also a bizarre example... 9/10 times, my code looks more like: auto list = document.getElementById("items-holder"); foreach(item; items) list.addChild("li", item); than the longer thing. If you want to visualize the html, you usually want to look at the html file, since it contains the majority of the structure.
 but usually you use the "form_for" or "form_tag" helper that
 Rails provides:

That's not bad.
 Another thing I really like is it's built in support for
 rebinding the "this" variable

That's easy in Javascript too. It has the Function.apply method built in that makes it as simple as writing a higher order function. I find javascript is easier to use if you think of it as a functional language with procedural elements rather than an object oriented one.
 Correct me if I'm wrong but that would require a request for
 bascially every function call?

Most of them, yes (though calls being passed as arguments to other calls are combined0, but keep in mind a HTTP request does *not* have to go to the server! If your server side code gives the appropriate cache headers, the ajax responses are cached too. There's a good chance you have to hit the server anyway for db access too...
 I don't like that, and I don't like the inline javascript.

Inline javascript was done here for convenience. You're free to do it in a separate file just like any other script.
May 16 2011
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
So I'm writing the official PHP library to access my work library.

Just spent 20 minutes trying to figure out why it wasn't working
right.

The problem was ultimately here:

                $rurl .= "?" + $this->getArgString();

See the mistake? Neither did the stupid PHP interpreter. I hate it
so much.
May 13 2011
prev sibling parent reply Nathan <nchriste yahoo.com> writes:
This looks really interesting -- this will be obvious from my question -- I am a
hobbyist programmer interested in D (with most experience in Python).

I can get the first cgi example (not the mixin) to compile and run on an Apache
cgi server.

I cannot get the second, cgi/mixin sample to compile. What is the appropriate
dmd
command line?

If I write the text verbatim and compile as a module "modulename", I get three
errors, one for the function "run" indicating that "cgi" is not defined, did I
mean Cgi.  The other two errors say that "modulename.run" cannot be called with
argument type Cgi and that 0 arguments are expected for function type void --
and
these errors indicate the line number from the arsd/cgi.d module.

I'm sure this is something simple and that I'm not yet understanding mixins and
how to troubleshoot this type of error -- anyone want to point me to the nose on
my face?

Thanks!

Nathan
May 23 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Nathan wrote:
 I cannot get the second, cgi/mixin sample to compile. What is the
 appropriate dmd command line?

First, download my cgi module http://arsdnet.net/dcode/cgi.d Then, in the same directory write this file, hello.d: === import arsd.cgi; void whatever(Cgi cgi) { cgi.write("Hello!"); } mixin GenericMain!(whatever); ==== And use this command line: dmd hello.d cgi.d Make sure you are using a recent dmd2 compiler like 2.053 from here: http://digitalmars.com/d/2.0/changelog.html You should get a program hello that, when run on the command line, outputs this: ===== Cache-Control: private, no-cache="set-cookie" Expires: 0 Pragma: no-cache Content-Type: text/html; charset=utf-8 Hello! ===== Copy it to a cgi enabled directory ( cgi-bin/ is preconfigured on most Apache installs) and you should be able to access it from the web: http://arsdnet.net/cgi-bin/test If it doesn't work, can you copy/paste the errors in here?
May 23 2011
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Also:

" other two errors say that "modulename.run" cannot be called with
argument type Cgi and that 0 arguments are expected for function type void "

When using the generic main mixin, the function you pass must
always take one argument: a Cgi object.

void yourFunctionHere(Cgi cgi) { }

When the mixin is compiled, it expands to something like this:


void main() {
   auto cgi = new Cgi;
   scope(exit) cgi.close();
   try {
        yourFunctionHere(cgi);
   } catch (Exception) {
        // log and maybe display the error then exit
   }
}


So the function you pass to the mixin is called with an argument:

        yourFunctionHere(cgi);


Which might be producing the error you saw, if your function
couldn't take the cgi object as it's own argument.




Why use the mixin at all? Writing main yourself might be simpler.

There's three reasons:

!) It saves you from writing the same thing over and over as your
   main function. This is a small benefit, but it's nice.

2) It can display errors to the browser in debug mode. This makes
   debugging easier. The message is right there.

3) This is the biggest one: if the main() function ever needs to
   change, your code doesn't.

Thanks to the GenericMain mixin, for example, you can switch to
using FastCGI or a built in webserver simply by recompiling with
a different version. None of your code has to change.
May 23 2011
parent Nathan <nchriste yahoo.com> writes:
Adam,

Thanks for the step by step guide.  My problem was exactly what you
outlined, that "yourFunctionHere" did not take Cgi cgi as an argument.
That's all I needed!

I definitely understand the benefit of the mixin -- the overall design
makes a lot of sense.

Nathan





On Mon, 23 May 2011 16:57:06 +0000 (UTC), Adam D. Ruppe
<destructionator gmail.com> wrote:

Also:

" other two errors say that "modulename.run" cannot be called with
argument type Cgi and that 0 arguments are expected for function type void "

When using the generic main mixin, the function you pass must
always take one argument: a Cgi object.

void yourFunctionHere(Cgi cgi) { }

When the mixin is compiled, it expands to something like this:


void main() {
   auto cgi = new Cgi;
   scope(exit) cgi.close();
   try {
        yourFunctionHere(cgi);
   } catch (Exception) {
        // log and maybe display the error then exit
   }
}


So the function you pass to the mixin is called with an argument:

        yourFunctionHere(cgi);


Which might be producing the error you saw, if your function
couldn't take the cgi object as it's own argument.




Why use the mixin at all? Writing main yourself might be simpler.

There's three reasons:

!) It saves you from writing the same thing over and over as your
   main function. This is a small benefit, but it's nice.

2) It can display errors to the browser in debug mode. This makes
   debugging easier. The message is right there.

3) This is the biggest one: if the main() function ever needs to
   change, your code doesn't.

Thanks to the GenericMain mixin, for example, you can switch to
using FastCGI or a built in webserver simply by recompiling with
a different version. None of your code has to change.

May 24 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Matthew Ong" <ongbp yahoo.com> wrote in message 
news:iqgo17$2nqv$1 digitalmars.com...
 Hi Adam,

 Thanks again for the sharp pointed answer.
 What is the counterpart in D for replacing JSP/ASP/JRuby on Rail or
 some sort of dynamic web base development?

I use D for web work by using the standard CGI interface and >sometimes
an embedded http server. It's the best thing I've ever used.

D?
 How to also code digitally sign the DLL  that was compiled in D?

So we use external tool to do that and not a build in one?? In java, we use jarsigner with some keygen. Please bear in mind I am new to D.

Here's a basic "Hello world" CGI app in D: // hellocgi.d import std.conv; import std.stdio; void main() { // Read in HTTP request headers string[] requestHeaders; while(true) { string line = readln(); if(line.length <= 1) break; requestHeaders ~= line; } // Send response headers writeln("Status: 200 OK"); writeln("Content-Type: text/html; charset=UTF-8"); writeln(); // Send content writeln("<b><i>Hello world</i></b>"); } Compile with: dmd hellocgi.d And just stick the resulting "hellocgi.exe" (windows) or "hellocgi" (other) in whatever "cgi-bin"-capable directory you have on your server. Everything else (such as fancy CGI libraries/frameworks like Adam's) can ultimately be built out of that basic idea. Keep in mind though, that since D is natively compiled, you'll have to compile it on either the same OS and CPU architecture as your server, or an OS/CPU that's compatible with your server. (This would be true of C/C++ as well.) I'm sure it's possible to make an ISAPI filter or Apache module in D, but I've never really done that in any langauge, and I haven't really dealt with DLLs much, so I wouldn't know how. But even as CGI, a web app in D is likely to still be much faster than one in, for instance, PHP or Ruby.
May 12 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
    // Read in HTTP request headers

Actually, that's not quite right. The HTTP headers are sent as environment variables. stdin gives you the POST variables - with the encoding given in the HTTP_CONTENT_TYPE envvar iirc. (that's where the Content-Type http header is found). The most common type is urlencoded, so it's just like parsing the query string. The other one I handle is multipart - the encoding for file upload forms. Getting all that stuff out is the main benefit of a basic cgi library.. it's a bit of a pain to do yourself every time.
May 12 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam Ruppe" <destructionator gmail.com> wrote in message 
news:iqhha9$17dp$1 digitalmars.com...
    // Read in HTTP request headers

Actually, that's not quite right. The HTTP headers are sent as environment variables. stdin gives you the POST variables - with the encoding given in the HTTP_CONTENT_TYPE envvar iirc. (that's where the Content-Type http header is found).

Ugh. Apperently, too much Flash/PHP/HTML/etc has rotted my mind...
May 12 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
 Ugh. Apperently, too much Flash/PHP/HTML/etc has rotted my mind...

Speaking of brain rot, the first version of my cgi.d actually aimed to mimic PHP! Some stupid part of me actually started to *like* the superglobals for a while... It had a static module constructor that built the arrays, and gave them global names like PHP does: import cgi; void main() { auto my_var = _POST["my_var"]; // works in D } It even simulated PHP's session_start() thing, though bugs in std.variant kept it from being particularly useful at the time. While std.variant is now fixed, I haven't had a need for sessions like that, so never updated that to the new module. For some reason, I actually liked it at the time. But, it broke down when I decided to write my own little http server to avoid Apache bloat for an app. A shared, mutable global is obviously nasty there. (I did stick with it for a while, but it got so complicated I ditched the whole stupid thing and started over, writing the new class based cgi.d. If you look at my code though, you'll see a couple things that are very bizarre according to the CGI standard: these are the things that let it work with the embedded httpd too. It reads all headers itself and writes the raw protocol to sockets instead of stdout when constructed that way. Thus, aside from the constructor arguments, the rest of the client code looks the same, so I can switch from embedded to apache/iis and back easily enough. The functions being mixin GenericMain!() instead of main() is also due to this, though the try/catch it provides is nice too.) Anywho. Another bad experience with PHP led me to make the get and post vars in cgi.d completely immutable - something that leads to some pain, since phobos and druntime don't care much for immutable(char[])'s (instead opting to work with immutable(char)[]'s. This has gotten worse in the new beta with even the replace() function no longer working on the former! Ugh!) But, some minor hacks here and there make it work, so yay. And, unlike PHP, if some asshole decides to write $_POST["evil"] = $whatever; in his vile function, I won't have to deal with it later! Whoo hoo!
May 12 2011
parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:iqhkdn$1co1$1 digitalmars.com...
 Ugh. Apperently, too much Flash/PHP/HTML/etc has rotted my mind...

Speaking of brain rot, the first version of my cgi.d actually aimed to mimic PHP! Some stupid part of me actually started to *like* the superglobals for a while...

Heh. Well they are at least convenient. I'm sure that's probably why PHP did it in the first place.
 It had a static module constructor that built the arrays, and gave
 them global names like PHP does:

 import cgi;

 void main() {
     auto my_var = _POST["my_var"]; // works in D
 }

 It even simulated PHP's session_start() thing, though bugs in
 std.variant kept it from being particularly useful at the time.
 While std.variant is now fixed, I haven't had a need for sessions
 like that, so never updated that to the new module.

I don't know how yours works, but PHP's session system has a number a pains. The whole way it handles session timeouts is just bizarre, and the fact that it's even possible for the sysadmin to enable session.auto_start has caused me big headaches. Actually, that get's into one of the big things I hate about PHP: there's far too much it allows sysadmins to fuck with. And it's not always possible for the programmer to override dumb php.ini settings. As a result, even a single specific point release of PHP is essentially 5 million different languages, depending what server you're on and your sysadmin's day-to-day whims. And a lot of the settings are just stupid features that never should have been put in in the first place (granted, those ones tend to become deprocated, but by then the damage is already done). Which reminds me of the PHP4->PHP5 debacle. I can certainly appreciate the occasional need for changes that break backwards-compatibility (especially as a D user), so I don't have a problem per se with the fact that PHP5 broke backwards compatibility (although it's not like compatibility in PHP has ever been anything but a joke). But there are so many ways it would have been so trivial to avoid the problems it caused. Probably the simplest and most obvious would be a decree "Scripts targeting PHP5 and up must end with the extension .php5, otherwise it will either refuse to run or get sent to a PHP4 installation if available." Or instead of the extension, require the first line to be "<?php PHP5...", etc. So many easy ways to avoid the problems they had. And that's all just off the top of my head. But PHP's primary design principle seems to be "Be sloppy whenever possible." Of course, D2 broke backards compatibility with D1 and doesn't have anything like what I suggested above for PHP5. But it works for D because the language exists completely on the development side, not on the server side like PHP.
 For some reason, I actually liked it at the time. But, it broke
 down when I decided to write my own little http server to avoid
 Apache bloat for an app.

Cool :) It's amazing how simple a basic http server is. Yea, there's some details and gotchas to be careful of if you're really trying to follow the HTTP1.1 spec properly (which is probably a good idea anyway). But even still, someone who's never written a server would probably think it would need to be some major Apache-level undertaking. That's what I originally thought. But unless you're really going for super-flexibility/configurability/bells-and-whistles, etc., you really don't need 99% of that, and it actually ends up being pretty simple. ...Unless you want to run it on a shared web host. Then you're just plain shit-out-of-luck ;)
 A shared, mutable global is obviously
 nasty there.

 (I did stick with it for a while, but it got so complicated I
 ditched the whole stupid thing and started over, writing the
 new class based cgi.d. If you look at my code though, you'll see
 a couple things that are very bizarre according to the CGI standard:
 these are the things that let it work with the embedded httpd too.
 It reads all headers itself and writes the raw protocol to sockets
 instead of stdout when constructed that way. Thus, aside from the
 constructor arguments, the rest of the client code looks the same,
 so I can switch from embedded to apache/iis and back easily enough.

That's pretty cool.
 The functions being mixin GenericMain!() instead of main() is also
 due to this, though the try/catch it provides is nice too.)


 Anywho.

 Another bad experience with PHP led me to make the get and post
 vars in cgi.d completely immutable - something that leads to
 some pain, since phobos and druntime don't care much for
 immutable(char[])'s (instead opting to work with
 immutable(char)[]'s. This has gotten worse in the new beta with
 even the replace() function no longer working on the former! Ugh!)

 But, some minor hacks here and there make it work, so yay.

 And, unlike PHP, if some asshole decides to write $_POST["evil"] =
 $whatever; in his vile function, I won't have to deal with it later!
 Whoo hoo!

Yea, D kicks the snot out of PHP in so many ways. It's so unfortunate though that shared web hosts have SOOO much better support for PHP than native-compiled CGI. I suppose one could argue that's for security and reliability reasons, but PHP's known for being terrible in those areas, too. *shrug* Just a popularity thing I guess...It annoys me to no end that the computer world has become every bit as trend-driven as the high-fasion industry...I guess that's what happens when you let middle managers in on things.
May 12 2011
prev sibling parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/13/2011 4:01 AM, Nick Sabalausky wrote:
 "Matthew Ong"<ongbp yahoo.com>  wrote in message
 news:iqgo17$2nqv$1 digitalmars.com...
 Hi Adam,

 Thanks again for the sharp pointed answer.
 What is the counterpart in D for replacing JSP/ASP/JRuby on Rail or
 some sort of dynamic web base development?

 I use D for web work by using the standard CGI interface and>sometimes
 an embedded http server. It's the best thing I've ever used.

D?
 How to also code digitally sign the DLL  that was compiled in D?

So we use external tool to do that and not a build in one?? In java, we use jarsigner with some keygen. Please bear in mind I am new to D.

Here's a basic "Hello world" CGI app in D: // hellocgi.d import std.conv; import std.stdio; void main()

of the publicity done my M$ and others also. When they pushed for ASP/JSP...
 {
      // Read in HTTP request headers
      string[] requestHeaders;
      while(true)
      {
          string line = readln();
          if(line.length<= 1)
              break;

          requestHeaders ~= line;
      }

      // Send response headers
      writeln("Status: 200 OK");
      writeln("Content-Type: text/html; charset=UTF-8");
      writeln();

      // Send content
      writeln("<b><i>Hello world</i></b>");
 }

 Compile with:
 dmd hellocgi.d

 And just stick the resulting "hellocgi.exe" (windows) or "hellocgi" (other)
 in whatever "cgi-bin"-capable directory you have on your server.

 Everything else (such as fancy CGI libraries/frameworks like Adam's) can
 ultimately be built out of that basic idea.

 Keep in mind though, that since D is natively compiled, you'll have to
 compile it on either the same OS and CPU architecture as your server, or an
 OS/CPU that's compatible with your server. (This would be true of C/C++ as
 well.)

 I'm sure it's possible to make an ISAPI filter or Apache module in D, but
 I've never really done that in any langauge, and I haven't really dealt with
 DLLs much, so I wouldn't know how. But even as CGI, a web app in D is likely
 to still be much faster than one in, for instance, PHP or Ruby.

security concern published and accepted as minimum by the industry for MNC. -- Matthew Ong email: ongbp yahoo.com
May 19 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
 Hmm...Might be problem for it to be main... Security concerned
 because of the publicity done my M$ and others also. When they
 pushed for ASP/JSP...

That's such backward nonsense I find it hard to believe anyone would seriously believe it.
May 19 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Matthew Ong" <ongbp yahoo.com> wrote in message 
news:ir3anp$dgj$1 digitalmars.com...
 On 5/13/2011 4:01 AM, Nick Sabalausky wrote:
 Here's a basic "Hello world" CGI app in D:

 // hellocgi.d
 import std.conv;
 import std.stdio;

 void main()

the publicity done my M$ and others also. When they pushed for ASP/JSP...

What's wrong with it? This is the first I've heard of any such issue.
 {
      // Read in HTTP request headers
      string[] requestHeaders;
      while(true)
      {
          string line = readln();
          if(line.length<= 1)
              break;

          requestHeaders ~= line;
      }

      // Send response headers
      writeln("Status: 200 OK");
      writeln("Content-Type: text/html; charset=UTF-8");
      writeln();

      // Send content
      writeln("<b><i>Hello world</i></b>");
 }

 Compile with:
 dmd hellocgi.d

 And just stick the resulting "hellocgi.exe" (windows) or "hellocgi" 
 (other)
 in whatever "cgi-bin"-capable directory you have on your server.


Actually, like Adam pointed out, I got the HTTP request headers part completely wrong. HTTP headers come from environment variables, and stdin is just used for any data that's been posted. So that part's totally wrong. So you'll want to just rip that part out like this: // hellocgi.d import std.conv; import std.stdio; void main() { // Send response headers writeln("Status: 200 OK"); writeln("Content-Type: text/html; charset=UTF-8"); writeln(); // Send content writeln("<b><i>Hello world</i></b>"); }
 I'm sure it's possible to make an ISAPI filter or Apache module in D, but
 I've never really done that in any langauge, and I haven't really dealt 
 with
 DLLs much, so I wouldn't know how. But even as CGI, a web app in D is 
 likely
 to still be much faster than one in, for instance, PHP or Ruby.

security concern published and accepted as minimum by the industry for MNC.

First I've heard of it. What's the problem?
May 19 2011