www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - critique of vibe.d

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
There's been some discussion about vibe.d recently on reddit (e.g. 
http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_
iscovers_d/cir9443) 
and I was wondering to what extent that's meaningful:

"has anyone ever tied a real webservice to vibe.d? I actually tried. its 
nowhere near complete in any sense. you simply cannot compare it with 
go's standard http lib, sorry, I tried."

If there's sheer work needed for completing vibe.d, I think it would be 
great if the domain-savvy part of the community would rally around it. 
Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding.


Andrei
Jul 08 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
wrote:

 If there's sheer work needed for completing vibe.d, I think it 
 would be great if the domain-savvy part of the community would 
 rally around it. Serving dlang.org and dconf.org off of vibe.d 
 would be awesome dogfooding.


Google App Engine is opening up for managed servers using new 
tech. I know Dart is coming to the managed servers soon. Of 
course, this is still in limited preview and not for production, 
but having D on App Engine would be interesting for many reasons.

https://developers.google.com/appengine/docs/managed-vms/

Google Compute Engine is also an option. Building libraries to 
access the regular cloud services such as Google Cloud Storage 
and Cloud SQL (replicated MySQL) is not too hard.

https://developers.google.com/compute/
https://developers.google.com/cloud-sql/
https://developers.google.com/storage/

It would also be an opportunity to test the abstraction levels of 
the current standard library…
Jul 08 2014
prev sibling next sibling parent reply "Puming" <zhaopuming gmail.com> writes:
Vibe.d is more like a base library for async I/O, networking and 
concurrency, a full stack WEB framework should be built on top of 
it which focus on application development and ease of use for 
newcomers. Sonke has said that too. Vibe.d should focus on 
performance, networking, and other lowerlevel stuff that D should 
be really good at. Sonke is already too busy doing his gorgeous 
work on vibe.d and dub. I think that is what the guy on reddit 
was complaining, he thought vibe.d should contain everything from 
a web framework, but didn't find them, thus getting the 
impression that vibe.d was not complete. Actually vibe.d is just 
an edge of a triangle in web frameworks. We are lacking the other 
two pieces.

We need a MVC or whatever framework on top of it. Compared to 
Java world, there is [Netty](http://netty.io) the networking 
library and Web frameworks like playframework, vert.x built on 
top of it.

Currently the only work that is active IFAIK is Rikki's 
[CMSED](https://github.com/rikkimax/Cmsed), which needs more love.

In [playframework](http://playframework.org), incoming request 
are send to a cluster of actions in a [Akka](http://akka.io) 
cluster for computing & business logic. The trio (play, netty & 
akka) has shown to be very good combination for a web stack.

We have actor models in std.concurrency but only with thread 
granularity, vibe.d has got a fiber based concurrency model which 
I think could go in to the standard library, or make its own 
library. That front needs more manpower. Again, rikki has 
initiated a port from akka -- 
[dakka](https://github.com/rikkimax/dakka). I think it is a right 
way to go.


On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
wrote:

 There's been some discussion about vibe.d recently on reddit 
 (e.g. 
 http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_
iscovers_d/cir9443) 
 and I was wondering to what extent that's meaningful:

 "has anyone ever tied a real webservice to vibe.d? I actually 
 tried. its nowhere near complete in any sense. you simply 
 cannot compare it with go's standard http lib, sorry, I tried."

 If there's sheer work needed for completing vibe.d, I think it 
 would be great if the domain-savvy part of the community would 
 rally around it. Serving dlang.org and dconf.org off of vibe.d 
 would be awesome dogfooding.


 Andrei
Jul 08 2014
next sibling parent reply "Puming" <zhaopuming gmail.com> writes:
Also, in playframework, vert.x and nodejs, they all have a 
plugin/module system, that people could easily compose plugins to 
make a website. (I call it plugin because that is what play used 
to call it, now they all call it a module but that name will 
easily conflict with D's sourcecode modules). This is a critical 
mechanism that actually allured developers to contribute to the 
eco-system.

Plugins are like dub packages in a way, but not exactly. Dub 
packages are an encapsulation of build packages, which is similar 
to Java's maven packages. But plugins are components of the web 
framework, built on top of build packages, but has more 
application related meaning. So both play and vert.x have 
separated plugin(in vert.x is called a module) concept from maven 
package. Vibe.d could have this plugin mechanizem, but Sonke said 
that it should be the responsibility of a framework on top of it 
(meaning in that framework, vibe.d would just be a plugin to the 
framework that web developers would choose to server http 
requests).

For example, if one designed a user/password plugin, with 
database access logic (in source folder), login page templates 
(in view folder) and static js/image/css (in public folder), and 
this plugin is used, then all resources are treated just as they 
are manually put into respective folders. While dub packages 
usually only deals with D code.

You can see playframework's plugin registery here: 
<http://www.playframework.com/documentation/2.3.x/Modules>

vert.x module's document here: 
<http://vertx.io/mods_manual.html>, vert.x has a more complicated 
module design (which not only is a way to group functionalities, 
but also a deployment node).
its registery here: <http://modulereg.vertx.io/>



On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote:

 Vibe.d is more like a base library for async I/O, networking 
 and concurrency, a full stack WEB framework should be built on 
 top of it which focus on application development and ease of 
 use for newcomers. Sonke has said that too. Vibe.d should focus 
 on performance, networking, and other lowerlevel stuff that D 
 should be really good at. Sonke is already too busy doing his 
 gorgeous work on vibe.d and dub. I think that is what the guy 
 on reddit was complaining, he thought vibe.d should contain 
 everything from a web framework, but didn't find them, thus 
 getting the impression that vibe.d was not complete. Actually 
 vibe.d is just an edge of a triangle in web frameworks. We are 
 lacking the other two pieces.

 We need a MVC or whatever framework on top of it. Compared to 
 Java world, there is [Netty](http://netty.io) the networking 
 library and Web frameworks like playframework, vert.x built on 
 top of it.

 Currently the only work that is active IFAIK is Rikki's 
 [CMSED](https://github.com/rikkimax/Cmsed), which needs more 
 love.

 In [playframework](http://playframework.org), incoming request 
 are send to a cluster of actions in a [Akka](http://akka.io) 
 cluster for computing & business logic. The trio (play, netty & 
 akka) has shown to be very good combination for a web stack.

 We have actor models in std.concurrency but only with thread 
 granularity, vibe.d has got a fiber based concurrency model 
 which I think could go in to the standard library, or make its 
 own library. That front needs more manpower. Again, rikki has 
 initiated a port from akka -- 
 [dakka](https://github.com/rikkimax/dakka). I think it is a 
 right way to go.


 On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
 wrote:

 There's been some discussion about vibe.d recently on reddit 
 (e.g. 
 http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_
iscovers_d/cir9443) 
 and I was wondering to what extent that's meaningful:

 "has anyone ever tied a real webservice to vibe.d? I actually 
 tried. its nowhere near complete in any sense. you simply 
 cannot compare it with go's standard http lib, sorry, I tried."

 If there's sheer work needed for completing vibe.d, I think it 
 would be great if the domain-savvy part of the community would 
 rally around it. Serving dlang.org and dconf.org off of vibe.d 
 would be awesome dogfooding.


 Andrei
Jul 08 2014
next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote:

 Also, in playframework, vert.x and nodejs, they all have a 
 plugin/module system, that people could easily compose plugins 
 to make a website. (I call it plugin because that is what play 
 used to call it, now they all call it a module but that name 
 will easily conflict with D's sourcecode modules). This is a 
 critical mechanism that actually allured developers to 
 contribute to the eco-system.


On a related note, one thing vibe.d is really missing from my 
perspective is a good way to handle unstable processes and 
perform seamless code upgrades (this is where Erlang really 
shines IMO).  It would be cool if there were a process monitor at 
least.  The system I work with does some fancy stuff with UDS, 
but that probably isn't necessary.  I'll admit that the ball is 
probably kind of in my court here, since IPC would be a handy way 
of communicating process health, but something simpler using 
pipes or whatever would work as well.
Jul 09 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 09.07.2014 17:26, schrieb Sean Kelly:

 On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote:

 Also, in playframework, vert.x and nodejs, they all have a
 plugin/module system, that people could easily compose plugins to make
 a website. (I call it plugin because that is what play used to call
 it, now they all call it a module but that name will easily conflict
 with D's sourcecode modules). This is a critical mechanism that
 actually allured developers to contribute to the eco-system.


 On a related note, one thing vibe.d is really missing from my
 perspective is a good way to handle unstable processes and perform
 seamless code upgrades (this is where Erlang really shines IMO).  It
 would be cool if there were a process monitor at least.  The system I
 work with does some fancy stuff with UDS, but that probably isn't
 necessary.  I'll admit that the ball is probably kind of in my court
 here, since IPC would be a handy way of communicating process health,
 but something simpler using pipes or whatever would work as well.


This is what vibedist [1] was/is intended for, but unfortunately I never 
found the time to really finish it so far.

[1]: https://github.com/rejectedsoftware/vibedist
Jul 09 2014
parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 09 Jul 2014 18:16:49 +0200
schrieb S=C3=B6nke Ludwig <sludwig rejectedsoftware.com>:


 Am 09.07.2014 17:26, schrieb Sean Kelly:

 On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote:

 Also, in playframework, vert.x and nodejs, they all have a
 plugin/module system, that people could easily compose plugins to
 make a website. (I call it plugin because that is what play used
 to call it, now they all call it a module but that name will
 easily conflict with D's sourcecode modules). This is a critical
 mechanism that actually allured developers to contribute to the
 eco-system.


 On a related note, one thing vibe.d is really missing from my
 perspective is a good way to handle unstable processes and perform
 seamless code upgrades (this is where Erlang really shines IMO).  It
 would be cool if there were a process monitor at least.  The system
 I work with does some fancy stuff with UDS, but that probably isn't
 necessary.  I'll admit that the ball is probably kind of in my court
 here, since IPC would be a handy way of communicating process
 health, but something simpler using pipes or whatever would work as
 well.


=20
 This is what vibedist [1] was/is intended for, but unfortunately I
 never found the time to really finish it so far.
=20
 [1]: https://github.com/rejectedsoftware/vibedist



Completely off-topic, but:

Have you considered making vibe http-backend independent?
So that it could provide a fcgi interface or be included in an nginx
plugin?

Also as D plugins now seem to work more or less have you considered
loading webpages dynamically from .so files?

Then we could invent some file extension - like .dpage - and have one
vibe fcgi process handle all .dpage files. The process then simply
loads the .dpage shared library, calls some function (extern(C) IWebSite
vibe_get_site()) etc.

Basically the way asp.net works, IIRC.
Jul 09 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau wrote:

 Completely off-topic, but:

 Have you considered making vibe http-backend independent?
 So that it could provide a fcgi interface or be included in an 
 nginx
 plugin?


What is the benefit as opposed to using proxy_pass at nginx? fcgi 
will be slower than built-in vibe.d HTTP server.
Jul 09 2014
parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 09 Jul 2014 17:28:42 +0000
schrieb "Dicebot" <public dicebot.lv>:


 On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau wrote:

 Completely off-topic, but:

 Have you considered making vibe http-backend independent?
 So that it could provide a fcgi interface or be included in an 
 nginx
 plugin?


 
 What is the benefit as opposed to using proxy_pass at nginx? fcgi 
 will be slower than built-in vibe.d HTTP server.


FCGI was only an example. I guess the only benefit is that the webserver
can spawn fcgi backends when it starts and files with certain
extensions can be handled with these backends.

But that's of course only useful with shared libraries / pages.
Jul 09 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 9 July 2014 at 21:07:26 UTC, Johannes Pfau wrote:

 Am Wed, 09 Jul 2014 17:28:42 +0000
 schrieb "Dicebot" <public dicebot.lv>:


 On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau wrote:

 Completely off-topic, but:

 Have you considered making vibe http-backend independent?
 So that it could provide a fcgi interface or be included in 
 an nginx
 plugin?


 
 What is the benefit as opposed to using proxy_pass at nginx? 
 fcgi will be slower than built-in vibe.d HTTP server.


 FCGI was only an example. I guess the only benefit is that the 
 webserver
 can spawn fcgi backends when it starts and files with certain
 extensions can be handled with these backends.

 But that's of course only useful with shared libraries / pages.


vibe.d can do it internally by having different routes for 
different file types and doing dynamic load if desired. Being 
100% independent of HTTP server frontend is a big feature in my 
opinion.
Jul 10 2014
parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 10 July 2014 at 10:24:23 UTC, Dicebot wrote:

 On Wednesday, 9 July 2014 at 21:07:26 UTC, Johannes Pfau wrote:

 Am Wed, 09 Jul 2014 17:28:42 +0000
 schrieb "Dicebot" <public dicebot.lv>:


 On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau 
 wrote:

 Completely off-topic, but:

 Have you considered making vibe http-backend independent?
 So that it could provide a fcgi interface or be included in 
 an nginx
 plugin?


 
 What is the benefit as opposed to using proxy_pass at nginx? 
 fcgi will be slower than built-in vibe.d HTTP server.


 FCGI was only an example. I guess the only benefit is that the 
 webserver
 can spawn fcgi backends when it starts and files with certain
 extensions can be handled with these backends.

 But that's of course only useful with shared libraries / pages.


 vibe.d can do it internally by having different routes for 
 different file types and doing dynamic load if desired. Being 
 100% independent of HTTP server frontend is a big feature in my 
 opinion.


Yes, that's what I use. I have this in my vibe.d code (to solve 
the problem that Chrome/Chromium play sound files only once):

router.get("*.wav", &handleAudioRequest);

private void handleAudioRequest(HTTPServerRequest req, 
HTTPServerResponse res) {
   res.headers.addField("Accept-Ranges", "bytes");
}
Jul 10 2014
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 09.07.2014 19:03, schrieb Johannes Pfau:

 Am Wed, 09 Jul 2014 18:16:49 +0200
 schrieb Sönke Ludwig <sludwig rejectedsoftware.com>:


 Am 09.07.2014 17:26, schrieb Sean Kelly:

 On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote:

 Also, in playframework, vert.x and nodejs, they all have a
 plugin/module system, that people could easily compose plugins to
 make a website. (I call it plugin because that is what play used
 to call it, now they all call it a module but that name will
 easily conflict with D's sourcecode modules). This is a critical
 mechanism that actually allured developers to contribute to the
 eco-system.


 On a related note, one thing vibe.d is really missing from my
 perspective is a good way to handle unstable processes and perform
 seamless code upgrades (this is where Erlang really shines IMO).  It
 would be cool if there were a process monitor at least.  The system
 I work with does some fancy stuff with UDS, but that probably isn't
 necessary.  I'll admit that the ball is probably kind of in my court
 here, since IPC would be a handy way of communicating process
 health, but something simpler using pipes or whatever would work as
 well.


 This is what vibedist [1] was/is intended for, but unfortunately I
 never found the time to really finish it so far.

 [1]: https://github.com/rejectedsoftware/vibedist



 Completely off-topic, but:

 Have you considered making vibe http-backend independent?
 So that it could provide a fcgi interface or be included in an nginx
 plugin?


That could be done pretty easily by providing an alternative to 
listenHTTP() (e.g. void listenFCGI(HTTPServerRequestDelegate del)). It 
could use the HTTPServerRequest and HTTPServerResponse classes more or 
less just like the HTTP server does.


 Also as D plugins now seem to work more or less have you considered
 loading webpages dynamically from .so files?

 Then we could invent some file extension - like .dpage - and have one
 vibe fcgi process handle all .dpage files. The process then simply
 loads the .dpage shared library, calls some function (extern(C) IWebSite
 vibe_get_site()) etc.

 Basically the way asp.net works, IIRC.


That would be pretty much what Rikki Cattermole is planning to do with 
Cmsed [1]. For vibe.d it would be a bit too much at this time. There is 
still a lot that I would like to get done on the lower levels of the 
library, so that the basis is really solid sooner rather than later. The 
highest level features planned for now are the descriptive REST and web 
interface modules.

However, there is a plan for using dynamic libraries to support seamless 
live editing/reloading of individual Diet templates [2].

[1]: http://code.dlang.org/packages/cmsed
[2]: https://github.com/rejectedsoftware/vibe.d/issues/676
Jul 09 2014
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 09 Jul 2014 20:34:49 +0200
schrieb S=C3=B6nke Ludwig <sludwig rejectedsoftware.com>:


 Am 09.07.2014 19:03, schrieb Johannes Pfau:

 Am Wed, 09 Jul 2014 18:16:49 +0200
 schrieb S=C3=B6nke Ludwig <sludwig rejectedsoftware.com>:


 Am 09.07.2014 17:26, schrieb Sean Kelly:

 On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote:

 Also, in playframework, vert.x and nodejs, they all have a
 plugin/module system, that people could easily compose plugins to
 make a website. (I call it plugin because that is what play used
 to call it, now they all call it a module but that name will
 easily conflict with D's sourcecode modules). This is a critical
 mechanism that actually allured developers to contribute to the
 eco-system.


 On a related note, one thing vibe.d is really missing from my
 perspective is a good way to handle unstable processes and perform
 seamless code upgrades (this is where Erlang really shines IMO).
 It would be cool if there were a process monitor at least.  The
 system I work with does some fancy stuff with UDS, but that
 probably isn't necessary.  I'll admit that the ball is probably
 kind of in my court here, since IPC would be a handy way of
 communicating process health, but something simpler using pipes
 or whatever would work as well.


 This is what vibedist [1] was/is intended for, but unfortunately I
 never found the time to really finish it so far.

 [1]: https://github.com/rejectedsoftware/vibedist



 Completely off-topic, but:

 Have you considered making vibe http-backend independent?
 So that it could provide a fcgi interface or be included in an nginx
 plugin?


=20
 That could be done pretty easily by providing an alternative to=20
 listenHTTP() (e.g. void listenFCGI(HTTPServerRequestDelegate del)).
 It could use the HTTPServerRequest and HTTPServerResponse classes
 more or less just like the HTTP server does.
=20

 Also as D plugins now seem to work more or less have you considered
 loading webpages dynamically from .so files?

 Then we could invent some file extension - like .dpage - and have
 one vibe fcgi process handle all .dpage files. The process then
 simply loads the .dpage shared library, calls some function
 (extern(C) IWebSite vibe_get_site()) etc.

 Basically the way asp.net works, IIRC.


=20
 That would be pretty much what Rikki Cattermole is planning to do
 with Cmsed [1]. For vibe.d it would be a bit too much at this time.
 There is still a lot that I would like to get done on the lower
 levels of the library, so that the basis is really solid sooner
 rather than later. The highest level features planned for now are the
 descriptive REST and web interface modules.
=20
 However, there is a plan for using dynamic libraries to support
 seamless live editing/reloading of individual Diet templates [2].
=20
 [1]: http://code.dlang.org/packages/cmsed
 [2]: https://github.com/rejectedsoftware/vibe.d/issues/676


I see, thanks. I think a CMS is usually a little higher-level then what
I meant. But of course a name doesn't say much about what a project
actually is ;-)
Jul 09 2014
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 10/07/2014 9:12 a.m., Johannes Pfau wrote:

 Am Wed, 09 Jul 2014 20:34:49 +0200
 schrieb Sönke Ludwig <sludwig rejectedsoftware.com>:


 Am 09.07.2014 19:03, schrieb Johannes Pfau:

 Am Wed, 09 Jul 2014 18:16:49 +0200
 schrieb Sönke Ludwig <sludwig rejectedsoftware.com>:


 Am 09.07.2014 17:26, schrieb Sean Kelly:

 On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote:

 Also, in playframework, vert.x and nodejs, they all have a
 plugin/module system, that people could easily compose plugins to
 make a website. (I call it plugin because that is what play used
 to call it, now they all call it a module but that name will
 easily conflict with D's sourcecode modules). This is a critical
 mechanism that actually allured developers to contribute to the
 eco-system.


 On a related note, one thing vibe.d is really missing from my
 perspective is a good way to handle unstable processes and perform
 seamless code upgrades (this is where Erlang really shines IMO).
 It would be cool if there were a process monitor at least.  The
 system I work with does some fancy stuff with UDS, but that
 probably isn't necessary.  I'll admit that the ball is probably
 kind of in my court here, since IPC would be a handy way of
 communicating process health, but something simpler using pipes
 or whatever would work as well.


 This is what vibedist [1] was/is intended for, but unfortunately I
 never found the time to really finish it so far.

 [1]: https://github.com/rejectedsoftware/vibedist



 Completely off-topic, but:

 Have you considered making vibe http-backend independent?
 So that it could provide a fcgi interface or be included in an nginx
 plugin?


 That could be done pretty easily by providing an alternative to
 listenHTTP() (e.g. void listenFCGI(HTTPServerRequestDelegate del)).
 It could use the HTTPServerRequest and HTTPServerResponse classes
 more or less just like the HTTP server does.


 Also as D plugins now seem to work more or less have you considered
 loading webpages dynamically from .so files?

 Then we could invent some file extension - like .dpage - and have
 one vibe fcgi process handle all .dpage files. The process then
 simply loads the .dpage shared library, calls some function
 (extern(C) IWebSite vibe_get_site()) etc.

 Basically the way asp.net works, IIRC.


 That would be pretty much what Rikki Cattermole is planning to do
 with Cmsed [1]. For vibe.d it would be a bit too much at this time.
 There is still a lot that I would like to get done on the lower
 levels of the library, so that the basis is really solid sooner
 rather than later. The highest level features planned for now are the
 descriptive REST and web interface modules.

 However, there is a plan for using dynamic libraries to support
 seamless live editing/reloading of individual Diet templates [2].

 [1]: http://code.dlang.org/packages/cmsed
 [2]: https://github.com/rejectedsoftware/vibe.d/issues/676


 I see, thanks. I think a CMS is usually a little higher-level then what
 I meant. But of course a name doesn't say much about what a project
 actually is ;-)


Unfortunately right now Cmsed doesn't for-fill its purpose in the CMS 
area. But basically I use dub sub packages so if you didn't want to go 
full in, you didn't need to.
I.E. the base web service framework is literally called cmsed:base and 
it would give you most of the nice ness e.g. router, javascript 
generation and Dvorm integration (ORM and works rather well in my opinion).
Where as cmsed:user would provide just user authentication and storage 
mechanism.
Jul 09 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-07-09 20:34, Sönke Ludwig wrote:


 However, there is a plan for using dynamic libraries to support seamless
 live editing/reloading of individual Diet templates [2].


Since LDC uses LLVM as its backend which supports JIT compilation it 
might be possible to JIT compile the Diet templates instead of using 
dynamic libraries.

-- 
/Jacob Carlborg
Jul 10 2014
prev sibling parent Etienne <etcimon gmail.com> writes:
On 2014-07-08 9:32 PM, Puming wrote:

 Also, in playframework, vert.x and nodejs, they all have a plugin/module
 system, that people could easily compose plugins to make a website. (I
 call it plugin because that is what play used to call it, now they all
 call it a module but that name will easily conflict with D's sourcecode
 modules). This is a critical mechanism that actually allured developers
 to contribute to the eco-system.


This is phenomenal work from my perspective because it needs to be 
original to justify the move. However, I was too tempted by the 
functional nature of D and my imagination motivated me to build the 
technicalities for some huge infrastructures behind a next-gen CMS.

I have a chart up at https://github.com/globecsys/spee.d about what's 
involved with it, on my schedule for all components there should be at 
least 300 hours of work left.

I'm aiming for a standalone executable library-oriented framework, which 
would give a cross-platform wordpress-like CMS installation that 
technically should scale _infinitely_. There's a few issues with 
infinite scalability behind NAT firewall nodes, like

- the solution would be a websocket communication with (http://wamp.ws/) 
a more advanced protocol is elementary.
- a cache database (I have a local redis-like one up called cache.d) 
needs to "talk" to hash-distributed master DBs with replication
- this cache database would be modified to take advantage of the GC to 
avoid making additional copies on a server (store some void* in memory, 
serialized data on the filesystem).
- library support would be with the same interface as wordpress: 
add_filter, add_action, etc - but a focus on Backbone.marionette for 
front-end js-based structuring with REST/json backend data provider
- a custom D-based TLS library would help maximize code inlining in the 
streams and minimize points of attack
- a DER and length-value serialization library would help minimize 
boilerplate

I'm still brainstorming on the geolocation and domain-clustering of 
master nodes and load balancing.

I'm finishing up work on a completely generic ASN.1 compiler with 
support for Information Objects that generates D structures for TLS: 
https://github.com/globecsys/asn1.d

This is necessary because there's over 7000 lines of structure 
definitions involved: 
https://github.com/globecsys/asn1.d/blob/master/tls.asn1

Anyways, enough typing about this for the moment, I'm not looking for 
help :)
Jul 09 2014
prev sibling next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 9/07/2014 1:09 p.m., Puming wrote:

 Vibe.d is more like a base library for async I/O, networking and
 concurrency, a full stack WEB framework should be built on top of it
 which focus on application development and ease of use for newcomers.
 Sonke has said that too. Vibe.d should focus on performance, networking,
 and other lowerlevel stuff that D should be really good at. Sonke is
 already too busy doing his gorgeous work on vibe.d and dub. I think that
 is what the guy on reddit was complaining, he thought vibe.d should
 contain everything from a web framework, but didn't find them, thus
 getting the impression that vibe.d was not complete. Actually vibe.d is
 just an edge of a triangle in web frameworks. We are lacking the other
 two pieces.

 We need a MVC or whatever framework on top of it. Compared to Java
 world, there is [Netty](http://netty.io) the networking library and Web
 frameworks like playframework, vert.x built on top of it.

 Currently the only work that is active IFAIK is Rikki's
 [CMSED](https://github.com/rikkimax/Cmsed), which needs more love.


Yes, I do need more help, but really I need Dakka to be made first. Get 
me Dakka. I'll give you live reloading so to speak.

Same goes with my ASN.1 lib[0]. Give me BER unittests, I'll give you an 
LDAP client library hooked into Cmsed's authentication mechanism (I 
haven't been able to find them and its not so simply to go by spec).
Give me a way to work with templates and traits better, I'll give you a 
fully working UML generator[1].


 In [playframework](http://playframework.org), incoming request are send
 to a cluster of actions in a [Akka](http://akka.io) cluster for
 computing & business logic. The trio (play, netty & akka) has shown to
 be very good combination for a web stack.


I have an evil idea on how to do this via Dakka actually, in fact I'm 
thinking that we could even use it for load balancing. Not to mention 
live updating during production!


 We have actor models in std.concurrency but only with thread
 granularity, vibe.d has got a fiber based concurrency model which I
 think could go in to the standard library, or make its own library. That
 front needs more manpower. Again, rikki has initiated a port from akka
 -- [dakka](https://github.com/rikkimax/dakka). I think it is a right way
 to go.


Dakka is less a port of Akka and more of a complete new framework while 
basing it on Akka (why reinvent the wheel, after all its extremely 
successful).
I'm personally only using it for as an RPC mechanism, but by in large 
they will cover most of the bases.
I could really use some help with threading, I am sure there is 
something that will cause deadlocks or something much much worse. My 
skills in this area are quite limited.
At worse, even commenting would be a help.


 On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:

 There's been some discussion about vibe.d recently on reddit (e.g.
 http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
 and I was wondering to what extent that's meaningful:

 "has anyone ever tied a real webservice to vibe.d? I actually tried.
 its nowhere near complete in any sense. you simply cannot compare it
 with go's standard http lib, sorry, I tried."

 If there's sheer work needed for completing vibe.d, I think it would
 be great if the domain-savvy part of the community would rally around
 it. Serving dlang.org and dconf.org off of vibe.d would be awesome
 dogfooding.


 Andrei




There is so many projects I want to work on to extend Cmsed's 
capabilities. From OAuth2 to PDF generation. But I can't do them (time 
wise). So if anybody would be interested in these sorts of projects:
* PDF creation
* Image manipulation and loading (we would need this anyway for e.g. Aurora)
* Barcode generation
* Qr code generation
* Skeleton generation (perhaps this could go into dub?)
* Something like GWT, not really possible right now nicely atleast the 
way I'd like it to work

Something I am very concerned about is documentation. While us in the D 
community are use to reading docs and at best examples. Most developers 
are not. They want simple examples with lots of information around it on 
websites, a little like how dlang's language specification is set up.

Even Vibe is pretty limited in this direction. This is also why I want a 
skeleton generator, Cmsed will have a complex directory setup in the 
future. Users shouldn't need to create that by hand.

[0] https://github.com/rikkimax/asn1
[1] https://github.com/rikkimax/Duml
Jul 08 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote:

 Vibe.d is more like a base library for async I/O, networking 
 and concurrency, a full stack WEB framework should be built on 
 top of it


Ironically I find pure vibe.d solutions much more clean and easy 
to maintain than any enhancements built on top so far (including 
Cmsed). I don't do any frontend stuff though.
Jul 09 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote:

 Vibe.d is more like a base library for async I/O, networking 
 and concurrency, a full stack WEB framework should be built on 
 top of it which focus on application development and ease of 
 use for newcomers. Sonke has said that too. Vibe.d should focus 
 on performance, networking, and other lowerlevel stuff that D 
 should be really good at. Sonke is already too busy doing his 
 gorgeous work on vibe.d and dub. I think that is what the guy 
 on reddit was complaining, he thought vibe.d should contain 
 everything from a web framework, but didn't find them, thus 
 getting the impression that vibe.d was not complete. Actually 
 vibe.d is just an edge of a triangle in web frameworks. We are 
 lacking the other two pieces.


Huh.  I guess it depends what your goal is.  For the kind of work 
I do, vibe.d is in the right ballpark.  The services I create 
basically respond to AJAX calls (JSON-RPC is the best, though 
REST is okay too) and do other back-end work.  I've never had a 
need to do any HTML handling or anything like that.  I might take 
issue with the specifics of how some of the APIs are designed, 
but not with the feature set.
Jul 09 2014
next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 09.07.2014 17:17, schrieb Sean Kelly:

 I might take issue with the specifics
 of how some of the APIs are designed, but not with the feature set.


Please be vocal about such design issues :) I think most parts are in a 
pretty good shape, but there is of course almost always room for 
improvement (the Json/Bson types come to mind).
Jul 09 2014
prev sibling parent "Tavi Cacina" <tc test.com> writes:
On Wednesday, 9 July 2014 at 15:17:03 UTC, Sean Kelly wrote:

 Huh.  I guess it depends what your goal is.  For the kind of 
 work I do, vibe.d is in the right ballpark.  The services I 
 create basically respond to AJAX calls (JSON-RPC is the best, 
 though REST is okay too) and do other back-end work.


The JSON stuff may be nice, but I would prefer some more rigor (I 
am writing mostly c++ desktop apps, for the server side I am 
still open). My 'vision' is a stack with Vibe, Thrift and 
PostgreSQL. Everything plugged inside the vibe's async io and its 
own task/fiber concurrency. I think a good direction would be to 
dispatch the in-proc-service method calls with vibe's 
concurrency/task message passing. This would bring 'async' by 
default (a service would yield as is waits for database or other 
services) and it would guarantee that the requests are processed 
serially by a service (no concurrency or reentrancy problems). 
Bonus points if the services can be easily moved from in-process 
to other machines.
Jul 09 2014
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
wrote:

 There's been some discussion about vibe.d recently on reddit 
 (e.g. 
 http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_
iscovers_d/cir9443) 
 and I was wondering to what extent that's meaningful:

 "has anyone ever tied a real webservice to vibe.d? I actually 
 tried. its nowhere near complete in any sense. you simply 
 cannot compare it with go's standard http lib, sorry, I tried."

 If there's sheer work needed for completing vibe.d, I think it 
 would be great if the domain-savvy part of the community would 
 rally around it. Serving dlang.org and dconf.org off of vibe.d 
 would be awesome dogfooding.


I use vibe.d and I have no idea what that commenter was on about.


 Andrei
Jul 08 2014
parent reply "Puming" <zhaopuming gmail.com> writes:
On Wednesday, 9 July 2014 at 01:13:39 UTC, Nick Sabalausky wrote:

 On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
 wrote:

 There's been some discussion about vibe.d recently on reddit 
 (e.g. 
 http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_
iscovers_d/cir9443) 
 and I was wondering to what extent that's meaningful:

 "has anyone ever tied a real webservice to vibe.d? I actually 
 tried. its nowhere near complete in any sense. you simply 
 cannot compare it with go's standard http lib, sorry, I tried."

 If there's sheer work needed for completing vibe.d, I think it 
 would be great if the domain-savvy part of the community would 
 rally around it. Serving dlang.org and dconf.org off of vibe.d 
 would be awesome dogfooding.


 I use vibe.d and I have no idea what that commenter was on 
 about.


That commenter is probably a web developer that wants all 
batteries included.

 Andrei
Jul 08 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 9 July 2014 at 01:35:49 UTC, Puming wrote:


 That commenter is probably a web developer that wants all 
 batteries included.


Yep. He mistook vibe.d for a complete web development framework, 
I suppose. It's quite common that people are put off because they 
expect too much or do not understand what the technology is 
really about. While we may not win this particular user back, it 
is important to clarify where s/he was mistaken, so that myths 
based on false assumptions are not propagated.
Jul 09 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/9/2014 10:49 AM, Chris wrote:

 On Wednesday, 9 July 2014 at 01:35:49 UTC, Puming wrote:


 That commenter is probably a web developer that wants all batteries
 included.


 Yep. He mistook vibe.d for a complete web development framework, I
 suppose. It's quite common that people are put off because they expect
 too much or do not understand what the technology is really about. While
 we may not win this particular user back, it is important to clarify
 where s/he was mistaken, so that myths based on false assumptions are
 not propagated.


Can't it be used as a complete web framework? I mean, assuming you're 
happy with the built-in templating and DB options? Or is everyone using 
"web framework" here to really mean "CMS"?
Jul 09 2014
parent Jacob Carlborg <doob me.com> writes:
On 09/07/14 20:34, Nick Sabalausky wrote:


 Can't it be used as a complete web framework? I mean, assuming you're
 happy with the built-in templating and DB options? Or is everyone using
 "web framework" here to really mean "CMS"?


I don't know. But to me they're not the same. You can use a web 
framework to build a CMS.

-- 
/Jacob Carlborg
Jul 10 2014
prev sibling next sibling parent reply "luminousone" <rd.hunt gmail.com> writes:
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
wrote:

 There's been some discussion about vibe.d recently on reddit 
 (e.g. 
 http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_
iscovers_d/cir9443) 
 and I was wondering to what extent that's meaningful:

 "has anyone ever tied a real webservice to vibe.d? I actually 
 tried. its nowhere near complete in any sense. you simply 
 cannot compare it with go's standard http lib, sorry, I tried."

 If there's sheer work needed for completing vibe.d, I think it 
 would be great if the domain-savvy part of the community would 
 rally around it. Serving dlang.org and dconf.org off of vibe.d 
 would be awesome dogfooding.


 Andrei


There is lots of missing little bits here and their, password 
hashing functions that use crypt_(C) formated hashes.

There are diet/jade template bugs still, specific major problem 
being that use of single quotes inside of double quotes when i 
need to pass strings to js functions inside of js events such as 
onclick inside a html tag, seems to be broken.

There is not common database interface for sql 
databases(forgivable actually), but many of the specific database 
libraries are messy(ddb for example) and they are not any where 
near api "stable".

Support for mongo is... cute?!, don't get me wrong it has a 
place, for most apps it would be fine, it is however unusable for 
the apps i am involved in.

Anything supported within vibe.d itself, is great, well thought 
out, well written, clean and easy to work with. And vibe.d makes 
wonderful use of D features in a productive way. vibe.d's 
documentation could be better.

Having to go outside of vibe.d for anything is often gritty, and 
that is what keeps me from using it. The oddities of being 
required to use vibe.d's sockets means libraries have to be 
ported to the extend of changing that(not hard, but maintaining a 
changeset from the original authors code is cumbersome if they 
are not updating the lib, or if you would like to link it from 
another languages compiled code).

That said if the database libraries could be brought up to snuff, 
one way or another everything else could be worked around for the 
most part.
Jul 08 2014
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 9/07/2014 1:54 p.m., luminousone wrote:

 On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:

 There's been some discussion about vibe.d recently on reddit (e.g.
 http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
 and I was wondering to what extent that's meaningful:

 "has anyone ever tied a real webservice to vibe.d? I actually tried.
 its nowhere near complete in any sense. you simply cannot compare it
 with go's standard http lib, sorry, I tried."

 If there's sheer work needed for completing vibe.d, I think it would
 be great if the domain-savvy part of the community would rally around
 it. Serving dlang.org and dconf.org off of vibe.d would be awesome
 dogfooding.


 Andrei


 There is lots of missing little bits here and their, password hashing
 functions that use crypt_(C) formated hashes.

 There are diet/jade template bugs still, specific major problem being
 that use of single quotes inside of double quotes when i need to pass
 strings to js functions inside of js events such as onclick inside a
 html tag, seems to be broken.

 There is not common database interface for sql databases(forgivable
 actually), but many of the specific database libraries are messy(ddb for
 example) and they are not any where near api "stable".


Yeah, we do need something like Hibernate, while Dvorm now is fairly 
stable API wise. It does abstract away pretty much everything about the 
database. As can be seen by having implemented POP3 and SMTP as a 
database provider (for EmailMessage model and only that one).


 Support for mongo is... cute?!, don't get me wrong it has a place, for
 most apps it would be fine, it is however unusable for the apps i am
 involved in.

 Anything supported within vibe.d itself, is great, well thought out,
 well written, clean and easy to work with. And vibe.d makes wonderful
 use of D features in a productive way. vibe.d's documentation could be
 better.


Ugh, I'd rather Vibe was split up. Honestly? right now it is slower to 
be compiled than Cmsed with its testing projects which I might add has 
quite a bit of CTFE with it.


 Having to go outside of vibe.d for anything is often gritty, and that is
 what keeps me from using it. The oddities of being required to use
 vibe.d's sockets means libraries have to be ported to the extend of
 changing that(not hard, but maintaining a changeset from the original
 authors code is cumbersome if they are not updating the lib, or if you
 would like to link it from another languages compiled code).

 That said if the database libraries could be brought up to snuff, one
 way or another everything else could be worked around for the most part.
Jul 08 2014
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 09.07.2014 03:54, schrieb luminousone:

 There is lots of missing little bits here and their, password hashing
 functions that use crypt_(C) formated hashes.


I was hoping for dauth [1] to fill that gap. It doesn't use the same 
format, but one with the same goal. I didn't actually try it out yet, 
though.


 There are diet/jade template bugs still, specific major problem being
 that use of single quotes inside of double quotes when i need to pass
 strings to js functions inside of js events such as onclick inside a
 html tag, seems to be broken.


Do you have a concrete example where this goes wrong? I've tested both, 
nesting ' inside " and vice versa. Both seemed to work fine for <body 
onLoad=...>.


 There is not common database interface for sql databases(forgivable
 actually), but many of the specific database libraries are messy(ddb for
 example) and they are not any where near api "stable".

 Support for mongo is... cute?!, don't get me wrong it has a place, for
 most apps it would be fine, it is however unusable for the apps i am
 involved in.


Yeah, I kind of like it for its flexibility, but it's definitely not the 
right choice for million user web services. I'm currently looking at 
NouDB as another potential SQL based target.

[1]: http://code.dlang.org/packages/dauth
Jul 09 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/9/2014 11:21 AM, Sönke Ludwig wrote:

 Am 09.07.2014 03:54, schrieb luminousone:

 There is lots of missing little bits here and their, password hashing
 functions that use crypt_(C) formated hashes.


 I was hoping for dauth [1] to fill that gap. It doesn't use the same
 format, but one with the same goal. I didn't actually try it out yet,
 though.


I admit I'm unfamiliar with this "crypt_(C) formated hashes", I'll look 
it up and try to support it. Anyone happen to have a link handy?

Also, if anyone has ANY issues/concerns/questions/anything about DAuth, 
PLEASE speak up or submit an issue at github. I want DAuth to work well 
for everyone :)

Speaking of DAuth future direction, I may as well mention this and open 
it for comment:

My plan ATM is to expand DAuth's scope a little, split it into about 
three main components (at different levels of abstraction) and rename to 
something less likely to be mistaken for an OAuth lib (DAuth is 
unrelated to OAuth).

I'm thinking of something like this:

"InstaUser Core": Basically what DAuth is now. Provides the two main 
primitives "Convert plaintext password to a salted hash" and "Validate 
plaintext password against a salted hash". Plus all the optional 
lower-level stuff like dealing with salts/hashes/etc directly, selecting 
hash algos directly, customized salted-hash formats, one-use tokens, etc.

"InstaUser Store": I've already started work on this locally. Basically 
a simple (compile-time, static linked) plugin architecture that provides 
basic user-management primitives (create user, change user's password, 
validate a password against a user, delete user, etc) with pluggable 
storage backends ("Stores") like MySQL. Various storage backends would 
be included.

"InstaUser Web": This would leverage vibe.d to provide an out-of-the-box 
working (and customizable) web-based register/login system. I expect 
that some applications may (or might not) outgrow this, but I think it 
would be fantastic for getting a login-based site off the ground and 
up-and-running. Or even just putting files (like webalyzer stats) behind 
a login that isn't "HTTP auth". I've written/maintained sooo many web 
login systems over the years I've gotten sick of reimplementing sooo 
many of the same things every time and backporting all newer 
improvements (Which is really the whole original reason I started DAuth 
in the first place).

An application can use *just* Core and omit the Store/Web stuff 
entirely. Or they can use it at the Store level. Or at the Web level. Or 
make direct use of all the levels.

Further in the future, "InstaUser" could possibly grow support for the 
"login in via Facebook/Gmail/OpenID/whatever" that seems to be popular 
now, or whatever other authentication systems may be useful.

"Destroy!"


 [1]: http://code.dlang.org/packages/dauth
Jul 09 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 09.07.2014 21:19, schrieb Nick Sabalausky:

 "InstaUser Web": This would leverage vibe.d to provide an out-of-the-box
 working (and customizable) web-based register/login system. I expect
 that some applications may (or might not) outgrow this, but I think it
 would be fantastic for getting a login-based site off the ground and
 up-and-running. Or even just putting files (like webalyzer stats) behind
 a login that isn't "HTTP auth". I've written/maintained sooo many web
 login systems over the years I've gotten sick of reimplementing sooo
 many of the same things every time and backporting all newer
 improvements (Which is really the whole original reason I started DAuth
 in the first place).

 An application can use *just* Core and omit the Store/Web stuff
 entirely. Or they can use it at the Store level. Or at the Web level. Or
 make direct use of all the levels.

 Further in the future, "InstaUser" could possibly grow support for the
 "login in via Facebook/Gmail/OpenID/whatever" that seems to be popular
 now, or whatever other authentication systems may be useful.


This was also exactly my idea with the "userman" [1] and "user-auth" [2] 
packages, although I didn't get very far with the "user-auth" part, yet. 
Maybe we can join forces there. (Please excuse the awfully creative 
names, I created a lot of packages at once at the time ;)

[1]: https://github.com/rejectedsoftware/userman
[2]: https://github.com/rejectedsoftware/user-auth
Jul 09 2014
prev sibling next sibling parent reply "luminousone" <rd.hunt gmail.com> writes:
On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:

 Am 09.07.2014 03:54, schrieb luminousone:

 There is lots of missing little bits here and their, password 
 hashing
 functions that use crypt_(C) formated hashes.


 I was hoping for dauth [1] to fill that gap. It doesn't use the 
 same format, but one with the same goal. I didn't actually try 
 it out yet, though.


 There are diet/jade template bugs still, specific major 
 problem being
 that use of single quotes inside of double quotes when i need 
 to pass
 strings to js functions inside of js events such as onclick 
 inside a
 html tag, seems to be broken.


 Do you have a concrete example where this goes wrong? I've 
 tested both, nesting ' inside " and vice versa. Both seemed to 
 work fine for <body onLoad=...>.


 There is not common database interface for sql 
 databases(forgivable
 actually), but many of the specific database libraries are 
 messy(ddb for
 example) and they are not any where near api "stable".

 Support for mongo is... cute?!, don't get me wrong it has a 
 place, for
 most apps it would be fine, it is however unusable for the 
 apps i am
 involved in.


 Yeah, I kind of like it for its flexibility, but it's 
 definitely not the right choice for million user web services. 
 I'm currently looking at NouDB as another potential SQL based 
 target.

 [1]: http://code.dlang.org/packages/dauth



hopefully, these posts are simply read as text, if not I can
figure out something else.




will always generate the following output,


Invoice</a>

class="menu_item">New Invoice</a>
Jul 09 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 09.07.2014 21:21, schrieb luminousone:

 On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:

 Am 09.07.2014 03:54, schrieb luminousone:

 There is lots of missing little bits here and their, password hashing
 functions that use crypt_(C) formated hashes.


 I was hoping for dauth [1] to fill that gap. It doesn't use the same
 format, but one with the same goal. I didn't actually try it out yet,
 though.


 There are diet/jade template bugs still, specific major problem being
 that use of single quotes inside of double quotes when i need to pass
 strings to js functions inside of js events such as onclick inside a
 html tag, seems to be broken.


 Do you have a concrete example where this goes wrong? I've tested
 both, nesting ' inside " and vice versa. Both seemed to work fine for
 <body onLoad=...>.


 There is not common database interface for sql databases(forgivable
 actually), but many of the specific database libraries are messy(ddb for
 example) and they are not any where near api "stable".

 Support for mongo is... cute?!, don't get me wrong it has a place, for
 most apps it would be fine, it is however unusable for the apps i am
 involved in.


 Yeah, I kind of like it for its flexibility, but it's definitely not
 the right choice for million user web services. I'm currently looking
 at NouDB as another potential SQL based target.

 [1]: http://code.dlang.org/packages/dauth



 hopefully, these posts are simply read as text, if not I can
 figure out something else.




 will always generate the following output,


 Invoice</a>

 class="menu_item">New Invoice</a>


That's right, but as far as I understand, it *should* work like that, 
because HTML character entity replacement should happen before parsing 
the JavaScript code, even if it's a little more verbose than it should be.
Jul 09 2014
parent reply "luminousone" <rd.hunt gmail.com> writes:
On Wednesday, 9 July 2014 at 19:51:38 UTC, Sönke Ludwig wrote:

 Am 09.07.2014 21:21, schrieb luminousone:

 On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:

 Am 09.07.2014 03:54, schrieb luminousone:

 There is lots of missing little bits here and their, 
 password hashing
 functions that use crypt_(C) formated hashes.


 I was hoping for dauth [1] to fill that gap. It doesn't use 
 the same
 format, but one with the same goal. I didn't actually try it 
 out yet,
 though.


 There are diet/jade template bugs still, specific major 
 problem being
 that use of single quotes inside of double quotes when i 
 need to pass
 strings to js functions inside of js events such as onclick 
 inside a
 html tag, seems to be broken.


 Do you have a concrete example where this goes wrong? I've 
 tested
 both, nesting ' inside " and vice versa. Both seemed to work 
 fine for
 <body onLoad=...>.


 There is not common database interface for sql 
 databases(forgivable
 actually), but many of the specific database libraries are 
 messy(ddb for
 example) and they are not any where near api "stable".

 Support for mongo is... cute?!, don't get me wrong it has a 
 place, for
 most apps it would be fine, it is however unusable for the 
 apps i am
 involved in.


 Yeah, I kind of like it for its flexibility, but it's 
 definitely not
 the right choice for million user web services. I'm currently 
 looking
 at NouDB as another potential SQL based target.

 [1]: http://code.dlang.org/packages/dauth



 hopefully, these posts are simply read as text, if not I can
 figure out something else.




 will always generate the following output,


 class="menu_item">New
 Invoice</a>

 class="menu_item">New Invoice</a>


 That's right, but as far as I understand, it *should* work like 
 that, because HTML character entity replacement should happen 
 before parsing the JavaScript code, even if it's a little more 
 verbose than it should be.


It breaks the js. And the character entity replacement only
effects text between tags, with the exception of the script tag
which also does not get characters replaced, the existing
"script." tag in diet templates works correctly. Text inside of
attributes is not ran through the character entity replacement.
Jul 09 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 10.07.2014 01:27, schrieb luminousone:

 On Wednesday, 9 July 2014 at 19:51:38 UTC, Sönke Ludwig wrote:

 Am 09.07.2014 21:21, schrieb luminousone:

 On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:

 Am 09.07.2014 03:54, schrieb luminousone:

 There is lots of missing little bits here and their, password hashing
 functions that use crypt_(C) formated hashes.


 I was hoping for dauth [1] to fill that gap. It doesn't use the same
 format, but one with the same goal. I didn't actually try it out yet,
 though.


 There are diet/jade template bugs still, specific major problem being
 that use of single quotes inside of double quotes when i need to pass
 strings to js functions inside of js events such as onclick inside a
 html tag, seems to be broken.


 Do you have a concrete example where this goes wrong? I've tested
 both, nesting ' inside " and vice versa. Both seemed to work fine for
 <body onLoad=...>.


 There is not common database interface for sql databases(forgivable
 actually), but many of the specific database libraries are
 messy(ddb for
 example) and they are not any where near api "stable".

 Support for mongo is... cute?!, don't get me wrong it has a place, for
 most apps it would be fine, it is however unusable for the apps i am
 involved in.


 Yeah, I kind of like it for its flexibility, but it's definitely not
 the right choice for million user web services. I'm currently looking
 at NouDB as another potential SQL based target.

 [1]: http://code.dlang.org/packages/dauth



 hopefully, these posts are simply read as text, if not I can
 figure out something else.




 will always generate the following output,


 Invoice</a>

 class="menu_item">New Invoice</a>


 That's right, but as far as I understand, it *should* work like that,
 because HTML character entity replacement should happen before parsing
 the JavaScript code, even if it's a little more verbose than it should
 be.


 It breaks the js. And the character entity replacement only
 effects text between tags, with the exception of the script tag
 which also does not get characters replaced, the existing
 "script." tag in diet templates works correctly. Text inside of
 attributes is not ran through the character entity replacement.


This is not true. See 
http://www.w3.org/html/wg/drafts/html/master/syntax.html#attributes-0
On which browser does it break the JS for you? It works for me, at least 
in Opera and Firefox.
Jul 09 2014
parent reply "luminousone" <rd.hunt gmail.com> writes:
On Thursday, 10 July 2014 at 00:02:23 UTC, Sönke Ludwig wrote:

 Am 10.07.2014 01:27, schrieb luminousone:

 On Wednesday, 9 July 2014 at 19:51:38 UTC, Sönke Ludwig wrote:

 Am 09.07.2014 21:21, schrieb luminousone:

 On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig 
 wrote:

 Am 09.07.2014 03:54, schrieb luminousone:

 There is lots of missing little bits here and their, 
 password hashing
 functions that use crypt_(C) formated hashes.


 I was hoping for dauth [1] to fill that gap. It doesn't use 
 the same
 format, but one with the same goal. I didn't actually try 
 it out yet,
 though.


 There are diet/jade template bugs still, specific major 
 problem being
 that use of single quotes inside of double quotes when i 
 need to pass
 strings to js functions inside of js events such as 
 onclick inside a
 html tag, seems to be broken.


 Do you have a concrete example where this goes wrong? I've 
 tested
 both, nesting ' inside " and vice versa. Both seemed to 
 work fine for
 <body onLoad=...>.


 There is not common database interface for sql 
 databases(forgivable
 actually), but many of the specific database libraries are
 messy(ddb for
 example) and they are not any where near api "stable".

 Support for mongo is... cute?!, don't get me wrong it has 
 a place, for
 most apps it would be fine, it is however unusable for the 
 apps i am
 involved in.


 Yeah, I kind of like it for its flexibility, but it's 
 definitely not
 the right choice for million user web services. I'm 
 currently looking
 at NouDB as another potential SQL based target.

 [1]: http://code.dlang.org/packages/dauth



 hopefully, these posts are simply read as text, if not I can
 figure out something else.




 will always generate the following output,


 class="menu_item">New
 Invoice</a>

 class="menu_item">New Invoice</a>


 That's right, but as far as I understand, it *should* work 
 like that,
 because HTML character entity replacement should happen 
 before parsing
 the JavaScript code, even if it's a little more verbose than 
 it should
 be.


 It breaks the js. And the character entity replacement only
 effects text between tags, with the exception of the script tag
 which also does not get characters replaced, the existing
 "script." tag in diet templates works correctly. Text inside of
 attributes is not ran through the character entity replacement.


 This is not true. See 
 http://www.w3.org/html/wg/drafts/html/master/syntax.html#attributes-0
 On which browser does it break the JS for you? It works for me, 
 at least in Opera and Firefox.


Chrome, When the links are clicked they simply don't do anything,
the load function is not called. And it doesn't seem to throw any
errors in chromes developer tools, which does seem odd.

Your link is for the html 5.1 draft spec, might this be different
dependent on the version of html being used?
Jul 09 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 10.07.2014 02:30, schrieb luminousone:

 he links are clicked they simply don't do anything,
 the load function is not called. And it doesn't seem to throw any
 errors in chromes devel


I'll test with Chrome. But the spec is the same in that regard for HTML 4:
http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
Jul 09 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 10.07.2014 02:58, schrieb Sönke Ludwig:

 Am 10.07.2014 02:30, schrieb luminousone:

 he links are clicked they simply don't do anything,
 the load function is not called. And it doesn't seem to throw any
 errors in chromes devel


 I'll test with Chrome. But the spec is the same in that regard for HTML 4:
 http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2




All of these work for the latest Chrome (as well as for Opera, Firefox 
and IE11):

<html><body>


&amp;quot;</a><br>


</body></html>
Jul 09 2014
parent "luminousone" <rd.hunt gmail.com> writes:
On Thursday, 10 July 2014 at 01:04:35 UTC, Sönke Ludwig wrote:

 Am 10.07.2014 02:58, schrieb Sönke Ludwig:

 Am 10.07.2014 02:30, schrieb luminousone:

 he links are clicked they simply don't do anything,
 the load function is not called. And it doesn't seem to throw 
 any
 errors in chromes devel


 I'll test with Chrome. But the spec is the same in that regard 
 for HTML 4:
 http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2




 All of these work for the latest Chrome (as well as for Opera, 
 Firefox and IE11):

 <html><body>



 &amp;quot;</a><br>


 </body></html>


Relooked over my code, and found issue else where, When I saw the
html special characters seemed so out of place and figured that
was it.
Jul 10 2014
prev sibling parent "luminousone" <rd.hunt gmail.com> writes:
On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:

 Am 09.07.2014 03:54, schrieb luminousone:

 There is lots of missing little bits here and their, password 
 hashing
 functions that use crypt_(C) formated hashes.


 I was hoping for dauth [1] to fill that gap. It doesn't use the 
 same format, but one with the same goal. I didn't actually try 
 it out yet, though.


 There are diet/jade template bugs still, specific major 
 problem being
 that use of single quotes inside of double quotes when i need 
 to pass
 strings to js functions inside of js events such as onclick 
 inside a
 html tag, seems to be broken.


 Do you have a concrete example where this goes wrong? I've 
 tested both, nesting ' inside " and vice versa. Both seemed to 
 work fine for <body onLoad=...>.


 There is not common database interface for sql 
 databases(forgivable
 actually), but many of the specific database libraries are 
 messy(ddb for
 example) and they are not any where near api "stable".

 Support for mongo is... cute?!, don't get me wrong it has a 
 place, for
 most apps it would be fine, it is however unusable for the 
 apps i am
 involved in.


 Yeah, I kind of like it for its flexibility, but it's 
 definitely not the right choice for million user web services. 
 I'm currently looking at NouDB as another potential SQL based 
 target.

 [1]: http://code.dlang.org/packages/dauth


I specifically work with data projects involving the EPA, Utah 
department of environmental quality, and county emissions 
programs in the State of Utah.

We have a few legacy projects that sit in Oracle, And everything 
else sits in mysql and postgresql. We would like to get 
everything onto just postgresql, minus the projects we can't move 
out of Oracle.

Our projects are spread across php/apache, and java/tomcat. I 
have been working to cut down the number of different 
technologies we use, or atleast to dump the really big train 
wreck ones aka, php and mysql.

Now oddly enough because we are a center at a university, I can 
get away with what some might consider "experimental", and use D 
and vibe.d, or at the very least whenever we have a one off demo 
of something I could use it for that.

I have been using mongodb for a few personal projects as I wanted 
to learn it, I am using it from vibe.d. Our largest dataset is 
1.5 million records per year going back to 1994~. Not terribly 
large but our clients run scientific queries on it. The queries 
they use pretty much preempts the use of non sql databases, so 
mongodb is out of the question, Tho I don't want to sound like I 
am being over discountive of what it can do.

I will look into NouSQL, assuming its not a memory database like 
voltdb, or some of the other NewSQL databases, it might be 
suitable.
Jul 10 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
wrote:

 "has anyone ever tied a real webservice to vibe.d?"


Yes and see no problems with it. Looks like author has very 
specific expectations of "webservice" concept and can't do a 
thing with 100%
Jul 09 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 9 July 2014 at 09:47:21 UTC, Dicebot wrote:

 On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
 wrote:

 "has anyone ever tied a real webservice to vibe.d?"


 Yes and see no problems with it. Looks like author has very 
 specific expectations of "webservice" concept and can't do a 
 thing with 100%


.. coverage of all utilities in the library. Sad he does not
provide some sample of missing bits. Most likely he has expected 
vibe.d to be exclusively web framework while it is generic 
networking / async framework.
Jul 09 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 9 July 2014 at 09:48:32 UTC, Dicebot wrote:

 On Wednesday, 9 July 2014 at 09:47:21 UTC, Dicebot wrote:

 On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
 wrote:

 "has anyone ever tied a real webservice to vibe.d?"


 Yes and see no problems with it. Looks like author has very 
 specific expectations of "webservice" concept and can't do a 
 thing with 100%


 .. coverage of all utilities in the library. Sad he does not
 provide some sample of missing bits. Most likely he has 
 expected vibe.d to be exclusively web framework while it is 
 generic networking / async framework.


Yeah, connection-based protocols are where UDS really shines for 
supporting seamless upgrades.  Transaction-based protocols like 
HTTP are much easier to deal with in this respect.
Jul 09 2014
prev sibling parent reply "w0rp" <devw0rp gmail.com> writes:
 From my usage of vibe.d thus far, I've found that it has a lot of 
things I want if I were to use it for building sites like the 
sites I build at work. vibe.d can offer excellent performance and 
scalability, and those are great building blocks to have for 
building a great web framework. I think what's missing from 
vibe.d lies in D code yet to be written which is required to get 
a decent level of productivity.

I am primarily a Django developer these days, and Django has some 
great features which boost my productivity massively. I'd want to 
see the same features, only written in a way more appropriate for 
D, in vibe.d. Here's a short list.

* An ORM, which absolutely must have a way to build queries a 
piece at a time without writing any SQL, like Django.
* A framework for generating all of the SQL required for database 
migrations like South or the built in migrations in Django 1.7, 
so you can quickly change any model.
* An API for creating form handlers, especially for creating 
instances of models in the ORM through forms. (Django Form and 
ModelForm)
* An HTML template system which doesn't eat memory at compile 
time and where changes can be made while the development server 
is running.

Those are the important "must have" points. Because of these 
features in Django, I can create a new feature for a website in 
the space of a couple of days, wildly restructure databases for 
optimisations etc. There are a few other tools I use in Django 
that are very nice to have.

* Django's automated testing framework lets you test pages with 
session data and email output, so I have tests for complex things 
like checkouts which are very easy to write. I pair it with a 
Jenkins module so I can use Jenkins locally for CI.
* The django-debug-toolbar module saves a ton of time when 
optimising queries. I use it for loading pages and looking at all 
of the queries run in a timeline with all of the EXPLAIN output 
right there. As a result I have massively improved query times at 
my job.
* The Django pipeline module provides mechanisms for generating 
JS and CSS. I now have SCSS which regenerates CSS automatically 
during development without needing a filesystem monitor like 
Compass, and I have cut load times on a couple of pages by a 
second each by merging JavaScript together. (Even without 
minification, which it supports, which I haven't gotten to yet.)

So there's my wishlist. I see it as a TODO list of things I or 
someone else should write. I'd be willing to contribute to a few 
of those points whenever I have time.
Jul 09 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/9/2014 3:05 PM, w0rp wrote:

 * An API for creating form handlers, especially for creating instances
 of models in the ORM through forms. (Django Form and ModelForm)


What I've started doing, and absolutely love so far, is to write my 
forms purely in the HTML template (with a little bit a custom 
tags/attributes), then use Adam's HTML DOM to read that HTML form and 
generate all the backend form-handing *from* the HTML form, including 
all the appropriate per-field "validation failed".

I'm finding this works a lot better than defining forms in the backend 
code and then trying to generate the HTML I want from that.


 * An HTML template system which doesn't eat memory at compile time and
 where changes can be made while the development server is running.


Mustache-D:

https://github.com/repeatedly/mustache-d

Unfortunately it *only* supports runtime processing right now, but it's 
a fairly nice little templating system. The claims of being "logicless" 
are total BS, but a *truly* logicless system would be useless anyway.
Jul 09 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 09/07/14 21:37, Nick Sabalausky wrote:


 What I've started doing, and absolutely love so far, is to write my
 forms purely in the HTML template (with a little bit a custom
 tags/attributes), then use Adam's HTML DOM to read that HTML form and
 generate all the backend form-handing *from* the HTML form, including
 all the appropriate per-field "validation failed".

 I'm finding this works a lot better than defining forms in the backend
 code and then trying to generate the HTML I want from that.


To me that sounds a bit backwards. I'm not exactly sure what you mean by 
"backend form-handling" but in Rails all ActiveRecord classes can take a 
hash (associative array) in the constructor. The keys will match the 
fields (columns) on the class and the constructor will automatically 
assign all fields with the given values. This is called mass-assignment.

The view uses appropriate names for the form fields, scoped in the same 
name as the model, like this:

<input type="text" name="person[name]" />

So the only thing you need to do in the controller is something like this:

def create
   user = User.new(params[:user])
   user.save
end

In the view you use a form builder:

= simple_form_for  user do |f| do
   = f.input :name
   = f.input :admin
   = f.association :role
   = f.button :submit

Here I'm using a plugin called SimpleForm, it will automatically render 
the correct input form type based on the column type in the database. 
"name" will be render as a text input. "admin" will be render as a 
checkbox (since it's a boolean). It will also add labels and similar 
things. It can also generate all necessary code to be compatible with 
Bootstrap.

"f.association :role" is quite interesting. This expects there to be an 
association to the Role model in the User model. It will render a select 
tag populated with all the rows from the Role table.

The validation is handled in the model, where it belongs, when "save" is 
called in the controller. There's also a plugin that will automatically 
add JavaScript validations. It has duplicated the standard Rails 
validators in JavaScript. It will inspect the model, choose the correct 
validator and add it when rendering the view.

-- 
/Jacob Carlborg
Jul 10 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 10 July 2014 at 07:56:43 UTC, Jacob Carlborg wrote:

 To me that sounds a bit backwards.


I can go both ways, depending on the design of the form and how 
many helper tags we decide to use for the project.

My dom library doesn't dictate how you do it, of course, it just 
provides access to the html structure and has functions to help 
build one. But among the functions I've written for this are:

createAutomaticForm, which is found in my web.d module. It takes 
a D function signature and creates a form to call it, using 
static type info to generate the appropriate inputs.

This is a really old demo but still shows the principles:

http://arsdnet.net/cgi-bin/apidemo/add-some-numbers

That form is generated from "int addSomeNumbers(int a, int b);" 
The URL routing, field names, and types are pulled out of the 
identifiers used in D.

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

This one is "Element getABox(Color color);" with "enum Color { 
list here... }". Enums are rendered as <select>.



I find this is really convenient to quickly throw something up 
(web.d will do it automatically for any exported function that 
doesn't have a custom form function), but real web designs tend 
to need more flexibility so it doesn't do everything.


I have three other solutions too:

1) Just write the HTML form manually and fill it in with dom 
helper functions. This has become my preference in a lot of 
cases, it is really easy.

<form id="foo">
   <input type="text" name="field" />
   <textarea name="other"></textarea>
   <select name="auto_list" 
data-options-from="some_backend_item"></select>
   <select name="list">
      <option value="whatever">Cool</option>
   </select>
</form>

And so on and so forth. A lot of people don't like html, but I 
don't mind it at all; especially once you start using html5 
attributes, it is fairly concise for this stuff.

Another thing I like with this is the designer can write it with 
just a plain browser, no need for the whole backend 
infrastructure just to see some quick tweaks. Helps a lot when 
they are working offline too.

Filling data is easy. Either use the functions directly:

auto form = document.requireSelector!Form("#foo");

foreach(k, v; your_data)
    form.setValue(k, v);


Or, if you are using my database.d with dom.d, relatively recent 
versions include a fillForm function:

fillForm(form, your_object, "object_name"); // object_name is 
used if the function takes a struct rather than individual items 
- another relatively new feature


To fill in data from a form, you can most easily use my 
DataObject class from database.d which doesn't take a hash 
constructor like Ruby but with foreach, it is close enough:

auto obj = new DataObject(db, "table"); // you could subclass it 
for a specific table, database.d even has functions to generate 
those classes from MySQL CREATE TABLE declarations automatically

foreach(k, v; cgi.post)
    obj[k] = v;

or you could easily enough list the expected keys in that filling 
loop, kinda like the Rails strong params (as I understand them - 
rails is now my day job but I'm still a bit of a n00b).



Filling the form data and generating the model updates was the 
most painful part of writing PHP IMO, so dom.d made them all 
stupid simple. Now I don't feel the need for form helpers, the 
DOM is smart enough to fill in the gaps from whatever it is given.

dom.d also has a function to get a value hash out of a form but I 
never actually used it. Maybe with local imports, I can make that 
smarter and selectively depend on cgi.d to actually have it cool. 
I gotta come back to this stuff some day.


2) Generate the HTML with the DOM library along with helper D 
functions to ensure more consistency.

auto form = cast(Form) Element.make("form");

form.addField("name", "value", [options]);

addField has several overloads that pick the right HTML to make 
from a given data type. It generates consistent HTML for labels 
and spans so it is easy to style with CSS.

But since this is D, it is a bit harder to pass to a HTML guy to 
edit the design. Otherwise though, dom.d's helper functions make 
all kinds of manipulations really easy and it is tempting to use 
more than I probably should.


3) Some hybrid, where you use custom tags in the HTML which are 
run. dom.d's more recent versions also include passing <%= %> and 
similar tags to a handler, if we really wanted to, we could use 
scripts there as well as custom tags and data attributes to fill 
things in.

Early on, I used a LOT of custom tags, but nowadays I prefer to 
stick to mostly standard HTML so it works better stand alone.


 The view uses appropriate names for the form fields, scoped in 
 the same name as the model, like this:


Yeah, that's pretty nice. database.d's fillData (on which dom.d's 
fillForm is based and web.d does the same for struct arguments) 
just uses dots:

name="person.name"

which would fill the

void handler(Person person);

person.name field there. Then you do person.toDatabaseObject (an 
auto-generated function btw) to get a SQL builder class out of it 
and modify it if you want then finally just 
person.commitChanges(); which is like Rails' .save!

Perhaps I'll make the mixin just throw in a save method at some 
point too.



This stuff is fairly new and underdocumented/advertised, even my 
by lax standards. I think this is the first time I've even talked 
about it on the forums.


tbh from what I've seen, my collection of stuff is closer to the 
"full web framework" than vibe.d itself - as we discussed a 
couple months ago, I also have my SASS like css expander (which 
unlike the real sass doesn't need the rest of your life to 
recompile after any trivial change... though it is admittably 
still slow for D), javascript expanders and generators, various 
SQL backends, the list goes on.
Jul 10 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 10 July 2014 at 13:42:30 UTC, Adam D. Ruppe wrote:

 On Thursday, 10 July 2014 at 07:56:43 UTC, Jacob Carlborg wrote:

 To me that sounds a bit backwards.


 I can go both ways, depending on the design of the form and how 
 many helper tags we decide to use for the project.

 My dom library doesn't dictate how you do it, of course, it 
 just provides access to the html structure and has functions to 
 help build one. But among the functions I've written for this 
 are:

 createAutomaticForm, which is found in my web.d module. It 
 takes a D function signature and creates a form to call it, 
 using static type info to generate the appropriate inputs.

 This is a really old demo but still shows the principles:

 http://arsdnet.net/cgi-bin/apidemo/add-some-numbers

 That form is generated from "int addSomeNumbers(int a, int b);" 
 The URL routing, field names, and types are pulled out of the 
 identifiers used in D.

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

 This one is "Element getABox(Color color);" with "enum Color { 
 list here... }". Enums are rendered as <select>.



 I find this is really convenient to quickly throw something up 
 (web.d will do it automatically for any exported function that 
 doesn't have a custom form function), but real web designs tend 
 to need more flexibility so it doesn't do everything.


 I have three other solutions too:

 1) Just write the HTML form manually and fill it in with dom 
 helper functions. This has become my preference in a lot of 
 cases, it is really easy.

 <form id="foo">
   <input type="text" name="field" />
   <textarea name="other"></textarea>
   <select name="auto_list" 
 data-options-from="some_backend_item"></select>
   <select name="list">
      <option value="whatever">Cool</option>
   </select>
 </form>

 And so on and so forth. A lot of people don't like html, but I 
 don't mind it at all; especially once you start using html5 
 attributes, it is fairly concise for this stuff.

 Another thing I like with this is the designer can write it 
 with just a plain browser, no need for the whole backend 
 infrastructure just to see some quick tweaks. Helps a lot when 
 they are working offline too.

 Filling data is easy. Either use the functions directly:

 auto form = document.requireSelector!Form("#foo");

 foreach(k, v; your_data)
    form.setValue(k, v);


 Or, if you are using my database.d with dom.d, relatively 
 recent versions include a fillForm function:

 fillForm(form, your_object, "object_name"); // object_name is 
 used if the function takes a struct rather than individual 
 items - another relatively new feature


 To fill in data from a form, you can most easily use my 
 DataObject class from database.d which doesn't take a hash 
 constructor like Ruby but with foreach, it is close enough:

 auto obj = new DataObject(db, "table"); // you could subclass 
 it for a specific table, database.d even has functions to 
 generate those classes from MySQL CREATE TABLE declarations 
 automatically

 foreach(k, v; cgi.post)
    obj[k] = v;

 or you could easily enough list the expected keys in that 
 filling loop, kinda like the Rails strong params (as I 
 understand them - rails is now my day job but I'm still a bit 
 of a n00b).



 Filling the form data and generating the model updates was the 
 most painful part of writing PHP IMO, so dom.d made them all 
 stupid simple. Now I don't feel the need for form helpers, the 
 DOM is smart enough to fill in the gaps from whatever it is 
 given.

 dom.d also has a function to get a value hash out of a form but 
 I never actually used it. Maybe with local imports, I can make 
 that smarter and selectively depend on cgi.d to actually have 
 it cool. I gotta come back to this stuff some day.


 2) Generate the HTML with the DOM library along with helper D 
 functions to ensure more consistency.

 auto form = cast(Form) Element.make("form");

 form.addField("name", "value", [options]);

 addField has several overloads that pick the right HTML to make 
 from a given data type. It generates consistent HTML for labels 
 and spans so it is easy to style with CSS.

 But since this is D, it is a bit harder to pass to a HTML guy 
 to edit the design. Otherwise though, dom.d's helper functions 
 make all kinds of manipulations really easy and it is tempting 
 to use more than I probably should.


 3) Some hybrid, where you use custom tags in the HTML which are 
 run. dom.d's more recent versions also include passing <%= %> 
 and similar tags to a handler, if we really wanted to, we could 
 use scripts there as well as custom tags and data attributes to 
 fill things in.

 Early on, I used a LOT of custom tags, but nowadays I prefer to 
 stick to mostly standard HTML so it works better stand alone.


 The view uses appropriate names for the form fields, scoped in 
 the same name as the model, like this:


 Yeah, that's pretty nice. database.d's fillData (on which 
 dom.d's fillForm is based and web.d does the same for struct 
 arguments) just uses dots:

 name="person.name"

 which would fill the

 void handler(Person person);

 person.name field there. Then you do person.toDatabaseObject 
 (an auto-generated function btw) to get a SQL builder class out 
 of it and modify it if you want then finally just 
 person.commitChanges(); which is like Rails' .save!

 Perhaps I'll make the mixin just throw in a save method at some 
 point too.



 This stuff is fairly new and underdocumented/advertised, even 
 my by lax standards. I think this is the first time I've even 
 talked about it on the forums.


 tbh from what I've seen, my collection of stuff is closer to 
 the "full web framework" than vibe.d itself - as we discussed a 
 couple months ago, I also have my SASS like css expander (which 
 unlike the real sass doesn't need the rest of your life to 
 recompile after any trivial change... though it is admittably 
 still slow for D), javascript expanders and generators, various 
 SQL backends, the list goes on.


Would you be interested in putting a web development framework 
(or parts of it) together we can tie in with vibe.d?
Jul 10 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 10 July 2014 at 13:55:14 UTC, Chris wrote:

 Would you be interested in putting a web development framework 
 (or parts of it) together we can tie in with vibe.d?


Meh, not really. I've never used vibe.d so getting started is at 
least a psychological hurdle and I have a lot of other things to 
do too. I have considered doing a vibe backend for cgi.d before, 
which should be possible and maybe not even too hard, but just 
not far up on my priority list.

Many of my modules are made to stand alone though. Pulling dom.d 
in should be really easy, maybe database.d too (though since it 
uses C libraries to talk to the db server, it would probably 
cause problems with vibe's fibers; the queries would block the 
whole server).

web.d is really ugly code, it was my first serious usage of D's 
reflection and while it works, I'd love to rewrite it some day. I 
think I'd prefer to do web.d 2.0 before doing the vibe stuff.
Jul 10 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 10 July 2014 at 14:50:50 UTC, Adam D. Ruppe wrote:

 On Thursday, 10 July 2014 at 13:55:14 UTC, Chris wrote:

 Would you be interested in putting a web development framework 
 (or parts of it) together we can tie in with vibe.d?


 Meh, not really. I've never used vibe.d so getting started is 
 at least a psychological hurdle and I have a lot of other 
 things to do too. I have considered doing a vibe backend for 
 cgi.d before, which should be possible and maybe not even too 
 hard, but just not far up on my priority list.

 Many of my modules are made to stand alone though. Pulling 
 dom.d in should be really easy, maybe database.d too (though 
 since it uses C libraries to talk to the db server, it would 
 probably cause problems with vibe's fibers; the queries would 
 block the whole server).

 web.d is really ugly code, it was my first serious usage of D's 
 reflection and while it works, I'd love to rewrite it some day. 
 I think I'd prefer to do web.d 2.0 before doing the vibe stuff.


I see.
Jul 10 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/10/2014 10:50 AM, Adam D. Ruppe wrote:

 maybe database.d too (though since it uses C
 libraries to talk to the db server, it would probably cause problems
 with vibe's fibers; the queries would block the whole server).


All you should really need to do is replace usage of Phobos's socket 
type with Vibe.d's socket type. There's a slight difference in API, but 
there are plans for a wrapper to handle those differences automatically:

https://github.com/rejectedsoftware/vibe.d/issues/702
Jul 10 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 10 July 2014 at 18:10:52 UTC, Nick Sabalausky wrote:

 All you should really need to do is replace usage of Phobos's 
 socket type with Vibe.d's socket type.


The problem is they don't use Phobos' socket type. All my 
database modules just use the vendor's C library, like mysql.d 
does mysql_query and mysql_connect etc. postgres.d uses libpq, 
and so on.
Jul 10 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/10/2014 9:42 AM, Adam D. Ruppe wrote:

 Another thing I like with this is the designer can write it with just a
 plain browser, no need for the whole backend infrastructure just to see
 some quick tweaks. Helps a lot when they are working offline too.


For awhile I tried to do things in a way that a designer (or me) could 
load up the (html | html templates) directly in a browser and see 
exactly how it would look, but I kept running into the problem of common 
page elements. Common headers, common footers, common CSS imports, etc. 
I couldn't come up with a reasonable solution to that, so I gave up on 
the idea and decided I'd rather just help any designers get a local 
build set up.

Any insight on that issue?
Jul 10 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 10 July 2014 at 18:05:35 UTC, Nick Sabalausky wrote:

 Common headers, common footers, common CSS imports, etc.


The way I do it is every html file is a full tree, so there isn't 
really a common header/footer and instead a common skeleton. So 
we'd have

skeleton.html
<html><head> all that stuff </head>
<body>
   header
   <div id="content-container"></div>
   footer
</body></html>

All as a single file. Then each page would be a file that 
contains a div and the content.

To view a whole page, you simply paste that code into the 
#content-container on the main page, which can be done with a 
javascript request easily enough, or just plain text editor 
copy/paste, and move it back into the independent file when 
finished with it.
Jul 10 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/10/2014 2:28 PM, Adam D. Ruppe wrote:

 On Thursday, 10 July 2014 at 18:05:35 UTC, Nick Sabalausky wrote:

 Common headers, common footers, common CSS imports, etc.


 The way I do it is every html file is a full tree, so there isn't really
 a common header/footer and instead a common skeleton. So we'd have

 skeleton.html
 <html><head> all that stuff </head>
 <body>
    header
    <div id="content-container"></div>
    footer
 </body></html>

 All as a single file. Then each page would be a file that contains a div
 and the content.

 To view a whole page, you simply paste that code into the
 #content-container on the main page, which can be done with a javascript
 request easily enough, or just plain text editor copy/paste, and move it
 back into the independent file when finished with it.


Hmm, a little more manual-effort than I'd have hoped for, although 
maybe, as you suggest, JS can be used to improve that. Hadn't thought of 
that.
Jul 10 2014
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 9 July 2014 at 19:05:54 UTC, w0rp wrote:

 * An ORM, which absolutely must have a way to build queries a 
 piece at a time without writing any SQL, like Django.


I'm skeptical of the benefit of full ORM, but my database.d goes 
to the point I believe is useful with two classes (and a few 
helper functions): DataObject, which allows easy inspection and 
setting of individual items and SelectBuilder which just builds a 
query.


 * A framework for generating all of the SQL required for 
 database migrations like South or the built in migrations in 
 Django 1.7, so you can quickly change any model.


I never did this automatically, I just wrote change files in sql 
myself before taking the RoR job... and personally I think Rails 
migrations aren't all that great, but it is nice that they are 
standardized; I can do the rails g migration here and the boss 
can shoot it up to heroku and it all usually just works.


 * An API for creating form handlers, especially for creating 
 instances of models in the ORM through forms. (Django Form and 
 ModelForm)


see my other email


 * An HTML template system which doesn't eat memory at compile 
 time and where changes can be made while the development server 
 is running.


I've thought about using dom.d at compile time, it now works 
there and could potentially do static checks on html 
well-formedness, broken links, correct field names, etc. But I 
never actually bothered, instead it just loads the file - 
convenient for tweaks by the rest of the team without recompiling 
anyway!


 * Django's automated testing framework lets you test pages with 
 session data and email output, so I have tests for complex 
 things like checkouts which are very easy to write.


I've done nothing like that. I kinda like this thing one of my 
rails coworkers pointed me toward there though called capybara. 
You fetch pages and tell it to click on buttons to do integration 
tests on html. It'd be almost trivial to do that with my cgi.d 
and dom.d - cgi.d already includes simulated requests (for 
command line testing, you run the binary like ./my_server GET 
/foo bar=baz and it runs the program with the given arguments) 
and dom.d can easily click/inspect the output.

But I haven't actually done it.


 * The Django pipeline module provides mechanisms for generating 
 JS and CSS. I now have SCSS which regenerates CSS automatically 
 during development


I've been using scss for the Rails job and I like that it has 
similar functionality to my own css expander (in html.d on my 
misc github, also now as a separate dub package called 
cssexpand), but I can't stand how BRUTALLY slow it is.

Some of the features it offers over cssexpand are kinda cool, but 
if the price is that high, it just isn't worth it. I'll stick to 
my simple nesting expansion and text macro replacement.
Jul 10 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
 Adam

At the moment, I'm looking into web development frameworks (from 
Foundation to CMSes to sever side solutions etc.), because in the 
months / years to come we (as in "the team I work in") will need 
a solid website.

Ideally, it would be PHP-free and not need much Javascript 
development (with Foundation you get some cool stuff via jQuery 
without having to bother with JS too much).

Your work on dom.d and web.d are a good starting point. What 
keeps me from using vibe.d + dom.d + web.d is the fact that it 
wouldn't be easy to transfer the tasks to someone who doesn't 
know D (= 99% of all web developers, I suppose). I cannot expect 
a web guy to learn D. However, I don't want to go down the same 
old PHP path again. PHP is inherently messy.*

*(How about interpreting JS through D as a server side language? 
Or something similar. Just thinking aloud).
Jul 10 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 10 July 2014 at 14:15:19 UTC, Chris wrote:

 I cannot expect a web guy to learn D.


Why not? Most my actual usage code looks close enough to Java and 
sometimes even PHP that I think someone should be able to learn 
it easily enough to be useful...


 *(How about interpreting JS through D as a server side 
 language? Or something similar. Just thinking aloud).


That kind of thing is possible, but it seems to me that if you 
are writing the code in javascript anyway you might as well just 
use one of the established players like node for that.
Jul 10 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-07-10 15:53, Adam D. Ruppe wrote:


 I never did this automatically, I just wrote change files in sql myself
 before taking the RoR job... and personally I think Rails migrations
 aren't all that great, but it is nice that they are standardized; I can
 do the rails g migration here and the boss can shoot it up to heroku and
 it all usually just works.


And they are database independent, mostly.


 I've done nothing like that. I kinda like this thing one of my rails
 coworkers pointed me toward there though called capybara. You fetch
 pages and tell it to click on buttons to do integration tests on html.


Capybara is more for user acceptances tests. Rails has other kinds of 
tests that are a bit lower for integration tests. But the line is thin.


 It'd be almost trivial to do that with my cgi.d and dom.d - cgi.d
 already includes simulated requests (for command line testing, you run
 the binary like ./my_server GET /foo bar=baz and it runs the program
 with the given arguments) and dom.d can easily click/inspect the output.


It depends. Capybara is only a high level API. It supports multiple 
drivers: Rack Test (the default one), Selenium, PhantomJS and others. 
Rack Test is the most simple one but also the fastest. PhantomJS is a 
completely headless driver which uses WebKit. Selenium is the most 
flexible one. By default it's not headless and uses Firefox. But it can 
be configured, using some kind of hub, to support multiple browsers and 
headless as well. The major advantage of PhantomJS and  Selenium is that 
they're release browsers and supports JavaScript.


 I've been using scss for the Rails job and I like that it has similar
 functionality to my own css expander (in html.d on my misc github, also
 now as a separate dub package called cssexpand), but I can't stand how
 BRUTALLY slow it is.


That's heavily dependent on how large project you have, how much Sass 
you've got. Preprocessing with Ruby as well will be slower.

Just a side note, the assets pipeline is extremely slow in a VirtualBox 
compared to a native machine. We had some problems with that at my 
previous work. Apparently the assets pipeline needs to access a lot of 
files on disk, and each access took around a second.

-- 
/Jacob Carlborg
Jul 10 2014
prev sibling parent reply "Poyeyo" <poyeyo arcadechaser.com> writes:
On Wednesday, 9 July 2014 at 19:05:54 UTC, w0rp wrote:

 * An ORM, which absolutely must have a way to build queries a 
 piece at a time without writing any SQL, like Django.
 * A framework for generating all of the SQL required for 
 database migrations like South or the built in migrations in 
 Django 1.7, so you can quickly change any model.


I am a Laravel developer, that's PHP inspired in Rails and 
Django. It has migrations, a query builder, ORM, form generators, 
etc.

However, well before we get to 'I want an ORM' stage, there are 
many things to be done first, as a DB foundation layer:

- Unified database API. For PHP is the PDO objects, for java is 
JDBC, it would be great to have a D DB standard set of objects, 
it should have database, table, rowset, row, field objects. They 
should not be part of a particular DB driver implementation. 
Rationale: I can change one single line in a laravel 
configuration file, rerun the migrations and seeds and have my 
system working in a different DB platform than before. It just 
works.

- A way to use all available SQL data types. I deal with money 
data, stored as DECIMAL (30,4). The Mysql driver throws an 
exception when I try to execute a query that reads DECIMAL data. 
This makes the whole D platform a non-starter for the company I 
work for.
Jul 10 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 11 July 2014 at 00:36:26 UTC, Poyeyo wrote:

 - Unified database API.


My database.d provides a simple one. An interface for databases 
that do string queries and returns result interfaces which can be 
looped over and returns the returned data as strings too.

Strings were a simple hack at first, but I actually like it well 
enough that now it is just what I'm going with.


 - A way to use all available SQL data types. I deal with money 
 data, stored as DECIMAL (30,4). The Mysql driver throws an 
 exception when I try to execute a query that reads DECIMAL 
 data. This makes the whole D platform a non-starter for the 
 company I work for.


My approach of just using sql with helper builders should handle 
that...
Jul 10 2014