September 19, 2020
On Friday, 18 September 2020 at 22:21:52 UTC, Adam D. Ruppe wrote:
> On Friday, 18 September 2020 at 22:02:07 UTC, aberba wrote:
>> [...]
>
> I actually added *exactly* this to cgi.d in... 2010 if I remember right. I even kinda documented it: http://dpldocs.info/experimental-docs/arsd.cgi.Cgi.UploadedFile.contentInMemory.html
>
> The threshold where it goes to a file is right now 10 MB and not configurable, but I've been meaning to go back and clean up this api a little. The max file size it accepts is configurable <http://dpldocs.info/experimental-docs/arsd.cgi.GenericMain.html> but the threshold where it goes from memory to file is not.
>

This looks promising. How could I forget about arsd. You have something for anything :)

> Though I should note that if vibe is putting it in a temporary file it probably realistically stays in memory anyway.... this whole thing might be about nothing since the OS is pretty good about optimizing temp files.

But if I wanted that sort of "convenience" I would still be using PHP ;)

> Just I have bigger things to take care of right now (or should I say smaller things?!)

:)
September 19, 2020
On Friday, 18 September 2020 at 22:31:09 UTC, mw wrote:
> On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:
>
>> Are there other frameworks besides vibe that can do what I want?
>
> Just FYI, there is also:
>
> https://code.dlang.org/packages/hunt-framework
>
>
> I never used myself, you need to investigate.

Thanks for the link, I will have a look.
September 19, 2020
On 9/19/20 7:15 AM, ikod wrote:
> On Saturday, 19 September 2020 at 11:11:21 UTC, ikod wrote:
>> On Friday, 18 September 2020 at 13:13:16 UTC, wjoe wrote:
>>> On Friday, 18 September 2020 at 12:58:29 UTC, Steven Schveighoffer wrote:
>>>> On 9/18/20 8:39 AM, Steven Schveighoffer wrote:
>>>>> But again, solved with an enhancement that allows you to process the data in your code. I'll file the enhancement request for you, as I think it's a nice addition.
>>>>
>>>> https://github.com/vibe-d/vibe.d/issues/2478
>>>>
>>>
>>> Awesome! Thanks a ton :)
>>
>> My preferable way to handle such thing is: convert incoming data into input range of immutable(ubyte)[] and let user to consume this range (and handle it as it wish - transform, store in memory as is, or dump to disk)
> 
> sorry, this looks exactly like it described in proposal (and this is how requests works).
> 

You mean for each file, right? Yeah, that is the proposal, though it uses Vibe's io type (necessary I think).

-Steve
September 19, 2020
On 9/19/20 6:59 AM, wjoe wrote:
> Handling file uploads is one example, another is command line arguments.
> The presumption here is there is vibe and there can only be vibe. It takes them from Runtime.args. Duh?
> This didn't make sense to me until I saw example where the initialization of vibe was done in a module constructor.

This used to be the expected way to set up vibe (using module constructors). And vibe would provide its own main function.

I *think* the idea was to allow registration of different handlers in their respective modules.

Nowadays, you just run the setup wherever you want (I do everything in main).

> By using vibe I feel like I need to bend myself like a snake and jump through the hoops of vibe's one way to do it. You save a lot of time here and there and then you lose half a day because of some stupid road block like the above.

I used Kai's book, and yeah, you have to do things the vibe way. But most web frameworks are that way I think.

I recommend getting the book if you plan on doing a lot with vibe.d

Where vibe really shines are the diet templates and the web interface stuff. To not have to handle anything from forms, or query parameters, and just write normal D functions is really great. You can even do a lot of authentication and stuff using UDAs. It helps you write consistent web applications.

And I LOVE diet templates. So much less verbose than actual HTML. I have a hard time writing actual HTML now.

When you want to do stuff manually, I think it's not as well supported.

-Steve
September 19, 2020
On Saturday, 19 September 2020 at 19:27:40 UTC, Steven Schveighoffer wrote:
>
> I used Kai's book, and yeah, you have to do things the vibe way. But most web frameworks are that way I think.
>

Do you have a reference to this book (web link, ISBN)?


September 19, 2020
On 9/19/20 3:36 PM, IGotD- wrote:
> On Saturday, 19 September 2020 at 19:27:40 UTC, Steven Schveighoffer wrote:
>>
>> I used Kai's book, and yeah, you have to do things the vibe way. But most web frameworks are that way I think.
>>
> 
> Do you have a reference to this book (web link, ISBN)?
> 
> 

Sure:

https://www.packtpub.com/product/d-web-development/9781785288890

It might be a bit dated, but most of the concepts are the same.

-Steve
September 19, 2020
On Saturday, 19 September 2020 at 18:56:20 UTC, Steven Schveighoffer wrote:
> On 9/19/20 7:15 AM, ikod wrote:
>> On Saturday, 19 September 2020 at 11:11:21 UTC, ikod wrote:
>>> On Friday, 18 September 2020 at 13:13:16 UTC, wjoe wrote:

>>> My preferable way to handle such thing is: convert incoming data into input range of immutable(ubyte)[] and let user to consume this range (and handle it as it wish - transform, store in memory as is, or dump to disk)
>> 
>> sorry, this looks exactly like it described in proposal (and this is how requests works).
>> 
>
> You mean for each file, right? Yeah, that is the proposal,

If user uploads several files through single form then yes, for each file. Maybe handler should receive range of input ranges and handle each as necessary.

> though it uses Vibe's io type (necessary I think).
>
> -Steve


September 19, 2020
On Friday, 18 September 2020 at 22:31:09 UTC, mw wrote:
> On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:
>
>> Are there other frameworks besides vibe that can do what I want?
>
> Just FYI, there is also:
>
> https://code.dlang.org/packages/hunt-framework
>
>
> I never used myself, you need to investigate.

Yeah, I'm aware of hunt too. Its like laravel in php whilst vibe.d feels more like express in nodejs. Infact I believe Sonke wrote vibe.d after using express or similar framework by design.


And yes, almost all frameworks work in a certain way. Arsd cgi.d might be what you want if you want to it your way as its more low-level interface-wise.

I personally (and many others in the industry... judging by popularity of express (node.js) and the plentiful third-party libraries,..do prefer the router.get() design. Also having everything abstracted in a convenient and consistent way...is very desirable. vibe.d's web interface API is something I've always praised and thanks to how powerful D is compare to say JavaScript. Diet templates is also an example.

However that power is not tapped in enough (yet) to favour using D conveniently over node (js). And web developers are interested in getting things done (at least my kind of web devs) rather than getting it our way...or squeezing every bit of efficiency out of it. Part of why v8 is fast by default (for us).

Unike express (which is a thing layer with interface for third-parties to hook in and extend with libs), vibe.d became a monolith with everything included... making it harder to maintain and extend in other ways. Plus too much hard-coding by default currently. Unfortunately Sonke doesn't work on it like he used to...and its quite an huge accomplishment...the work he's done for D.


I wish vibe.d could be positioned and sponsored officially or by community cus its the killer app.

Staying lean and being extensible will open up for more innovation around it. Eg. a form handler for files library that works like how Ikod suggested...a customizable stream.


Unless you're doing usual routing and database things, using vibe.d for a full stack projects can lead to a dead end unless you're positioned to write your own stuff to supplement. Of course its only a matter of time before this change for the good.

Personally I use vibe.d for basic side projects. Looking to use it more going forward. But that's how I see it.
September 19, 2020
On Saturday, 19 September 2020 at 20:17:06 UTC, aberba wrote:
> On Friday, 18 September 2020 at 22:31:09 UTC, mw wrote:
>> On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:
>>
>>> Are there other frameworks besides vibe that can do what I want?

> Personally I use vibe.d for basic side projects. Looking to use it more going forward. But that's how I see it.

This is my personal collection of D web development packages. Let me know if I'm missing something.

https://gist.github.com/aberba/dcaf9102b35205080ad99a2af2c21142

September 20, 2020
On Saturday, 19 September 2020 at 20:17:06 UTC, aberba wrote:
> Arsd cgi.d might be what you want if you want to it your way as its more low-level interface-wise.

Eh, it depends. My lib lets you do as much or as little as you want.

About ten years ago, I wrote a framework on top that automatically generates javascript/json interfaces as well as html form and output UI just given an ordinary D class. Had full interop with PHP too... all with no UDAs since they didn't exist yet!

I never really documented how to use it. Wrote a few examples on the forum but nothing formal. I kinda regret that; I've *still* never seen anyone else, anywhere, automate as much as it did.

old demo I posted in May 2011: http://arsdnet.net/cgi-bin/apidemo/javascript

I can't find the source to that anymore but it would be something like:

---
import arsd.web;

class CoolApi : WebApi {
   enum Color { red, green, etc }
   struct Person { int id; string first; string last; }

   Element getABox(Color c) {
         auto div = Element.make("div");
         div.style.color = to!string(c);
         return div;
   }

   int addSomeNumbers(int a, int b) { return a + b; }

   Person[] getPeople(int startingId) { return [Person(...)]; }
}
mixin FancyMain!CoolApi;
---

That's it - all the html and javascript are all auto-generated.


Nowadays I'm merging all those ideas into cgi.d and actually writing about it in my blog. There's a lot in my old implementation I didn't like but now that D's reflection is better than it was, I have techniques to make it even better.

My new dwidder website is the only public example of the new code so far https://github.com/adamdruppe/dupdates/blob/master/main.d#L157

Still a bunch more I'm slowly bringing together. D has unique strengths for web that javascript, ruby, and python can just *never* do and we should be pushing the edges to go as cool as we can.