Ex-nunc is an open-source framework, written in Objective Caml, to develop Web applications. The main purpose of Ex-nunc is to bring the benefits of strongly typed languages to the Web application domain.
Traditionally, Web appliances are based on weakly typed languages, and are focused mostly on markup production. The developer has to deal mostly with string manipulation (i.e., validation, parsing, serialization, deserialization) with little (or none) support from the underlying platform. Ex-nunc aims to simplify most of this low-level stuff, raising Web developing to a higher level of abstraction, in hope to have less error-prone applications.
Another pitfall of traditional Web development is the lack of type information for globally available data. For example, the data submitted by the user through a form is usually stored in an associative array. This way, no check can be performed at compile time to see if there is a misspelled field name, or if the developer applied the wrong conversion function to a field value. The only way to discover the error is pointing a web browser to the page that contains the bug. This bug hunting process gets harder and harder as the number of pages grows. Ex-nunc is designed with type safety in mind. Every piece of available data is stored in a strongly typed structure, permitting extensive checks at compile time.
Each Ex-nunc page accepts zero or more parameters that act like formal parameters of a function. This mechanism let the developer pass information (the actual parameters) when invoking a target page in a compiler-time verifiable manner. The traditional way of passing data to a page is through query string or form submission. The Web browser packs and encodes the values entered by the user into a string and submits it to the Web server. Therefore, the target page receives an encoded string, that must be parsed. Every single field must extracted, validated and converted to the proper type. And this process must be repeated for every single page in the application. There is no automated way of verifying that the page received the right number of fields or that a single field contains a value of the right type. On the other hand, page parameters are a type safe manner of passing information through pages: the developer specifies a tuple that constitutes the formal parameters of a page and let the compiler check the type information of the actual parameters passed by the calling page.
Web applications interact with users through forms. Users complete a form by entering values into text fields, selecting menu items, switching check-boxes, and so on. Then the Web browser submits the form to the Web server for processing. Data entered by the user must be validated before usage to avoid security issues. Ex-nunc provides tools specifically designed to simplify this task. Each Ex-nunc form has a declaration section, where the developer enumerates all the fields included in the form, annotated with type information. Each form is self-submitting, i.e. it always submits data to itself, to permit data validation. This task is performed through input validation controls that verify the conformance of user entered data. Then this data (still contained in string fields) is properly converted, stored in a strongly-typed record, and made available to the page code. It is worth noting that page switching mechanism is totally decoupled from form submission and is totally handled server-side. This way, the Ex-nunc runtime can forbid page transitions, if data validation failed. While traditionally, the page change mechanism is performed client-side, giving less control to the application.
As HTTP is a stateless protocol, each request is handled on its own. A session is a way to persist user state between requests. The Ex-nunc framework let the developer enlist all the fields he wants to use in his application, and will generate an OCaml record where the persisted data is stored. This way, the session data is available through a strongly typed data structure, and the compiler can catch typos in field names, and check that values of the proper type are stored in session fields.