RejectedSoftware Forums

Sign up

Frameworks on top of vibe.d

Hi all!

vibe-d is good base, but it need much more to be productive, so it need next layer with component-based approach, more advanced db layer, etc. I found only Cmsed project but it's dead for about 2 years and even can't be compiled. Is where any other projects/libraries around?

Re: Frameworks on top of vibe.d

Am 12.10.2016 um 11:15 schrieb Alexey Kulentsov:

Hi all!

vibe-d is good base, but it need much more to be productive, so it need next layer with component-based approach, more advanced db layer, etc. I found only Cmsed project but it's dead for about 2 years and even can't be compiled. Is where any other projects/libraries around?

Hi! There are some higher level database abstractions (database
libraries on
code.dlang.org
),
but I haven't used any of them so far, so I can't make any qualitative
statements there. I once started an abstraction
layer
, too, but I'd still
consider it to be in the experimental stage, even though it is close to
being practically useful.

In terms of a component based abstraction library, I only know of Cmsed.
But if statically compiled components are sufficient, most of the vibe.d
side projects are written so that they can be plugged into umbrella
applications (for example, ddox and vibelog are integrated into
vibed.org), using the URLRouter as the common connection point.

If you haven't done so already, I'd recommend searching for "vibe" on
https://code.dlang.org/ or looking at the "vibe.d compatible" category
to get an overview of the available extension libraries. I should
probably also start to maintain a catalog of mature and well maintained
libraries at some point...

Re: Frameworks on top of vibe.d

Hi!

On Fri, 14 Oct 2016 20:16:16 +0200, Sönke Ludwig wrote:

Am 12.10.2016 um 11:15 schrieb Alexey Kulentsov:

Hi all!

vibe-d is good base, but it need much more to be productive, so it need next layer with component-based approach, more advanced db layer, etc. I found only Cmsed project but it's dead for about 2 years and even can't be compiled. Is where any other projects/libraries around?

Hi! There are some higher level database abstractions (database
libraries on
code.dlang.org
),
but I haven't used any of them so far, so I can't make any qualitative
statements there.

After some investigations I can say where are some variants but not ideal. Most close to my requirements I found is database and mysql-lited. database is standard proposal and seems to be good enough but uses C mysql client library so requests are blocking, and mysql-lited has vibe-d support but not very good interface (I'd prefer to have ranges instead of callbacks). Now I choose mysql-lited because of non-blocking nature and production-tested state.

In terms of a component based abstraction library, I only know of Cmsed.
But if statically compiled components are sufficient, most of the vibe.d
side projects are written so that they can be plugged into umbrella
applications (for example, ddox and vibelog are integrated into
vibed.org), using the URLRouter as the common connection point.

This part is real problem and more important then database layer. May be it's lack of knowledge but for current moment I fail to make something good using current vibe-d interfaces. For example, I can't realize how to implement widgets not dragging around response object. I didn't found how to get context of current request except of webinterface method parameter. Meantime function 'render' uses internally such variable, but it is private and user can't get it. Why do not expose request content to user if it is used by 'render' in any case? For current moment I have to get it from webinterface method and put to my static variable for later use.
Another problem for me is current router implementation. Problem is routing to methods. I have seen many web projects and can say: this is o.k. for small projects but then project grows this inevitably leads to a huge unsupportable classes. Thinking more about it, when we use widget approach, HTML page is just subclass (named like PageWidget) of some BaseWidget class, so it's logical to route urls direct to PageWidget instances. So it will be good to have something like:

shared static this()
{
	auto router = new URLRouter;
	router.registerWebPages(maybe_with_some_prefix);
....
}

@WebPage // mapped to some default URL calculated from package/class name
class Index : PageWidget
{
	this(context object, page parameters, etc)
...
}

@WebPage("/user/profile") // mapped to provided url
class Profile : PageWidget
{
 ...
}

// masks will be useful, with captures available using some context object
@WebPage("/do/(.+)", PUT) 
class DoSomeAction : PageWidget
{
 ...
}

It will allow to split code to small, independent parts instead of huge classes.

If you haven't done so already, I'd recommend searching for "vibe" on
https://code.dlang.org/ or looking at the "vibe.d compatible" category
to get an overview of the available extension libraries. I should
probably also start to maintain a catalog of mature and well maintained
libraries at some point...

Yes, it will be good to have such list, but more important to invest time into documentation, I think. A lot of experiments and effort required to understand basic things. Like fact that 'render' template can be called only from public methods of registered web interfaces.