D For A Web Developer

[Rikki Cattermole via Digitalmars-d]

On Wednesday, 30 April 2014 at 04:12:59 UTC, Adam D. Ruppe wrote:
> On Wednesday, 30 April 2014 at 03:20:16 UTC, Rikki Cattermole 
> wrote:
>> We should probably work together on this sort of stuff! As we 
>> seem to have similar ideas
>
> Yea, I wrote my version several years ago (IIRC 2009 or early 
> 2010) and since then D has grown as has my knowledge of it. I 
> kinda want to write a web.d 2.0 that cleans everything up but 
> eh I have a lot of things I want to do and web.d 1.0 works so 
> no big rush.
>
> The 1.0 has a lot of cool stuff though, like it can avoid JS 
> calls by referencing the result of another function in the URL, 
> all pretty transparently. So like if you wrote, in JS:
>
> Foo.add(Foo.add(1,2), 3).get(alert), it should only result in 
> one HTTP request. The proxy object when used as an argument 
> just emits an indirect reference through magic URL params. 
> Kinda cool, though it doesn't go as far as I'd like.
>
>
> Among what I'd like to clean in web.d 2.0:
>
> web.d supports what it calls "ApiObjects", which map to RESTful 
> uris:
>
> class Poo : ApiObject {
>    this(ApiProvider parent, string identifier) {}
>    auto GET() { }
>    auto POST() {} // etc
>    auto bar() {}
> }
>
> If you went to:
>
> /Poo/cool-beans
>
> it would call (new Poo(parent, "cool-beans")).GET(). Then 
> /Poo/a/bar calls new Poo("a").bar and so on.
>
> The problem is this is really reliant on things like the ending 
> slash, and it issues redirects to force it to be there or not 
> be there.
>
> The implementation is also kinda buggy in general, it is 
> supposed to beautifully nest, but it only kinda does. Getting 
> an index of all things also doesn't work quite right, you have 
> to write a separate method for that.
>
> So I'd like to clean all that up and actually design it instead 
> of growing on cool hacks as they come to mind.
>
> Nested ApiProviders don't work exactly right either. They are 
> supposed to do a chain of magic:
>
> class Foo : ApiProvider { auto whatever() {} }
> class Bar : ApiProvider {
>    alias Foo foo;
> }
>
> Then, /foo/whatever does (new Foo((new Bar))).whatever. That 
> part works. The things is each class can also provide a 
> postProcess method to modify the document after it is 
> generated. That's *supposed* hit everything, but sometimes it 
> doesn't, I think it only works two levels deep right now, 
> really hairy implementation.
>
> The other problem is the Javascript generator doesn't really 
> understand nesting. Ideally, nested ApiProviders are made 
> available through dots and nested ApiObjects are workable 
> through JS proxy objects.
>
> This looks like what you managed to do so that's cool.
>
>
> I also need to clean up the reflection generation to make it 
> easier to use and make path info accessible outside just the 
> automatic routing (or the low level Cgi.pathInfo which doesn't 
> tell you where it starts!).
>
> Reflection should be generated once upon startup then reused 
> forever as an immutable object. Currently, reflection is 
> partially regenerated on each request - eek.
>
>
> I also wrote a _register*Processor family fairly recently (like 
> December 2012) that kinda obviates the old postProcess and back 
> in January this year, changed the session to put it all in 
> cookies instead of files. That stuff is awesome, so much better 
> than the old way. Should consider doing them from the ground up 
> now!
>
> (Also, ironically, I was a big pusher for UDAs for web.d... but 
> I barely actually used them after they were made available. I 
> really wanted to put them on parameters tho, otherwise 
> convention over configuration is kinda how i play it LOLOL)
>
>
>
> oh yeah and it could be documented somewhere other than my 
> brain, the sloppy source, and random forum posts so ppl can 
> know about it all. but meh.
>
> All that said, it manages to get the job done for me so I'm not 
> in a huge rush to actually fix any of it.

It does look like web.d was a bit of a precursor to Cmsed 
(unintentionally) strangely enough.
Although I definitely would like to hear more about asynchronous 
javascript instead of my synchronous based code and how I can 
combine it at some point.