YetaWF Documentation


YetaWF Philosophy

"Provide 100% of the features that will satisfy most small to mid-size, average websites - with rapid custom development for specialized features - while eliminating tedious development tasks."

Development of YetaWF started in 2010 and has evolved over the years into this open source project. Its main objective is "Convention over Configuration", meaning rather than offering complicated configuration options, things are done within the YetaWF framework "the YetaWF way". This provides huge benefits to even the simplest module. Property pages, data backup/export, search, localization, and many other features are automatically available without any effort on the part of the developer.

YetaWF takes the "Model First" approach (we're not referring to Entity Framework). In any module, you create a data model and decorate it with various attributes (like UIHint, ProcessIf, validation attributes, etc.). Based on this model, a complete form is created for you, including client-side validation and conditional processing, without any JavaScript coding required. It's all built into YetaWF. So without JavaScript/TypeScript knowledge, you can create web applications with a solid client-side end-user experience, even including "Single Page Sites".


YetaWF provides all features necessary to maintain a site, such as automated backups, scheduler tasks, sitemap generation, and all the configuration and maintenance pages found in the Admin menu (standard YetaWF site). All the Admin features are also accessible from mobile devices (like everything else in YetaWF).


Page content is easily modified. Most content will be created using the YetaWF.Text module which provides an editor accessible in Site Edit mode so any authorized user can make changes to a page. Other modules can be configured using their module settings. This simplifies most content maintenance as it does not involve a developer.

Static Pages

YetaWF can turn any page into a static page, which means it doesn't need to be rendered as its contents are already available in HTML form. This offers the best of both worlds, a page can be edited and saved and is immediately available as a static page for super-fast loading. No tools or utilities to run.

Single Page Site

With YetaWF every site is a single page site. You still develop individual pages, which are then combined into a Single Page Application. No tools or utilities to run. You can even combine Single Page Applications and Static Pages for extreme performance.

Next-Gen Format Images

YetaWF automatically serves requested PNG and JPG files using the next-gen WEBP image format as recommended by Google. This is fully automatic and requires no developer action.



YetaWF automates all developer tasks that can be a burden on other platforms.

JavaScript, CSS

YetaWF modularizes components, modules, packages, etc. and each may contribute JavaScript "snippets" to a page. YetaWF automatically combines all these and on deployed systems creates complete bundles with all combined JavaScript. The developer has zero work for this to happen, no configuration, no list of files to provide where a file could be missed. Just select a checkbox in Site Settings once. Done. CSS files are also processed the same way, including bundling. Again, without any configuration. Just select a checkbox in Site Settings once. Done.

YetaWF uses incremental JavaScript/CSS loading so an initial landing page has a minimal payload, yet it's still a Single Page Application. YetaWF does not bundle all JavaScript/CSS files into one giant package (as webpack would). Instead, required parts are incrementally loaded as the user navigates the Single Page Site. A landing page can quite easily achieve a PageSpeed Insights score near 100, and still participates in the Single Page Site, with near 100% ROCA compliance.

The YetaWF core uses TypeScript and SCSS. All the rendering code is modularized in the (replaceable) YetaWF.ComponentsHTML package which uses TypeScript and JavaScript addons.


Other platforms may use localization "resources". This means the developer has to add a resource, a "string", to one file, so the message can be used (by another file). This is tedious and error prone. YetaWF uses another approach using the __ResStr() method.

. . .
return FormProcessed(model, this.__ResStr("okSaved", "Profile saved"));

A short name ("okSaved") is assigned to the string ("Profile saved"). This defines a localizable message, which doesn't need to be added anywhere else (like a resource file). During development, this will simply result in the string "Profile saved". Once the package has been completed, the developer can generate the localization resource (a JSON file) using Admin > Panel > Packages (standard YetaWF site). Done. If a __ResStr() call is removed, the next time the localization resource is generated, the string is removed from the JSON file.

Of course, translating all the JSON files into other languages still requires some work. But there is an automated translation tool built into YetaWF (see National Language Support).

Data Modeling

YetaWF is very much data driven and creating a new form (Add, Edit, Display) only requires a model. All presentation and client-side validation is derived by YetaWF from the model, including its attributes (like UIHint, StringLength, Required, ReadOnly, AdditionalMetadata, etc.). In addition, attributes such as RequiredIf, SameAs, etc. provide additional information which determine client-side behavior. All required JavaScript is generated based on this information, usually embedded as part of basic support offered by YetaWF and its components.

This means that a developer using YetaWF with an understanding of MVC can take full advantage of all features without being burdened by client-side programming, yet still get all the advantages of a solid client-side experience for the end-user of the site.

The only time an application would need to implement any type of JavaScript/TypeScript is when adding display and editor components or when a module implements specialized functionality (e.g., a menu editor like the one found when editing a menu). Because of this approach to client-side presentation, YetaWF does not need or support frameworks like Angular, React, Vue, etc. They are simply not needed as all the plumbing is already provided by YetaWF. At the same time, an application can of course add one of these frameworks to YetaWF for its own specialized pages and modules. Similarly, it is possible that YetaWF itself will eventually switch to one of these frameworks. This would of course not require any application changes as all the necessary information for presentation and validation could still be extracted from the application's data model.

YetaWF already localizes all rendering into the YetaWF.ComponentsHTML package, so it is (in theory) possible to replace just this package to take full advantage of a JavaScript framework like Vue, React, etc.

Error Handling

Things can go wrong, unfortunately. Anytime an error occurs, YetaWF will display an appropriate message, within a module or page, depending on where the error occurred. If Ajax calls go wrong, a popup window is shown. No cryptic 500 IIS error page. This error handling extends to exceptions thrown pretty much anywhere, in a controller, a data provider, a view, or some support code. YetaWF will figure out how to best display the error message.

if (Manager.IsInPopup) throw new InternalError("Save & Display not available in a popup window");

In this example, a module doesn't support use in a popup window. So it throws an exception (any exception would do), in this case an InternalError instance. YetaWF displays this appropriately in the location of the module or as a popup.

Supported Database Servers

YetaWF's main objective was always to satisfy the requirements of Softel vdm, Inc.'s websites and other websites provided to its customers. While initially it was limited to just Microsoft SQL Server, it now also fully supports PostgreSQL.

YetaWF implements its own data providers for SQL and PostgreSQL. It does not use Entity Framework. Tables and stored procedures are automatically created based on data models for new packages and are automatically updated when a new package version is found (debug, non-deployed builds only).

Even though supporting other DBs is of little value to us, all external data providers can be used, in addition to the provided File, PostgreSQL and SQL data providers, by registering external data providers. We have experimental RavenDB data providers, although they're not included with YetaWF. It is possible to replace any of the provided data providers.

YetaWF can also be used without database server and all data is stored in files. This is intended for small sites only, but can be used very efficiently, particularly if static pages are also used.