On Saturday, 13 February 2016 at 19:06:46 UTC, Eugene Wissner
wrote:
On Saturday, 13 February 2016 at 14:52:46 UTC, Adil Baig wrote:
Hey Eugene,
Caraus seems like an interesting project. How do you plan to
build it out and differentiate it from vibe.d?
Difficult to explain it in a few sentences in a foreign
language, but I'll try. Just don't hesitate to ask if you have
any questions. I'm also not very familiar with vibe.d, I've
just seen a few examples and read about it a bit; so Sönke
should excuse or correct me if I say nonsense :).
It should be a framework for easy building and maintaining of
websites. The applications built on it would follow MVC (or
MVC-like) pattern by default, but since the framework is
thought as a set of reusable components/modules it should be
possible to use it for everything else like micro-webframework
for small projects with custom structure. The whole framework
should ship an abstraction over HTTP(S), mail sending
(sendmail, smtp), session handling with a possibility to
implement an own storage (file system, redis, memcached,
PostgreSQL...), dependency injection, router and so on.
It is a very common description. Now I make a few examples
showing what I think the framework should be able to do.
1) Creating a website should be as simple as creating a
Controller and a router configuration (YAML or database for
example), that assigns some route to this controller. Think of
something like this:
class IndexController
{
indexAction(Request request)
{
int contentId =
this.getDatabase().getContentModel().getPageById(5);
this.render("myTemplate.tpl", ["content": contentId]);
}
}
2) Form handling. You create a register form. So you create a
class User:
class User
{
int username;
string password;
}
and that class with some additional information should be
rendered to a web form. There are should be also routins to
help to verify the form (helpers for checking for email, length
of the input, phone number) and persist it to a database.
Whereby I don't think on ORM here, I'm not a big fan of ORMs.
For my projects I would implement a rich domain model with
domain objects, mappers... But it should be possible to use ORM
as well if this is available. Dependency Injection would make
such freedom possible. Btw. I think I won't write a DIc,
https://github.com/mbierlee/poodinis looks very promissing for
me. I would use any tools that meet requirements.
So it should help web developers in their daily job and should
make the web development pleasant.
It doesn't mean that I implement 10 session handlers from the
beginning. I will slowly implement things that I need for my
projects and will accept contributions if there are some
contributers one day.
And I can't promise that everything will be ready tomorrow. It
is very time consuming. But I got a new project last week that
may grow in the future. So I will begin to use these tools for
my work (I'm pretty free what I'm writing in and how I do it).
It can overlap with vibe.d here and there, but I think it is
more a continuation of vibe.d's http submodule. There were
already few attempts to create a similar framework on top of
vibe.d, see: https://github.com/CarbonComputed/carb.d or
https://github.com/Skadi-d/Skadi.d for example. But I want to
make it independent of the underlying platform (vibe.d, SCGI,
FastCGI).
So far....
my five cents on that topic...
@Eugene:
From my point of view, it would be great if you could bring in
all your ideas, wishes, changes, additions and new stuff into
vibe_d and help to grow and extend it and make it more usable...
Don't get me wrong, I thinks it's great if developers have
various choices in general to pick from, but especially in Dlang
"core tools" some of the existing stuff needs more
contributors/help... like vibe_d, dub (both from Sönke & team)
dfmt, ...
You and Sönke share the same native language (German) and also
the same time zone (Munich/Berlin)... and as it seems also the
same interest in "Web stuff/Frameworks", right? It shouldn't be
that difficult for you guys to alighn and team-up to build an
even better "Dlang Web tools/Framework development team"...
