On Friday, 15 July 2011 at 01:00:51 UTC, Adam D. Ruppe wrote:
> 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.
>

is this still working on the latest git (2bfdccc)? I don't seem to be able to call anything..

And do public functions really require "export" now or am i just declaring them in i wrong way?

class MySite : ApiProvider {

	export string hello(string name){
		return "Welcome " ~ name ~ "!";
	}

	export string foo(){
		return "foo";
	}

	override Document _defaultPage() {
		return _getGenericContainer().appendChild(_sitemap()).parentDocument;
	}
};


mixin FancyMain!MySite;

On Friday, 15 July 2011 at 22:37:00 UTC, Andrei Alexandrescu wrote:
> On 7/15/11 4:26 PM, Adam Ruppe wrote:
>>> IMO it makes sense to use this to reduce process creation times.
>>
>> Process creation is a very small cost with D programs. It's nothing
>> to worry about unless you have real world data to the contrary for
>> your project.
>
> Doesn't that apply more to Unix than to D?
>
> One of the paradigm shifts incurred when I moved to Unix from Windows was how incredibly cheap it was to create processes on Unix, and how many great idioms derive from that. In Windows one gets used to thinking creating a process is a big deal, which requires a fair amount of unlearning.
>
>
> Andrei

On the other hand threading is everywhere.

On Wednesday, 3 July 2013 at 09:39:43 UTC, Paulo Pinto wrote:
> On the other hand threading is everywhere.

On the other hand both creating process and thread are so much more expensive than not creating anything at all :P

On Wed, 2013-07-03 at 11:39 +0200, Paulo Pinto wrote:
[…]
> On the other hand threading is everywhere.

Threads (and processes) are like stacks and heaps, you know they are there but if you are manipulating them explicitly instead of as a managed resource, you need to have a very, very good reason why.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 3 July 2013 at 09:24:03 UTC, RedX wrote:
> is this still working on the latest git (2bfdccc)? I don't seem to be able to call anything..

I found the bug, I had a static if that was too restrictive and stopped reading the child object functions.

It is fixed now on the newest github version.


The regular functions and child ApiProviders are still working, though the child ApiObject thing is mildly buggy, the initialize and initializePerCall aren't always done right, so if you override them, you need to call the parent too. Or something like that, I have it working in a program but it was a bug workaround hack.

Regular functions work excellently though!

> And do public functions really require "export" now or am i just declaring them in i wrong way?

Yes, they need export now. You can easily work around it by writing

class MySite : ApiProvider {
  export:
    string hello() {}
// etc
}

The export: at the top will apply to everything unless you override it on a specific function.


The reason it does this is to get more control over if you want helper functions to show up publicly or not. Before it used a leading _ in the name to skip, which still works, but now you can also use other access specifiers.

It uses export instead of public because public is available to other modules, export I took to mean even more available to outside the program.

On Wednesday, 3 July 2013 at 09:45:18 UTC, Dicebot wrote:
> On the other hand both creating process and thread are so much more expensive than not creating anything at all :P

I recently added a process pool to cgi.d and it was both the simplest and the fastest option for the http server it has. I tried to do a thread pool, to avoid creating stuff in the main loop, but I messed it up.

The process pool on Linux though was dead easy and worked really well. I find it kinda interesting how threads in D seem to emulate processes too, with TLS giving you a sort of separate address space - just easier to get right as the programmer I guess.

On Wednesday, 3 July 2013 at 13:31:56 UTC, Adam D. Ruppe wrote:
> The process pool on Linux though was dead easy and worked really well. I find it kinda interesting how threads in D seem to emulate processes too, with TLS giving you a sort of separate address space - just easier to get right as the programmer I guess.

That is essentially what happens now in vibe.d when multiple worker threads are used - because all server stuff is stored in TLS, each worker thread operates completely independently, similar to separate processes but with a nice bonus of sharing data made easier in user code.

I was referring to the reason behind async models became so popular though - most efficient way to deal with processes and threads is to not use them for multitasking at all :)

Am 03.07.2013 12:03, schrieb Russel Winder:
> On Wed, 2013-07-03 at 11:39 +0200, Paulo Pinto wrote:
> […]
>> On the other hand threading is everywhere.
>
> Threads (and processes) are like stacks and heaps, you know they are
> there but if you are manipulating them explicitly instead of as a
> managed resource, you need to have a very, very good reason why.
>

True, but functional programming is only now becoming mainstream.

I remember reading a book around 1997 about doing HPC in multicore
machines with NUMA in a Lisp like language.

The language runtime was the OS and it took care of exploring the
multicore environment, while the researchers could express higher
level algorithms.

Eventually we will get there.

--
Paulo

On Wednesday, 3 July 2013 at 13:05:27 UTC, Adam D. Ruppe wrote:
> On Wednesday, 3 July 2013 at 09:24:03 UTC, RedX wrote:
>> is this still working on the latest git (2bfdccc)? I don't seem to be able to call anything..
>
> I found the bug, I had a static if that was too restrictive and stopped reading the child object functions.
>
> It is fixed now on the newest github version.
>
>
> The regular functions and child ApiProviders are still working, though the child ApiObject thing is mildly buggy, the initialize and initializePerCall aren't always done right, so if you override them, you need to call the parent too. Or something like that, I have it working in a program but it was a bug workaround hack.
>
> Regular functions work excellently though!
>
>> And do public functions really require "export" now or am i just declaring them in i wrong way?
>
> Yes, they need export now. You can easily work around it by writing
>
> class MySite : ApiProvider {
>   export:
>     string hello() {}
> // etc
> }
>
> The export: at the top will apply to everything unless you override it on a specific function.
>
>
> The reason it does this is to get more control over if you want helper functions to show up publicly or not. Before it used a leading _ in the name to skip, which still works, but now you can also use other access specifiers.
>
> It uses export instead of public because public is available to other modules, export I took to mean even more available to outside the program.

Very nice, thank you.

I was wondering if there is a way of sending the program back to the form entry page if validation on the input fails in the function that is accepting the arguments. In the _Form function i'm only able to create the form but no validation can be done there and no _Validate automatism seems to exist, or am i overseeing something?

On 07/14/2011 12:49 PM, Robert M. Münch wrote:
> Hi, is there a matured framework for building the server side part of
> web-apps in D2? I don't need totally fancy things, session handling,
> dynamic content and simple output generation.
>
http://vibed.org/