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. a.menu_item(href='#', onclick='load("invoice");') New Invoice a.menu_item(href='#', onclick="load('invoice');") New Invoice will always generate the following output, <a href="#" onclick="load(&quot;a&quot;);" class="menu_item">New Invoice</a> <a href="#" onclick="load(&#39;invoice&#39;);" 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. a.menu_item(href='#', onclick='load("invoice");') New Invoice a.menu_item(href='#', onclick="load('invoice');") New Invoice will always generate the following output, <a href="#" onclick="load(&quot;a&quot;);" class="menu_item">New Invoice</a> <a href="#" onclick="load(&#39;invoice&#39;);" 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. a.menu_item(href='#', onclick='load("invoice");') New Invoice a.menu_item(href='#', onclick="load('invoice');") New Invoice will always generate the following output, <a href="#" onclick="load(&quot;a&quot;);" class="menu_item">New Invoice</a> <a href="#" onclick="load(&#39;invoice&#39;);" 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. a.menu_item(href='#', onclick='load("invoice");') New Invoice a.menu_item(href='#', onclick="load('invoice');") New Invoice will always generate the following output, <a href="#" onclick="load(&quot;a&quot;);" class="menu_item">New Invoice</a> <a href="#" onclick="load(&#39;invoice&#39;);" 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. a.menu_item(href='#', onclick='load("invoice");') New Invoice a.menu_item(href='#', onclick="load('invoice');") New Invoice will always generate the following output, <a href="#" onclick="load(&quot;a&quot;);" class="menu_item">New Invoice</a> <a href="#" onclick="load(&#39;invoice&#39;);" 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 It even explicitly mentions escaping of &quot; and &#39;
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 It even explicitly mentions escaping of &quot; and &#39;
All of these work for the latest Chrome (as well as for Opera, Firefox and IE11): <html><body> <a href="#" onClick="alert(&#39;Hello, World!&#39;)">Using &amp;#39;</a><br> <a href="#" onClick="alert(&quot;Hello, World!&quot;)">Using &amp;quot;</a><br> <a href="#" onClick="alert('Hello, World!')">Using '</a><br> <a href="#" onClick='alert("Hello, World!")'>Using "</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 It even explicitly mentions escaping of &quot; and &#39;
All of these work for the latest Chrome (as well as for Opera, Firefox and IE11): <html><body> <a href="#" onClick="alert(&#39;Hello, World!&#39;)">Using &amp;#39;</a><br> <a href="#" onClick="alert(&quot;Hello, World!&quot;)">Using &amp;quot;</a><br> <a href="#" onClick="alert('Hello, World!')">Using '</a><br> <a href="#" onClick='alert("Hello, World!")'>Using "</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