Thanks David! I agree with most of it, but... (inline)
Adrian Crum Sandglass Software www.sandglass-software.com On 10/17/2015 11:07 AM, David E. Jones wrote:
This message has a lot of the right questions to ask about a new framework. A big part of why the OFBiz framework suffers is because it was never planned in its entirety from the beginning, it is VERY much an emergent design as opposed to an intentional one. The interest bits start appearing with intentional design, and for anyone serious about getting into a fresh framework rewrite I’d highly recommend doing the same thing I did with Moqui: define Java interfaces for the API and an XML schema (XSD files) for the intended XML files. The XML schema might be the same as the current one, though there is room for improvement in the current OFBiz XML files and the eventual framework would be much better if these are reconsidered as well. You can see the Moqui interfaces here: https://github.com/moqui/moqui/tree/master/framework/src/api/java/org/moqui The central object at runtime, ie for most application code, is the implementation of the ExecutionContext interface. The whole API is structured around this: https://github.com/moqui/moqui/blob/master/framework/src/api/java/org/moqui/context/ExecutionContext.java There is also a JavaDoc generated and available on moqui.org, might be easier to read for some: http://www.moqui.org/javadoc/index.html http://www.moqui.org/javadoc/org/moqui/context/ExecutionContext.html I include these links because they might be useful for ideas or even as a starting point for a next generation OFBiz framework API (take or leave each method/etc as you wish). The nice thing about creating Java interfaces as opposed to a document is they are more clear and concise, and can be actually used in the framework implementation once interested community participants have reviewed it.
I believe both are necessary. The design document Wiki page describes the thought process/design goals/use cases for the interface design, and the actual Java interface can be included for review. Not only is this good for the design process, it can also serve as a reference for later ("Why was the interface designed that way?").
Here is an example: https://cwiki.apache.org/confluence/display/OFBIZ/Authorization+Manager+Implementation+Details
This doesn’t require nearly as much work as implementing the beast and is a great way to communicate concepts, so for anyone really serious about a framework rewrite in OFBiz I’d highly recommend this specific effort. The other details like which tools (other open source projects and such) to use is less important. On the other hand if using something like Spring is a serious consideration it would change the API dramatically, and a lot of the design ideas as well (I’d recommend against this BTW, the Spring ecosystem is its own thing and VERY different conceptually from OFBiz). -David
