Enterprise frameworks, what's next?

For those who have been following my blog recently, will know I've been working on a web service framework. Although its ultimate goal is to act as a far more all in one based component library. Its still needs the web service framework part of it.
The development so far has really gone well. Its already reached its first milestone where majority of its core features have been implemented.

The next stage is determining where to go from here. At this point in time I can continue my own requirements part of development or I can look towards other web service frameworks for requirements.
For this I have gone towards others.

Based upon a bunch of others I have discovered I have compiled this list

• Form validation
• XSS filtering
• Email recieve / sending
• File uploading
• Localization
• Pagination
• Caching
• Barcode generator
• Qr code generator
• Captcha
• Mysql, Postgresql, sqlite, Oracle
• Rss
• Ldap auth
• SOAP/wsdl
• Sitemap generator
• Mime handling
• Theming
• Oauth/OpenID consumer/provider
• XMPP

Now there is items on there that has already got partial support for.

Example of this is email sending. Vibe provides the ability to use an smtp server to send email. However its interface is very horrible and does not hook into the template system for html emails.

It also has the ability to upload files.

There is also some extra things that are not directly related to Cmsed in that list. Like the databases. They are actually a requirement for Dvorm. All in all, adding new databases is easy for Dvorm. The problem is between Mongo/Memory and sql based databases. In Mongo you generate a key ahead of time. With Mysql it utilises an integer and returns it. Big problems here. Not only different types (string vs integer) but where its generated. By the model vs the provider. The end result will probably end up being the unique identifier gets handled by Dvorm and depending on the backend will it be stored as a string or as an integer.

This list of requirements is ever growing. But once most of its done it will be very enjoyable to work with. Not to mention very easy!

For an example of why should you choose Cmsed and why it is promising check out this code examples:

models/package.d

	module cmsed.test.models;
	import cmsed.base.registration.model;
	public import cmsed.test.models.book;
	shared static this() {
	registerModel!Book3;
	registerModel!Page3;
	}

view raw package.d hosted with ❤ by GitHub

models/book.d

	module cmsed.test.models.book;
	import cmsed.base.routing;
	import dvorm;
	@dbName("Books3")
	class Book3 {
	@dbId
	@dbName("")
	Book3Id key = new Book3Id;
	@dbDefaultValue("0")
	ubyte edition;
	void t() {}
	@dbIgnore
	string something;
	mixin OrmModel!Book3;
	}
	class Book3Id {
	@dbId {
	@dbName("id")
	string isbn;
	}
	}
	class Page3 {
	@dbId
	@dbName("_id")
	string id;
	@dbName("book")
	@dbActualModel!(Book3, "key")
	Book3Id book = new Book3Id;
	mixin OrmModel!Page3;
	}

view raw book.d hosted with ❤ by GitHub

routes/test.d

	module cmsed.test.routes.test;
	import cmsed.base.routing;
	import cmsed.base.restful;
	import cmsed.test.models.book;
	class Test : OORoute {
	@RouteGroup(null, "/test.svc") {
	mixin RestfulRoute!(RestfulProtection.All, Book3, Page3);
	}
	}

view raw test.d hosted with ❤ by GitHub

routes/package.d

	module cmsed.test.routes;
	import cmsed.test.models.book;
	import cmsed.base.registration.routes;
	import cmsed.base.registration.onload;
	public import cmsed.test.routes.test;
	shared static this() {
	registerRoute!Test();
	void func(bool isInstall) {
	Book3 book = new Book3;
	book.key.isbn = "AS-DF-TF";
	book.edition = 8;
	book.save();
	}
	registerOnLoad(&func);
	}

view raw test.d hosted with ❤ by GitHub

Thanks to the restful mixin full access and modification is provided for the Book3 and Page3 models.
You're able to specify only view/create/modify/delete and have the model check that, that action can occur. This can be utilised for checking if a user can do set operation.

The idea is the amount of code to do something should be as minimal as possible. But flexibility should not be compromised for simplicity at any stage. When comparing against other languages and frameworks this may feel a little heavy. However there is always a price for high functionality. But netherless its still quite small.

An example of how to create a route and get it to output some text passed by a url parameter:

	import cmsed.base;
	class ExampleRoute : OORoute {
	@RouteFunction(RouteType.Get, "/mypath/:myarg")
	void anyNameMyFunc() {
	if (http_request.params.get("myarg", "") != "") {
	http_reponse.writeBody(http_request.params["myarg"]);
	} else {
	http_response.writeBody("You failed haha!");
	}
	}
	}

view raw gistfile1.d hosted with ❤ by GitHub

And for if you want to utilise a template:

	import cmsed.base;
	class ExampleRoute : OORoute {
	@RouteFunction(RouteType.Get, "/mypath", "mytemplate")
	bool anyNameFunc() {
	return true;
	}
	}

view raw gistfile1.d hosted with ❤ by GitHub

You still need to register the route. But no point showing that.
I truly believe that D has a strong future in web development. And am prepared to put my skill where my mouth is! The only thing truly preventing it right now is the iteration times of testing models/routes/templates. That will be fixable once we get shared libraries on all platforms.