+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.
>
>
>
>
>
