ControlServlet, widgets (screen, form, menu, tree):
These tools are now all combined into the Moqui XML Screens.
There are no explicit menus and instead there are subscreens and a menu is
automatically generated from the set of subscreens in a screen.
Instead of using the decoration pattern the XML Screens use subscreens to
compose an hierarchy of screens. The subscreens for a screen can be
configured in three different ways for different purposes including: a
directory structure plus defaults for a normal screen/subscreens hierarchy,
an XML element to include screens from other applications or that aren't in
any application, and a database table that allows add-on component to add
a subscreen to an existing screen somewhere else.
It is not an option to have multiple XML Screens in a single file. Each file
represents a single screen to make it easier to see what an application looks
like just by browsing the directory structure, kind of like it is for webapps
with normal templates and such.
Forms and trees are kept in separate files and are simply in-lined
in a screen. It is possible to refer to forms externally using the
screen's file location and the name of the form.
The widgets don't have any style attributes that will be used for HTML
class attributes. There are id attributes in various places, but the intent
is to use automatic id and class elements based on names and types of
elements in the XML Screens and then keep all of the styling in an external
CSS file.
There aren't any AJAX- and HTML-specific elements and attributes. This
goes back to the original intent of the OFBiz widgets and that is to be purely
declarative and platform independent. Many XML Screens elements will be
implemented using AJAX and DHTML, and options to control those or add to them
will be available.
MiniLang simple-methods, screen/form/etc actions
All operations from these various places are combined in one XSD file
and are referred to as XML Actions. These are included in various places
using the "actions" and "condition" elements. With this approach there is no
inconsistency for similarly named and designed operations or conditions.
Moqui XML Actions don't have operations that are not frequently used and some
operations are like a combination of various simple-method operations. There
are operations for a few additional things as well, like producing and
consuming XML.
Some operations that are inconsistent in different places in OFBiz, like
calling a service, have all similar features combined into one far more useful
operation.
There is no performFind service needed in Moqui as the entity-find operation
has an element that takes its place, and can be combined with various other
elements of a find by condition for a great deal of flexibility that is
easily usable.
The actions are available in many more places including ECA rules, screen
transitions (like the OFBiz controller request events), and others.
Service definitions and implementations
The OFBiz Service Engine is most like the Service Facade in Moqui. There are
many other facades, and for more info see the API Structure section below.
Service names are split into verb and noun parts, which together make up the
service name (ie like: ${verb}${noun}). Services are called with the combined
name and can separate the verb and noun parts of it using a hash mark ('#').
Services are also organized by path just like Java classes to facilitate lazy
loading and to better organize code. The full name of a service will follow a
pattern like: "${path}.${verb}${noun}".
Service parameters in Moqui are like the service attributes in OFBiz.
Service parameters are split into two groups: "in-parameters" and
"out-parameters" so that parameters with the same name can have different
settings going into or coming out of the service.
Parameters in Moqui have hierarchical sub-types for map and collection types.
Parameters have a fairly complete set of validation tags. Those
validation tags will be used for server-side validation when the service is
called, AND when the service is a target on a screen transition it will be
used to generate client-side validation in JavaScript. This validation
is defined once but run in both places.
As mentioned above XML Actions are available in many places, and one of those
places is inside a service definition. With this a service implementation can
be inline inside the service definition or external depending on preference.
Entity Engine
The OFBiz Entity Engine is most like the Entity Facade in Moqui. There are
many other facades, and for more info see the API Structure section below.
Entity definitions are more streamlined and don't have the less useful
attributes and elements. Primary key fields are designated with an attribute
on the field element instead of using a separate element. The data type
dictionary in Moqui is more simple and better organized than in OFBiz and
the data types available are declared in the XSD for auto-completion help.
The API for dealing with entity values and for queries and such is much more
simple, streamlined, and in a few small cases has additional functionality.
The methods have far more consistent names than in OFBiz, using
create/update/delete everywhere instead of things like store or remove.
Moqui does not have a concept of multiple delegators so the Entity Proxy
configuration file is much more simple. The datasource elements are also far
more simple because all of the database-specific settings are now in the
database configuration file along with the data type dictionary (combined in
one file instead of a separate file for each database).
API structure
The Moqui API is clearly separate into interfaces and implementations of
those interfaces. Applications only need to worry about the interfaces part
of the Java code and not the underlying implementation.
All tools in the Moqui framework are available through the ExecutionContext
object, which is created and attached to a thread for each web request,
remotely called service, etc. It keeps the current context for whatever is
running and has a series of facades for each tool in the framework, including
for sevices, entities, screens, localization, logging, caching, user info
and preferences, and so on. Some of the implementations of these interfaces
will be reusable from one thread to another, and others will be created for
each thread.
The API is designed to take advantage of some of the syntax short cuts in
Groovy such as using the dot syntax to start with the Moqui static object and
get down to whatever part of the API you need.
Configuration and code layout
In Moqui the framework is one big happy set of tools that work together.
There is no attempt to separate the tools or make them useful on their own.
That was goal at first with OFBiz, but never really worked out very well and
splitting the framework into components caused more difficulty than it helped
things. So, in Moqui it's all one big framework, and one that can be easily
compiled and deployed and so on. The basic idea is that the framework jar
files (api and implementation) on the classpath plus the locaiton of the
runtime directory are all you need to get started. Components can be loaded
through an API or configuration.
Configuration files are meant to come from a runtime directory and are not
spread around the code. There is a default-conf directory in the framework
so that if a configuration file is left out the framework will have a default
to fallback on that will work in most cases.
While Moqui supports multiple webapps, the normal deployment mode is be as
a single big webapp with screen trees from add on components mounted on a
certain path within the big webapp.
Content management
Instead of a set of entities and services for content management that are
part of the project Moqui uses the JCR 2.0 interfaces (and by default the
Apache Jackrabbit implementation) for content management. Anywhere there is
a "location" in the API or XML files it can have a prefix of "content://" to
access something from the JCR. This means that code and templates and such
can go there as well.
Security: authorization
Moqui uses a set of entities to define user groups, artifact groups, and
permissions for a group of users on a group of artifacts. These are external
settings and support record level permissions too. With this approach there
is no need make the artifacts responsible for permission checking, and no
code changes are required to change permissions when customizing or
maintaining or supporting an application.
There is a tarpit, like the idea in OFBiz, that uses the same model as the
permissions for reduced redundancy and more features.
I18n and L10n
Internationalization is implicit everywhere in Moqui using natural text in
the default language for a key instead of an artificial identifier. This
reduces redundancy and effort. The localized labels are in a database table
instead of an XML file to perform better (only lookup and cache labels that
are used) and to support per-instance localizations in a multi-instance
environment.
