"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 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.
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.
With YetaWF every site is a single page site. You still develop individual pages, which are then combined into one (or multiple) Unified Page Sets. No tools or utilities to run. You can even combine Unified Page Sets and Static Pages for extreme performance.
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.
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).
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.
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.
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.