A New Framework Project: Moqui

[David E. Jones-2]

Hello all,

First, I apologize in advance for the somewhat off-topic post.

A few people, but not many, already know that I've been working on a new enterprise application framework over the past couple of months. That framework is not starting to take shape and is called Moqui. You can see the Moqui project on sourceforge, and eventually I'll get the moqui.org web site setup as well (but it isn't yet, just a parked domain for now).

I've been waiting to make it more public until I had designs in place for most of the main ideas, and that is now done. The designs and planning are not yet complete, but are far enough along (and with an example application) that it is at least clear what the framework will be like in a fair amount of detail.

How does this relate to the Apache OFBiz Framework? Why am I doing this as a separate project instead of part of OFBiz?

I guess as Ricky Ricardo used to say, I've "got some 'splainin' to do!" I'll try to keep it short and simple... but then again you probably know my track record on that. ;)

Early in the life of OFBiz there were various points in time where we made dramatic changes to the framework. This was somewhat painful even when the project was small, and you can still see the results of that in OFBiz today with some older code that does not take advantage of newer tools. It may be that part of the problem was that the framework and the applications work together in a single project and while the dividing line between them was fairly clear for a long time it has become harder and harder to say what is really in the framework and what is really in the applications and to keep things in the framework from depending on the applications. If the framework had been in a separate project the applications could have been built on a certain version of the framework, released before updating to a newer version of the framework, and then refactored or rebuilt to use the newer version of the framework.

On the other hand, over time as the applications have grown and the number of organizations using OFBiz have grown, it has become much more difficult to make major changes in the framework because there is so much code that would have to be updated and there are so many people using the code that would have problems because of the updates. In many parts of OFBiz there is backwards compatible code and I think it is impressive that so much backwards compatibility has been maintained. This does have the downside of making the framework, and especially the implementation of the framework, far more complex.

Over the years I've thought about many possible changes to the framework and kept notes on them. There have been a few times when I focused on framework improvements, and for a while after OFBiz joined the Apache Software Foundation I even tried to push a temporary focus on the framework before the size and scope of the applications increased too much more. A lot of great things have been added to the framework in recent years in spite of all of the difficulties and it has been impressive to see the community take up and leverage so many of these changes.

A few months ago I started thinking about another set of changes and looking at how they might be implemented inside OFBiz. Eventually I decided that the changes were too dramatic and it would be much easier to just do them as a separate project. What I have started is a separate open source project that is not part of the Apache Software Foundation. It may take quite a while to get this implemented even to the 1.0 release, and when that happens I hope that either Apache OFBiz will move to use it or another project like OFBiz will be built on it. For now I'm not really worried about that and the focus of the effort is to build a good framework and nothing more. The license of the framework is the Apache License 2.0.

With the Moqui framework I am also planning to structure the community differently. There are many great things about a more open community driven project like OFBiz. For example, it is a great place for innovation and new ideas and collaboration with others to make those new ideas a reality. For me personally I plan to stay involved with OFBiz and for the foreseeable future it is still the main focus of my career. This may seem funny because I have been hostile in the past with OFBiz to the idea of having more restricted control over commits to the trunk, and I certainly haven't jumped on the GIT bandwagon at all. That doesn't mean I don't think it's a good idea in general, I'm just not sure how it would work for something like OFBiz or for any project in the ASF.

However, with this new project I am planning on managing it more like Linux and various other open-source projects are managed. The idea is for everything to go through a single moderator. Contributions from others may be accepted, but never directly and only through the moderator. The project may have multiple moderators each responsible for a different part of the whole, but nothing will go into the project without centralized review. This sort of model does bring up other possible issues but for this sort of software the trade-off is well worth it.

Yesterday I spent some time writing up an overview of the Moqui project and also a comparison of the Moqui framework to the OFBiz framework. For those interested I am including both below.

Out of courtesy for the real intent of this mailing list if you have questions or comments about Moqui please send them to the Moqui Open Discussion Forum instead of sending them to an OFBiz mailing list. This thread on this mailing list will hopefully only have a single message so that the list can focus on what it is meant to.

-David


=============================================================================
The Moqui Framework
=============================================================================

The Moqui Framework is an integrated tool set with everything needed to start
building web-based applications right away. Instead of starting with a set of
tools and figuring out how to use them together and filling in gaps that are
not handled by default Moqui is ready to go right away.

The Moqui Framework includes:

- Database (entity) proxy for data tier
  - Define your entities and go, no code to write and no redundancy
  - Java API or XML tags for a wide variety of queries and common operations
  - Event-Condition-Action rules to do things based on data changes
  - Data import and export tools, including for seed and other setup data
  - Support for Derby, HSQL, PostgreSQL, MySQL, and Oracle OOTB, and easy to
    add support for other databases, usually just through configuration
- Service-based logic tier
  - Call services synchronously, async, or scheduled
  - Services can be local or remote and implemented in a variety of languages
  - Flexible XML service definitions
  - Validation of data type, required or not, regexp, and other constraints;
    validation runs on server and in client with JavaScript library
  - Event-Condition-Action rules to orchestrate high level processes,
    externally change or augment behavior of existing services, and much more
- Screen-base user interface tier
  - Declarative multi-platform screens, text templates, or any combination
  - Generate HTML, XML, PDF (XSL-FO), or drive GWT or Swing screens
  - Screen files and included sets of subscreens in directories with the same
    structure as the application
  - Nested subscreens for multiple levels of tabs or other types of menus
  - Data preparation logic declared with screens to make each screen modular
  - Outgoing transitions point to input processing logic and conditional
    forwarding to other screens or external URLs
  - Forms (single, list), trees, panels, and various other common widgets
- Uses Groovy for scripting and Freemarker for templates (can add others)
- JCR 2.0 (JSR-283) based content and artifact management
- Manage incoming and outgoing email
- Implicit internationalization and easy localization
- Comprehensive security with declarative authorization
  - Settings in the database, separate from implementation artifacts
  - Define run-time inheritable permissions for any artifact in the system
  - Both record level and implementation artifact level security
- Protection from XSS and XSRF threats (uses ESAPI and Antisamy)
- Flexible resource access from files, JCR repository, and many others
- Cache management for framework and application resources
- Logging
- Multi-tenant architecture (single application, one database per tenant)
- Common business data structures and seed data
  - Enumerations and statuses with transitions
  - Units of measure with conversion, including currency
  - Geographic boundaries (legal and arbitrary) and points
  - Time periods and temporal expressions
- Service/logic and data level integration options
- Data migration and mapping tools (especially for to/from XML, to/from db)

The framework features a well-defined Java API that makes it easy to get at
the features listed above, especially in Groovy code. What's even better is
that the Moqui tools are designed to be used in a declarative way so most of
what you need to do will be possible with XML configuration and little or no
code is required, unless you want to of course.

Moqui uses sourceforge.net for various tools. See the Moqui sourceforge site
here:

http://sourceforge.net/projects/moqui/

To access to the source for Moqui through SVN use this URL:

https://moqui.svn.sourceforge.net/svnroot/moqui/trunk/moqui

=============================================================================
The Moqui Framework versus the the Apache OFBiz Framework
=============================================================================

-- ControlServlet, widgets (screen, form, menu, tree):

These tools are now all combined into the 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 ('#').

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 works 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 will 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 concept 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-tenant localizations in a multi-tenant
environment.

[Shi Jinghai]

+1 to the new PM style.

在 2010-03-12五的 13:55 -0700，David E Jones写道：

> Hello all,
>
> First, I apologize in advance for the somewhat off-topic post.
>
> A few people, but not many, already know that I've been working on a new enterprise application framework over the past couple of months. That framework is not starting to take shape and is called Moqui. You can see the Moqui project on sourceforge, and eventually I'll get the moqui.org web site setup as well (but it isn't yet, just a parked domain for now).
>
> I've been waiting to make it more public until I had designs in place for most of the main ideas, and that is now done. The designs and planning are not yet complete, but are far enough along (and with an example application) that it is at least clear what the framework will be like in a fair amount of detail.
>
> How does this relate to the Apache OFBiz Framework? Why am I doing this as a separate project instead of part of OFBiz?
>
> I guess as Ricky Ricardo used to say, I've "got some 'splainin' to do!" I'll try to keep it short and simple... but then again you probably know my track record on that. ;)
>
> Early in the life of OFBiz there were various points in time where we made dramatic changes to the framework. This was somewhat painful even when the project was small, and you can still see the results of that in OFBiz today with some older code that does not take advantage of newer tools. It may be that part of the problem was that the framework and the applications work together in a single project and while the dividing line between them was fairly clear for a long time it has become harder and harder to say what is really in the framework and what is really in the applications and to keep things in the framework from depending on the applications. If the framework had been in a separate project the applications could have been built on a certain version of the framework, released before updating to a newer version of the framework, and then refactored or rebuilt to use the newer version of the framework.
>
> On the other hand, over time as the applications have grown and the number of organizations using OFBiz have grown, it has become much more difficult to make major changes in the framework because there is so much code that would have to be updated and there are so many people using the code that would have problems because of the updates. In many parts of OFBiz there is backwards compatible code and I think it is impressive that so much backwards compatibility has been maintained. This does have the downside of making the framework, and especially the implementation of the framework, far more complex.
>
> Over the years I've thought about many possible changes to the framework and kept notes on them. There have been a few times when I focused on framework improvements, and for a while after OFBiz joined the Apache Software Foundation I even tried to push a temporary focus on the framework before the size and scope of the applications increased too much more. A lot of great things have been added to the framework in recent years in spite of all of the difficulties and it has been impressive to see the community take up and leverage so many of these changes.
>
> A few months ago I started thinking about another set of changes and looking at how they might be implemented inside OFBiz. Eventually I decided that the changes were too dramatic and it would be much easier to just do them as a separate project. What I have started is a separate open source project that is not part of the Apache Software Foundation. It may take quite a while to get this implemented even to the 1.0 release, and when that happens I hope that either Apache OFBiz will move to use it or another project like OFBiz will be built on it. For now I'm not really worried about that and the focus of the effort is to build a good framework and nothing more. The license of the framework is the Apache License 2.0.
>
> With the Moqui framework I am also planning to structure the community differently. There are many great things about a more open community driven project like OFBiz. For example, it is a great place for innovation and new ideas and collaboration with others to make those new ideas a reality. For me personally I plan to stay involved with OFBiz and for the foreseeable future it is still the main focus of my career. This may seem funny because I have been hostile in the past with OFBiz to the idea of having more restricted control over commits to the trunk, and I certainly haven't jumped on the GIT bandwagon at all. That doesn't mean I don't think it's a good idea in general, I'm just not sure how it would work for something like OFBiz or for any project in the ASF.
>
> However, with this new project I am planning on managing it more like Linux and various other open-source projects are managed. The idea is for everything to go through a single moderator. Contributions from others may be accepted, but never directly and only through the moderator. The project may have multiple moderators each responsible for a different part of the whole, but nothing will go into the project without centralized review. This sort of model does bring up other possible issues but for this sort of software the trade-off is well worth it.
>
> Yesterday I spent some time writing up an overview of the Moqui project and also a comparison of the Moqui framework to the OFBiz framework. For those interested I am including both below.
>
> Out of courtesy for the real intent of this mailing list if you have questions or comments about Moqui please send them to the Moqui Open Discussion Forum instead of sending them to an OFBiz mailing list. This thread on this mailing list will hopefully only have a single message so that the list can focus on what it is meant to.
>
> -David
>
>
> =============================================================================
> The Moqui Framework
> =============================================================================
>
> The Moqui Framework is an integrated tool set with everything needed to start
> building web-based applications right away. Instead of starting with a set of
> tools and figuring out how to use them together and filling in gaps that are
> not handled by default Moqui is ready to go right away.
>
> The Moqui Framework includes:
>
> - Database (entity) proxy for data tier
>   - Define your entities and go, no code to write and no redundancy
>   - Java API or XML tags for a wide variety of queries and common operations
>   - Event-Condition-Action rules to do things based on data changes
>   - Data import and export tools, including for seed and other setup data
>   - Support for Derby, HSQL, PostgreSQL, MySQL, and Oracle OOTB, and easy to
>     add support for other databases, usually just through configuration
> - Service-based logic tier
>   - Call services synchronously, async, or scheduled
>   - Services can be local or remote and implemented in a variety of languages
>   - Flexible XML service definitions
>   - Validation of data type, required or not, regexp, and other constraints;
>     validation runs on server and in client with JavaScript library
>   - Event-Condition-Action rules to orchestrate high level processes,
>     externally change or augment behavior of existing services, and much more
> - Screen-base user interface tier
>   - Declarative multi-platform screens, text templates, or any combination
>   - Generate HTML, XML, PDF (XSL-FO), or drive GWT or Swing screens
>   - Screen files and included sets of subscreens in directories with the same
>     structure as the application
>   - Nested subscreens for multiple levels of tabs or other types of menus
>   - Data preparation logic declared with screens to make each screen modular
>   - Outgoing transitions point to input processing logic and conditional
>     forwarding to other screens or external URLs
>   - Forms (single, list), trees, panels, and various other common widgets
> - Uses Groovy for scripting and Freemarker for templates (can add others)
> - JCR 2.0 (JSR-283) based content and artifact management
> - Manage incoming and outgoing email
> - Implicit internationalization and easy localization
> - Comprehensive security with declarative authorization
>   - Settings in the database, separate from implementation artifacts
>   - Define run-time inheritable permissions for any artifact in the system
>   - Both record level and implementation artifact level security
> - Protection from XSS and XSRF threats (uses ESAPI and Antisamy)
> - Flexible resource access from files, JCR repository, and many others
> - Cache management for framework and application resources
> - Logging
> - Multi-tenant architecture (single application, one database per tenant)
> - Common business data structures and seed data
>   - Enumerations and statuses with transitions
>   - Units of measure with conversion, including currency
>   - Geographic boundaries (legal and arbitrary) and points
>   - Time periods and temporal expressions
> - Service/logic and data level integration options
> - Data migration and mapping tools (especially for to/from XML, to/from db)
>
> The framework features a well-defined Java API that makes it easy to get at
> the features listed above, especially in Groovy code. What's even better is
> that the Moqui tools are designed to be used in a declarative way so most of
> what you need to do will be possible with XML configuration and little or no
> code is required, unless you want to of course.
>
> Moqui uses sourceforge.net for various tools. See the Moqui sourceforge site
> here:
>
> http://sourceforge.net/projects/moqui/
>
> To access to the source for Moqui through SVN use this URL:
>
> https://moqui.svn.sourceforge.net/svnroot/moqui/trunk/moqui
>
> =============================================================================
> The Moqui Framework versus the the Apache OFBiz Framework
> =============================================================================
>
> -- ControlServlet, widgets (screen, form, menu, tree):
>
> These tools are now all combined into the 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 ('#').
>
> 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 works 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 will 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 concept 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-tenant localizations in a multi-tenant
> environment.
>
>
>
>
>