Skip to content
Richard Andrew Cattermole edited this page Jul 20, 2014 · 27 revisions

Already done

  • OOP based router, supports conditional error handling (past just error code)
  • Data models to database support
  • Session handling in database
  • Configuration
  • Binding of data models to routes
  • Widget handling with database binding of values
  • Cache manager for data models
  • Update mechanism for running every 5 minutes and hourly
  • Key/Value system settings
  • Install vs production routes
  • Database backed user management
  • Database backed user authentication but abstracted for others
  • Email receive / sending (with thanks to dvorm and vibe!)
  • Complete generation of javascript data models, specifically the queries.
  • Support password changing
  • Javascript minifier on static files
  • Localization
  • Mime handling
  • Rss generation from data model
  • Using interfaces/classes to create a remote API call.

TODO: Immediate future

  • Implement the node communication system
  • Improve performance
    This is a continuous task that won't ever really be completed. And is highly dependent on the system its being tested upon.
  • Database migration strategies?
  • Documentation
    At current state people are unaware of the capabilities of Cmsed. Nor how to use it successfully.
  • Better templates support
    Something like @MayUseTemplate("mytemplate")
    Add renderTemplate("mytemplate") function.
    Possibly support arguments?
  • For route arguments if its a struct/class receive it as a KV pair or JSON document
  • For route return type if its a struct/class send it as a JSON document

What does other web service frameworks offer?

  • Form validation
  • XSS filtering
  • File uploading
  • Pagination
  • Caching
  • Barcode generator
  • Qr code generator
  • Captcha
  • Postgresql, sqlite, Oracle
  • Ldap auth
  • SOAP/wsdl
  • Sitemap generator, xml/html?
  • Theming
  • Oauth consumer/provider
  • XMPP

What else should be added

  • templ-d support

    Currently the template support is heavily designed towards diet and ability to include out of a template.

  • Communication per node

    • Node type/capabilities

      Broadcast / message hooks

    • Messages

      Perhaps msgpack-d

  • Adding RouteDescription UDA might be a good idea

  • Support for outputting PlantUML and the diagram version of it

  • Nitrogen framework (Erlang) supports inline templates that are generated to html/javascript that can automatically call server side code on specific events like onclick.

    Perhaps something along these lines would be rather useful. Ideas for a new templating mechanism other than Diet perhaps?

  • Ideas for recompilation

    • Recompilation at runtime (templates/routes/models)
    • Hook template into route
    • Quick (most important)
    • Development vs Release
    • Large builds = bad
enum ResponseTypes {	
	NotHandled,
	Json,
	PlainText,
	Redirect,
	Raw,
	Error
}

struct ResponsePacket {
	ResponseTypes type;
	string mimeType;
	
	union {
		string text;
		Json json;
		ubyte[] raw;
	}
}

enum DakkaCallMethods {
	Singular,
	Sequential, // if returns void don't wait
	SequentialUntil // if returns void act as sequential
}

struct DakkaCallMethod(M = DakkaCallMethods.Singular, D = {return true;}) {
	DakkaCallMethods method = M;
	
	auto del = D;
}

class RouteActor!T : Actor {
	@DakkaCallMethod!(DakkaCallMethods.SequentialUntil, a => a.type != ResponseTypes.NotHandled)
	ResponsePacket handle(HTTPServerRequest request, RouteResponse response) {
		// foreach route in T
		//		Actually make it routable
		// 			Turn output if used into the response
		// Error out (not exception wise, but response)
	}
}