Quino 2020 Roadmap

Now that Quino 8.x is out the door, we can look forward to Quino 9.

Quino 8 is a very solid and stable release that has already been test-integrated into many of our current products running on Quino. We don’t anticipate any more low-level API changes, though there will be follow-up bug-fix releases.

There are a few larger-scale changes improvements and enhancement, outlined below (and noted in the roadmap).

Ready for Change

With this release, we’ve got more coverage than ever. Excluding only generated code (e.g. *Metadata.cs and *.Class.css in the model assemblies), we ended up with a respectable 81% test coverage. Quino has almost 10,000 tests comprising about 51k LOC and covering 82k LOC[1], Many, many of these are integration and scenario tests. With this level of test coverage, we feel comfortable with refactoring to improve usability and performance.

81% Coverage for Quino 8

Documentation

One of the primary near-term goals is to improve Quino’s documentation story. The aim is to take a new developer through the common tasks of working with a solution based on Quino.

• Setting up a solution: getting packages and creating standard projects for testing, web, and so on
• Creating a model
• Using expressions
• Using quino’s command-line tools
• Generating ORM and metadata code
• Working with business logic
• Integrating the web
• Improving the debugging experience
• Writing tests efficiently, quickly and easily using powerful base classes and tools for snapshot-based tests

Some of this documentation is currently still out-of-date or will change as we improve the corresponding components. For example:

• Anything that refers to Nant is no longer relevant
• Some of the quino tool documentation will no longer be relevant after 8.1 (see tools-related issue in the issue tracker)
• The data documentation is still very much a work-in-progress

Search and Index

The latest table of contents is much more comprehensive than before and we’re still improving it.

We don’t have an integrated search for the conceptual documentation yet, but you can use Google’s site-specific search. For example, search for configuration with the following search text “configuration site:docs.encodo.ch”. The top results are:

• Configuration
• Configuration System
• Quino Application Configuration

Which is pretty decent, overall.

Database-first

Several of our upcoming products using Quino (two are so new that they’re not yet listed) are replacing legacy products that are highly dependent on a central database that defines the application domain. That is, the model is in the database or in a model description that is not initiallly a Quino model.

Instead of defining the model in C# code manually and then building the database from that (the standard approach with Quino), these products define the model with varying levels of automation and import and then use the existing database.

The following list shows the various ways that we’re building Quino models, in addition to the standard approach of defining them in C#:

• Import a model from Microsoft Dynamics CRM
• Import a model from a legacy DSL like the Atlas modeling language
• Import a model from the database schema itself, using Quino’s schema-import/migration support
• Map a model in C# to an existing database schema, using Quino’s new support for mapping schemas

This allows customers with existing databases to relatively quickly and easily produce a Quino model that gets them access to the plethora of features available to Quino applications (e.g. ORM, schema-check and -migration, generated GUI for desktop or web, and so on).