Discussion:
critique of vibe.d
(too old to reply)
Andrei Alexandrescu via Digitalmars-d
2014-07-08 20:39:23 UTC
Permalink
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
via Digitalmars-d
2014-07-08 21:30:14 UTC
Permalink
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
Post by Andrei Alexandrescu via Digitalmars-d
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

Puming via Digitalmars-d
2014-07-09 01:09:09 UTC
Permalink
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
Post by Andrei Alexandrescu via Digitalmars-d
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)
"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
Puming via Digitalmars-d
2014-07-09 01:32:59 UTC
Permalink
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/>
Post by Puming via Digitalmars-d
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
Post by Andrei Alexandrescu via Digitalmars-d
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)
"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
Sean Kelly via Digitalmars-d
2014-07-09 15:26:16 UTC
Permalink
Post by Puming via Digitalmars-d
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.
Sönke Ludwig via Digitalmars-d
2014-07-09 16:16:49 UTC
Permalink
Post by Sean Kelly via Digitalmars-d
Post by Puming via Digitalmars-d
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
Johannes Pfau via Digitalmars-d
2014-07-09 17:03:28 UTC
Permalink
Am Wed, 09 Jul 2014 18:16:49 +0200
Post by Sönke Ludwig via Digitalmars-d
Post by Sean Kelly via Digitalmars-d
Post by Puming via Digitalmars-d
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?

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.
Dicebot via Digitalmars-d
2014-07-09 17:28:42 UTC
Permalink
Post by Johannes Pfau via Digitalmars-d
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.
Johannes Pfau via Digitalmars-d
2014-07-09 21:05:32 UTC
Permalink
Am Wed, 09 Jul 2014 17:28:42 +0000
Post by Dicebot via Digitalmars-d
Post by Johannes Pfau via Digitalmars-d
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.
Dicebot via Digitalmars-d
2014-07-10 10:24:22 UTC
Permalink
Post by Johannes Pfau via Digitalmars-d
Am Wed, 09 Jul 2014 17:28:42 +0000
Post by Dicebot via Digitalmars-d
Post by Johannes Pfau via Digitalmars-d
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.
Chris via Digitalmars-d
2014-07-10 10:35:18 UTC
Permalink
Post by Dicebot via Digitalmars-d
Post by Johannes Pfau via Digitalmars-d
Am Wed, 09 Jul 2014 17:28:42 +0000
On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau
Post by Johannes Pfau via Digitalmars-d
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");
}
Sönke Ludwig via Digitalmars-d
2014-07-09 18:34:49 UTC
Permalink
Post by Johannes Pfau via Digitalmars-d
Am Wed, 09 Jul 2014 18:16:49 +0200
Post by Sönke Ludwig via Digitalmars-d
Post by Sean Kelly via Digitalmars-d
Post by Puming via Digitalmars-d
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
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.
Post by Johannes Pfau via Digitalmars-d
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
Johannes Pfau via Digitalmars-d
2014-07-09 21:12:15 UTC
Permalink
Am Wed, 09 Jul 2014 20:34:49 +0200
Post by Sönke Ludwig via Digitalmars-d
Post by Johannes Pfau via Digitalmars-d
Am Wed, 09 Jul 2014 18:16:49 +0200
Post by Sönke Ludwig via Digitalmars-d
Post by Sean Kelly via Digitalmars-d
Post by Puming via Digitalmars-d
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
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.
Post by Johannes Pfau via Digitalmars-d
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 ;-)
Rikki Cattermole via Digitalmars-d
2014-07-10 04:14:54 UTC
Permalink
Post by Johannes Pfau via Digitalmars-d
Am Wed, 09 Jul 2014 20:34:49 +0200
Post by Sönke Ludwig via Digitalmars-d
Post by Johannes Pfau via Digitalmars-d
Am Wed, 09 Jul 2014 18:16:49 +0200
Post by Sönke Ludwig via Digitalmars-d
Post by Sean Kelly via Digitalmars-d
Post by Puming via Digitalmars-d
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
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.
Post by Johannes Pfau via Digitalmars-d
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.
Jacob Carlborg via Digitalmars-d
2014-07-10 20:33:43 UTC
Permalink
Post by Sönke Ludwig via Digitalmars-d
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
Etienne via Digitalmars-d
2014-07-09 19:45:42 UTC
Permalink
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 :)
Rikki Cattermole via Digitalmars-d
2014-07-09 04:17:29 UTC
Permalink
Post by Puming via Digitalmars-d
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].
Post by Puming via Digitalmars-d
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!
Post by Puming via Digitalmars-d
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.
Post by Puming via Digitalmars-d
Post by Andrei Alexandrescu via Digitalmars-d
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)
"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
Dicebot via Digitalmars-d
2014-07-09 09:55:07 UTC
Permalink
Post by Puming via Digitalmars-d
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.
Sean Kelly via Digitalmars-d
2014-07-09 15:17:02 UTC
Permalink
Post by Puming via Digitalmars-d
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.
Sönke Ludwig via Digitalmars-d
2014-07-09 16:14:55 UTC
Permalink
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).
Tavi Cacina via Digitalmars-d
2014-07-09 19:43:04 UTC
Permalink
Post by Sean Kelly via Digitalmars-d
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.
Nick Sabalausky via Digitalmars-d
2014-07-09 01:13:38 UTC
Permalink
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
Post by Andrei Alexandrescu via Digitalmars-d
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)
"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.
Post by Andrei Alexandrescu via Digitalmars-d
Andrei
Puming via Digitalmars-d
2014-07-09 01:35:47 UTC
Permalink
Post by via Digitalmars-d
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
Post by Andrei Alexandrescu via Digitalmars-d
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)
"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.
Post by via Digitalmars-d
Post by Andrei Alexandrescu via Digitalmars-d
Andrei
Chris via Digitalmars-d
2014-07-09 14:49:29 UTC
Permalink
Post by Puming via Digitalmars-d
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.
Nick Sabalausky via Digitalmars-d
2014-07-09 18:34:09 UTC
Permalink
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"?
Jacob Carlborg via Digitalmars-d
2014-07-10 07:11:33 UTC
Permalink
Post by Nick Sabalausky via Digitalmars-d
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
luminousone via Digitalmars-d
2014-07-09 01:54:10 UTC
Permalink
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
Post by Andrei Alexandrescu via Digitalmars-d
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)
"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.
Rikki Cattermole via Digitalmars-d
2014-07-09 04:23:30 UTC
Permalink
Post by Andrei Alexandrescu via Digitalmars-d
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)
"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.
Sönke Ludwig via Digitalmars-d
2014-07-09 15:21:46 UTC
Permalink
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
Nick Sabalausky via Digitalmars-d
2014-07-09 19:19:14 UTC
Permalink
Post by Sönke Ludwig via Digitalmars-d
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!"
Post by Sönke Ludwig via Digitalmars-d
[1]: http://code.dlang.org/packages/dauth
Sönke Ludwig via Digitalmars-d
2014-07-09 19:48:20 UTC
Permalink
Post by Nick Sabalausky via Digitalmars-d
"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
luminousone via Digitalmars-d
2014-07-09 19:21:07 UTC
Permalink
Post by Sönke Ludwig via Digitalmars-d
Post by luminousone via Digitalmars-d
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.
Post by luminousone via Digitalmars-d
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=...>.
Post by luminousone via Digitalmars-d
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>
Sönke Ludwig via Digitalmars-d
2014-07-09 19:51:44 UTC
Permalink
Post by luminousone via Digitalmars-d
Post by Sönke Ludwig via Digitalmars-d
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.
luminousone via Digitalmars-d
2014-07-09 23:27:01 UTC
Permalink
Post by Sönke Ludwig via Digitalmars-d
Post by luminousone via Digitalmars-d
Post by Sönke Ludwig via Digitalmars-d
Post by luminousone via Digitalmars-d
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.
Post by luminousone via Digitalmars-d
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=...>.
Post by luminousone via Digitalmars-d
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.
Sönke Ludwig via Digitalmars-d
2014-07-10 00:02:28 UTC
Permalink
Post by luminousone via Digitalmars-d
Post by Sönke Ludwig via Digitalmars-d
Post by luminousone via Digitalmars-d
Post by Sönke Ludwig via Digitalmars-d
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.
luminousone via Digitalmars-d
2014-07-10 00:30:43 UTC
Permalink
Post by Sönke Ludwig via Digitalmars-d
Post by luminousone via Digitalmars-d
Post by Sönke Ludwig via Digitalmars-d
On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig
Post by Sönke Ludwig via Digitalmars-d
Post by luminousone via Digitalmars-d
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.
Post by luminousone via Digitalmars-d
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=...>.
Post by luminousone via Digitalmars-d
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?
Sönke Ludwig via Digitalmars-d
2014-07-10 00:58:12 UTC
Permalink
Post by luminousone via Digitalmars-d
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;
Sönke Ludwig via Digitalmars-d
2014-07-10 01:04:40 UTC
Permalink
Post by Sönke Ludwig via Digitalmars-d
Post by luminousone via Digitalmars-d
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
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>
luminousone via Digitalmars-d
2014-07-10 18:07:37 UTC
Permalink
Post by Sönke Ludwig via Digitalmars-d
Post by Sönke Ludwig via Digitalmars-d
Post by luminousone via Digitalmars-d
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
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,
<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.
luminousone via Digitalmars-d
2014-07-10 19:10:18 UTC
Permalink
Post by Sönke Ludwig via Digitalmars-d
Post by luminousone via Digitalmars-d
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.
Post by luminousone via Digitalmars-d
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=...>.
Post by luminousone via Digitalmars-d
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.
Dicebot via Digitalmars-d
2014-07-09 09:47:19 UTC
Permalink
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
"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%
Dicebot via Digitalmars-d
2014-07-09 09:48:31 UTC
Permalink
Post by via Digitalmars-d
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
"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.
Sean Kelly via Digitalmars-d
2014-07-09 15:42:56 UTC
Permalink
Post by Dicebot via Digitalmars-d
Post by via Digitalmars-d
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
"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.
w0rp via Digitalmars-d
2014-07-09 19:05:53 UTC
Permalink
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.
Nick Sabalausky via Digitalmars-d
2014-07-09 19:37:27 UTC
Permalink
* 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.
Jacob Carlborg via Digitalmars-d
2014-07-10 07:56:43 UTC
Permalink
Post by Nick Sabalausky via Digitalmars-d
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
Adam D. Ruppe via Digitalmars-d
2014-07-10 13:42:30 UTC
Permalink
Post by Jacob Carlborg via Digitalmars-d
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.
Post by Jacob Carlborg via Digitalmars-d
The view uses appropriate names for the form fields, scoped in
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.
Chris via Digitalmars-d
2014-07-10 13:55:13 UTC
Permalink
Post by Adam D. Ruppe via Digitalmars-d
Post by Jacob Carlborg via Digitalmars-d
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
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.
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.
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.
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
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
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.
Post by Jacob Carlborg via Digitalmars-d
The view uses appropriate names for the form fields, scoped in
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
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?
Adam D. Ruppe via Digitalmars-d
2014-07-10 14:50:48 UTC
Permalink
Post by Chris via Digitalmars-d
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.
Chris via Digitalmars-d
2014-07-10 15:37:00 UTC
Permalink
Post by Adam D. Ruppe via Digitalmars-d
Post by Chris via Digitalmars-d
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.
Nick Sabalausky via Digitalmars-d
2014-07-10 18:10:49 UTC
Permalink
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
Adam D. Ruppe via Digitalmars-d
2014-07-10 18:24:57 UTC
Permalink
Post by Nick Sabalausky via Digitalmars-d
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.
Nick Sabalausky via Digitalmars-d
2014-07-10 18:05:32 UTC
Permalink
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?
Adam D. Ruppe via Digitalmars-d
2014-07-10 18:28:31 UTC
Permalink
Post by Nick Sabalausky via Digitalmars-d
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.
Nick Sabalausky via Digitalmars-d
2014-07-10 23:45:43 UTC
Permalink
Post by Nick Sabalausky via Digitalmars-d
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.
Adam D. Ruppe via Digitalmars-d
2014-07-10 13:53:17 UTC
Permalink
Post by w0rp via Digitalmars-d
* 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.
Post by w0rp via Digitalmars-d
* 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.
Post by w0rp via Digitalmars-d
* 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
Post by w0rp via Digitalmars-d
* 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!
Post by w0rp via Digitalmars-d
* 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.
Post by w0rp via Digitalmars-d
* 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.
Chris via Digitalmars-d
2014-07-10 14:15:18 UTC
Permalink
@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).
Adam D. Ruppe via Digitalmars-d
2014-07-10 17:29:05 UTC
Permalink
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.
Jacob Carlborg via Digitalmars-d
2014-07-10 17:31:41 UTC
Permalink
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
Poyeyo via Digitalmars-d
2014-07-11 00:36:25 UTC
Permalink
Post by w0rp via Digitalmars-d
* 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.
Adam D. Ruppe via Digitalmars-d
2014-07-11 01:03:23 UTC
Permalink
Post by Poyeyo via Digitalmars-d
- 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.
Post by Poyeyo via Digitalmars-d
- 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...

Continue reading on narkive:
Loading...