Skip to content

Design Goals

U-LPT00135\sumeetc edited this page Dec 6, 2015 · 2 revisions

Design Goals

Simplicity/Easy of Use

ffead-cpp does not require application class files to inherit any base classes. You can just implement a method signature and the framework will invoke your control method. Every application class is now just a plain old C++ class and nothing more. There is a small set of XML tags required for configuration in ffead-cpp which are very easy to read and manage. Markers provide the best alternative to XML configuration when it comes to manage and control the flow of your application. Most needed features like Type Conversion, String functions, Logging, Thread-Pools, Serialization and many more make application development super easy.

Extensible/Pluggable Architecture

Every major feature in ffead-cpp is a module, be it threads, sever-framework, client-framework, common utilities, serialization support, reflection support, ORM, caching, logging etc. Modules are the core of the ffead-cpp Eco-system. Handlers leverage their capability to make them usable. Plugins are an in-the-works future feature in ffead-cpp which will let any programming language be usable with ffead-cpp. The idea is to create an Eco-system where the ffead-cpp framework ideology can be utilized without the need to bother about lower level tasks of HTTP/Sessions/Serialization etc. Together modules, handlers and plugins will let any feature to be easily plugged in to the ffead-cpp framework. ffead-cpp is designed keeping in mind future extensions to the core framework. Plugins can be provided to not only drive language extensions but also additional feature set in the future. Handlers are a type of plugin currently implemented in ffead-cpp. Similar additions can be easily made to allow for added extensions to the core feature set in ffead-cpp.