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



models/book.d



routes/test.d



routes/package.d


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:


And for if you want to utilise a template:


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.