Nick Sabalausky wrote:
> (Not sure why IIS changes the redirect's "/" to "localstart.asp",
> probably just IIS trying to be "smart", but I usually only use IIS > locally, so
I don't really care right now).

It's possible I messed up... the line of code is specifically:

        cgi.setResponseLocation(cgi.requestUri ~ "/");

which is supposed add the slash. But maybe my requestUri member
is wrong on IIS, so it saw just the slash, and that redirected to the
other thing.


Hmmmm, a quick web search tells me that IIS doesn't set REQUEST_URI the same way as Apache, so this is probably a bug in cgi.d. I thought that was a standard, but it looks like it might be an Apache extension.

Huh, I've gotta think about this.

> Oh, one other thing I noticed: With DMD 2.054 banning implicit switch/case fallthrough, it pointed out an implicit fallthrough in dom.d at line 2641

That's interesting... I updated my dmd but didn't see this....

but yes that's definitely a bug, also in my copy of the code. Add a break to it.

You might want to grab a new copy of dom.d. I think your copy is pretty old in general, since that line number is a few hundred lines different than my copy.

http://arsdnet.net/dcode/dom.d

The newer one has stuff like requireSelector and requireElementById that we discussed a while ago, among other things.

(that dcode folder is updated on random whims. I do changes for myself in another location then copy it over usually when I talk about it on the newsgroup.)


Anywho.

That's embarrassing... every time bearophile mentions fallthrough, I defend it - it's sometimes useful and besides, those bugs *never* happen to *me*.

Blargh.


(the reason I didn't catch this before is that case is a private extension to CSS' selector, that I very, very rarely use, and nobody else uses it either, since it's nonstandard, so it hasn't been caught in my little browser I'm writing with this either.)

Let me list some of the newer features in web.d too, added in the last couple weeks.

class ApiObject;

These let you expose a more object oriented interface to your stuff on the url.

====
class User : ApiObject {
   this(Foo foo, string id) {}
}

class Foo : ApiProvider {
   alias User user;
}
=====

Now, when the user goes to:

yoursite.com/yourapp/user/username

It instantiates one of those User classes, passing "username" as the second argument to the constructor.

Then, you can add methods to your ApiObject and call them with additional slashes on the url. Or, you can put in methods with the name of an HTTP operation to apply straight to it.

string GET() { return "my name"; }

Now the url above works, running this GET() method. Or, you can
issue HTTP POST to it, and it runs POST() {}. Etc. The return
value is auto-formatted like with any other method.

You can also put in normal methods.

yoursite.com/yourapp/user/username/method

runs

new User(foo, "username").method();



This function is new and not fleshed out totally. The basics work, but the javascript access isn't done yet - only top level procedures are auto generated at this point. Basic reflection is working but not even the sitemap uses it.

Eventually, I want to add proper support for static methods so you can do things like get lists too, without requiring an identifier.

That's another new method in the base class: sitemap. It lists links to your functions. Nothing fancy, but soon I'll change defaultPage to point to it, so creating a simple site is almost fully automated.


Another new thing is you can now add aliases to other ApiProvider children to your main one.

class Admin : ApiProvider { ... }

class Site : ApiProvider { alias Admin admin; }

Now, you can access the members of admin by going to yoursite.com/yourapp/admin/methods...


This lets you separate out modules more easily. While they all need to be aliased into the root apiprovider you provide, they can be implemented in different modules.


It might be a good idea to make your own:

class YourApiProvider : ApiProvider {
 // override some of the methods here for a consistent site...
}

class Site : YourApiProvider {}
class Admin : YourApiProvider {}


Then you can easily have a centralized getDocument and postProcess thing with normal overriding.


I'm considering automating that by making a chain of postProcess calls based on where the aliases appear. Run the inner postprocess first, then the outer one. I haven't decided yet.



You'll notice that I use alias a lot here. You don't strictly have to, but I like to have the implementation easily separated, which alias allows, and for the public name to not always match the internal name (seen here with captialization). So that works too with alias.


Another new thing is _initialize vs _initializePerCall, meant to give more flexibility in a FastCGI situation. Using regular CGI, it doesn't really matter since the process only handles one call anyway.


I think that's everything recent.


Eventually I should write this documentation somewhere other than the newsgroup!

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:ivo1ga$1ete$1@digitalmars.com...
> Nick Sabalausky wrote:
>> (Not sure why IIS changes the redirect's "/" to "localstart.asp", probably just IIS trying to be "smart", but I usually only use IIS > locally, so
> I don't really care right now).
>
> It's possible I messed up... the line of code is specifically:
>
>        cgi.setResponseLocation(cgi.requestUri ~ "/");
>
> which is supposed add the slash. But maybe my requestUri member
> is wrong on IIS, so it saw just the slash, and that redirected to the
> other thing.
>
>
> Hmmmm, a quick web search tells me that IIS doesn't set REQUEST_URI the same way as Apache, so this is probably a bug in cgi.d. I thought that was a standard, but it looks like it might be an Apache extension.
>
> Huh, I've gotta think about this.
>

More detailed information in case it's helpful:

The URL I typed into the browser was:

http://localhost/darticles/articles-debug.exe

According to HttpFox (FF plugin), the headers received were:

HTTP/1.1 302 Object moved
Server: Microsoft-IIS/5.1
Date: Fri, 15 Jul 2011 04:18:56 GMT
X-Powered-By: ASP.NET
Connection: close
Location: localstart.asp
Content-Length: 121
Content-Type: text/html
Cache-Control: private

Note, FWIW, that's a relative path in the "Location". Ie, it's "localstart.asp", not "/localstart.asp", so the browser then goes to http://localhost/darticles/localstart.asp

If I insetad go to http://localhost/darticles/articles-debug.exe/ then it all works right.

Although I guess that probably doesn't help tell you what the CGI app received from IIS...


>> Oh, one other thing I noticed: With DMD 2.054 banning implicit switch/case fallthrough, it pointed out an implicit fallthrough in dom.d at line 2641
>
> That's interesting... I updated my dmd but didn't see this....
>
> but yes that's definitely a bug, also in my copy of the code. Add a break to it.
>
> You might want to grab a new copy of dom.d. I think your copy is pretty old in general, since that line number is a few hundred lines different than my copy.
>
> http://arsdnet.net/dcode/dom.d
>
> The newer one has stuff like requireSelector and requireElementById that we discussed a while ago, among other things.
>

My copy does have requireSelector and requireElementById, but yea, it looks like that latest one does have a lot of new stuff.


> (that dcode folder is updated on random whims. I do changes for myself in another location then copy it over usually when I talk about it on the newsgroup.)
>

Sooo...I don't suppose you've given thought to using Hg/BitBucket or Git/GitHub? ;)

It'd make a lot of things much easier for both you and others using your code.  And it would better facilitate people submitting patches to you. They are an extra tool to learn and use, but they're well worth it.


>
> Anywho.
>
> That's embarrassing... every time bearophile mentions fallthrough, I defend it - it's sometimes useful and besides, those bugs *never* happen to *me*.
>
> Blargh.
>

 :)

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:ivo1ga$1ete$1@digitalmars.com...
> Nick Sabalausky wrote:
>> Oh, one other thing I noticed: With DMD 2.054 banning implicit switch/case fallthrough, it pointed out an implicit fallthrough in dom.d at line 2641
>
> That's interesting... I updated my dmd but didn't see this....
>

I don't remember, but it might have been because I compile with -wi

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:ivo1ga$1ete$1@digitalmars.com...
> Nick Sabalausky wrote:
>> Oh, one other thing I noticed: With DMD 2.054 banning implicit switch/case fallthrough, it pointed out an implicit fallthrough in dom.d at line 2641
>
> That's interesting... I updated my dmd but didn't see this....
>
> but yes that's definitely a bug, also in my copy of the code. Add a break to it.
>

I might have found another one in the new dom.d. Starting at line 3006 it has:

case "visited":
case "active":
case "hover":
case "target":
case "focus":
case "checked":
case "selected":
    current.attributesPresent ~= "nothing";
    // FIXME
/*
// defined in the standard, but I don't implement it
case "not":
*/
/+
// extensions not implemented
//case "text": // takes the text in the element and wraps it in an element,
returning it
+/

case "before":
case "after":
    current.attributesPresent ~= "FIXME";

The "visited"/"selected" case falls through into the "before"/"after" case. Looks like that might not be intended, but I could be wrong...

Nick Sabalausky wrote:
> I might have found another one in the new dom.d. Starting at line 3006 it has:

Nah, that's just not implemented. The reason those cases are there
is the browser app would throw an exception on it (assert(0) I believe)
if it didn't recognize the names, but those are common in real
websites.

So I put the cases in then just some spam.. I was going to do something
with attributes then changed my mind then changed it again... but
regardless none of it actually does anything so it doesn't matter
what it says.


(The difficulty I'm having there is I really want it to throw on not implemented or unknown stuff, but I also want it to be able to handle the kind of pure putrid shit you find on the open internet. Document has a flag to parse() for that - loose vs strict, but the css handler is half used for getElementsBySelector and half garbage so it doesn't have a consistent approach at all.)

Nick Sabalausky wrote:
> Sooo...I don't suppose you've given thought to using Hg/BitBucket or Git/GitHub? ;)
>
> It'd make a lot of things much easier for both you and others using your code.  And it would better facilitate people submitting patches to you. Theyare an extra tool to learn and use, but they're well worth it.

Easier for me is hard to see... right now, I just write files and when I want it shared, I run:

cp dom.d /var/www/htdocs/dcode

And that's all there is to it.. similarly, saving changes is as simple as hitting save in my editor. Revert means hitting undo a bunch of times.


Basically my primitive approach is good enough, so while git (etc.) have some benefits, they aren't enough to overcome my massive inertia.


Now, I do have git installed here and know the basics on how to use it, and Walter and Andrei pushed me into making a github account.

What I hate about github though... SOCIAL CODING. Ugh, I see the
word "social" way way WAY too much! I've come to hate it the way
I hate "secure" and "powerful" - meaningless words added to garbage
so it can be on the bandwagon too!


but meh I did it anyway and it wasn't as painful as I thought to get started:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff



Wait a minute........ the files don't seem to actually be there! And this website is so SLOW!

How annoying.


Meh, I'll come back to it later.


BTW, looking at my comments in web.d... note one thing: most of those are notes to self; it's a todo list of ideas, not necessarily things that actually work.

I just realized I talked about command line access in a comment at the top, but none of that exists in code! It's just there so I don't forget to eventually add it.

I changed my symlinks to hardlinks and it seems to have worked. So that github thingy is up to date now.

Hopefully it will be simple to keep it that way!

"Adam Ruppe" <destructionator@gmail.com> wrote in message news:ivpdoo$rif$1@digitalmars.com...
> Nick Sabalausky wrote:
>> Sooo...I don't suppose you've given thought to using Hg/BitBucket or Git/GitHub? ;)
>>
>> It'd make a lot of things much easier for both you and others using your code.  And it would better facilitate people submitting patches to you. Theyare an extra tool to learn and use, but they're well worth it.
>
> Easier for me is hard to see... right now, I just write files and when I want it shared, I run:
>
> cp dom.d /var/www/htdocs/dcode
>
> And that's all there is to it.. similarly, saving changes is as simple as hitting save in my editor. Revert means hitting undo a bunch of times.
>

Does your undo stack persist after the editor (or the file) is closed? How big is the undo stack? How easy is to undo to a specific working (ie, not "in the middle of a task") state?

Also, doing it that way makes it harder to track down where a regression was introduced.

A point that was a big one for me: What happens when you decide you need to go back and use, or take a look at, some piece of code that you've already deleted?

Another big thing is that it makes it much easier to fold in user-submitted changes. (And you're more likely to actually *get* other people helping out.)

>
> What I hate about github though... SOCIAL CODING. Ugh, I see the word "social" way way WAY too much!

I *completely* agree! Every time I see/hear the word "social" (at least used with an implied positive connotation) it makes my skin crawl.

But then, I hate most people, I've always hated socializing (except for message boards and close friends/family), I hate highly social people, I hate Twitface and people who use it, etc... And, of course, "social" has become just as much of an idiotic, meaningless buzzword as "cloud".

Unfortunately, even as much of a turn-off as "social" is, I have to admit, DVCSes are absolutely fantastic tools, and the collaboration is, admittedly, a very very good aspect. I do wish the sites weren't so damnned slow and JS-heavy, though...Hell, even with JS off, they're insanely slow when viewing code - but I blame HTML/CSS for that...

>
> but meh I did it anyway and it wasn't as painful as I thought to get started:
>
> https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
>
>

Cool :) Nice repo name, btw ;)

BTW, Tip from experience: Save yourself the sanity and never bother trying to deal with hg-git (the thing that supposedly lets you access Git repos from Hg)...

"Adam Ruppe" <destructionator@gmail.com> wrote in message news:ivp9aq$jn4$1@digitalmars.com...
>
> (The difficulty I'm having there is I really want it to throw on not implemented or unknown stuff, but I also want it to be able to handle the kind of pure putrid shit you find on the open internet.

Yea, I've been having to deal with that on a big Haxe project I've been working on. I have a nice spiffy automatic error-reporting system, but it's proven surprisingly hard to find the right balance between what should be reported and what would just be noise.

Speaking of, apparently, HTTP's HEAD command is technically required by the HTTP spec to work right. But my system hasn't been handling it (I didn't even know about it before), and I never had *anyone* actually send such a request. But just recently I started getting one HEAD request every few days from an IP that've traced to Amazon WebSevices, which makes me wonder what the hell someone is even trying to do. The site is a demonstration for a memory-exercise program I've been tech lead on ( www.attentionworkout.com - pardon the annoying parts of the site, like the embedded sound, it was designed to be used in nursing homes ), so I can't imagine what the hell anyone at Amazon WebServices would be doing with it.

But, HEAD is technically required (though I have no idea what the real-world use-cases are), so I'm not quite sure what to do.


> Document has a flag to parse() for that - loose vs strict, but the css handler is half used for getElementsBySelector and half garbage so it doesn't have a consistent approach at all.)