Wt

Wt follows the traditional desktop 'MVC' model, in the sense that Wt (with a few exceptions) only provides the 'View' layer of your application. One exception is the class of item view models (WAbstractItemModel) which can supply information to a views like tables, trees, tree tables, and charts. Another exception is the form model (WFormModel) which supplies information for a standard form view (WTemplateFormView).

See also http://doc.qt.io/qt-4.8/model-view-programming.html for a more conceptual overview and historical context. Wt's MVC system predates the abduction (some would say, abuse) of the concept by web frameworks. What do you feel is currently missing which makes it impossible (or hard) for you to create a UI with Wt in a way that is concise, readable, and maintainable?

What I feel is missing is distributed object/function based on MVC :

• All database functions (query, CRUD, validation) are in Model class,
• All request/response, session, page title are in Controller class
• All widgets, assets are in View class
• Html template to be rendered by View class for easier maintenance

In Wt maybe it can be interpreted like this :

WtApplication -> handleInternalPath (routes list) -> Controllers -> Model -> View -> HTML

1. All configuration are on WtApplication constructor (database connection, app name, or any other)
2. WtApplication runs handleInternalPath which is defining all routes available (should be able to differentiate method like POST/GET etc.)
3. handleInternalPath call Controller and gives the user request as arguments
4. on Controller we define the logic & call all the functions we need on Model (REMEMBER : Fat Model Thin Controller)
5. Controller call View class to render HTML template file which contains our UI (widgets are inside the template file)

This is only the big picture of my understanding of MVC web framework

I haven't try http://www.treefrogframework.org because of the performance benchmark comparison to wt, but maybe this framework will give you a better concept.

This framework looks like implementing a real MVC web framework

In Wt, internal paths are optional, very much like it's optional in a 'single page' JavaScript application.

They are an additional feature to allow the user to think of your application in terms of pages, and it offers additional navigation methods (browser back/forward buttons, or opening an anchor in a new window/tab).

Conceptually, Wt's MVC model is more similar to that of a modern JavaScript framework (like angularjs, react) or an old-style desktop UI framework (Qt, ...), than it resembles the MVC model as advocated by old-school web frameworks.

So there's typically no 'routing' in a Wt application, unless for very specific widget like a menu which wants to react to internal path changes.

Moreover there are no 'user request arguments'. Instead all form data is nicely propagated to each view component, automatically.

Finally, the 'controller' does not call a view class to render a HTML template. Instead, each widget determines for itself if and how it wants to respond to the raised event.

The core concept inside Wt (as well as dekstop frameworks or modern JavaScript frameworks) is a Widget (sometimes named component) that is self-contained, easily reusable and can can be specialized or composited. It hides the specific technology that is used by a browser to communicate with a web server (and gives it the freedom to choose whatever works best). In contrast, the core concept in a traditional MVC framework is a Page and it tends to expose the entire Request/Response methodology of how a browser talks to a web server, making it nearly impossible to organize your application using reusable end-to-end components.

Wt was actually inspired by MVC web frameworks (Apache Struts at the time), as an example of how not to let the programmer get involved with tedious and non-functional details and a page-oriented design, which may work (reasonably well) for simple dynamic web sites (like for example wikipedia), but not for a web application that aims at replacing a desktop application. It was obvious to us (at the time) that the technologies to create desktop applications were working well enough, and could be translated to the web.

OK then. I'll try to learn to use it Wt's way.

Actually I still have a lot of questions about Wt's library (such as built-in form validation library), but maybe I'll open up another thread.

Wt really need to add more video tutorial, or cookbooks(how to create this and that, how to do this and that).

Wt seems such a good product without a good packaging.

Hopefully after I learn Wt (I must recalibrate myself from PHP's Yii2 Framework to C & Wt) , I could help on that.

Nice work, Koen Deforche!

>Wt really need to add more video tutorial, or cookbooks(how to create this and that, how to do this and that).

Agree with that, this is quite verbose task, but important for adoption of the tool