FAQ

See: FOAM-Overflow, the FOAM Q&A database at: http://foam-framework.github.io/foam/foam/apps/overflow/Overflow.html

Q1. What is the relationship between the controller that you pass through the URL parameter query and a DAO? As I currently understand it, a DAO is an instantiated interface to a storage space, which seems to me equivalent to a controller.

A1. There are different kinds of controllers, but the most common type is a DAOController, which provides CRUD GUI functionality for a DAO. The DAO is a programming interface for accessing your data. It contains methods like, find(), select(), put(), remove(), where(), orderBy(), etc. The DAO is independent of GUI. The Controller is a mediator which takes an underling DAO implementation and makes it available as a GUI. The actual displaying of the data from the DAO is handled by Views, but the Controller coordinates between Views and the DAO. Different types of Views include summary views like tables, trees or lists for displaying more than one record at a time, and detail views for viewing or editing a single row at a time. The Controller lets you perform searches, thus filtering the data displayed in your summary view, then pick individual views for viewing or editing, and also the creation of new data. It is important that DAO functionality not be built into the Controller, because it just isn't the controller that needs access to the data. Other views and business logic often need access to DAO's outside of the main GUI for that DAO. DAO implementations are available on all three client-platforms: Web/JS, Android/Java, iOS/Swift and on the server in Java. The client DAO's communicate over the network to the matching server DAO (with authentication and possibly caching).

Q2. Does Foam utilize a virtual DOM to implement Hot Reloading like React or does it not support it?

A2. FOAM is built upon a virtual DOM. It does this for security and performance reasons. We don't support hot reloading. It could be added, but because our applications tend to be small, and therefore load fast anyway, it hasn't been worthwhile. Our gmail client, for example, is only about 110k, including FOAM. See: http://foam-framework.github.io/foam/apps/gmail/main.html One business application with 660 screens, reloads in 2 seconds.

Q3. How does Foam translate code from data to Java, Javascript, Swift, etc without using a transpiler?

A3. We first do what's called a Model-to-Model transform. So we have the FOAM Models for things like Class, Method, Property, Action, Template, etc., which make up what we just call your FOAM Model, but we also have Java specific models for things like Class, Property, Method, etc., which represent Java language functionality. These have the same names, but are in different packages, ie. foam.core.Method vs. foam.java.Method. So from the FOAM Model we generate a Java model (or Swift or whatever) and then the Java models have toJavaSource() methods which can be implemented as regular methods or as template methods, which give you a standard-ish template syntax. Transpilers are for translating between languages at similar levels of abstraction, ex.: from Java to Javascript, but that isn't what FOAM is doing. It's converting from a higher-level to a lower-level language, just like a C compiler which generates assembly would. Unlike compiling from high to low-level, transpilers have never worked well in practice.

In essence, this part of FOAM is much simpler than most people expect. FOAM models are themselves modelled, meaning they are themselves just data. So the result is that iterating over models and generating code, is essentially no different than, say, iterating over line-items and creating an invoice. It's ultimately just a simple report against data (somewhat complicated by the model-to-model transforms).