> On 15 Oct 2015, at 18:48, Scott Gray <scott.g...@hotwaxsystems.com> wrote: > > By the way, I'm surprised I haven't seen any efforts within the Moqui > community to rewrite any of the OFBiz apps. I don't have any ideas as to > why that hasn't happened, but I'm curious about it. Surely it would be > easier for the Moqui community who already know the framework and are > probably also familiar with OFBiz to try this than us.
This I can comment on. The business level data model in Mantle Business Artifacts (separate from Moqui Framework) is very different from the one in OFBiz. It is not only the framework that has room for cleanup and enhancement, but the data model, services and UI as well. The data model and services in Mantle are now on par or more advanced that similar parts of OFBiz in many areas, though there are still various areas of business functionality supported in OFBiz that are not yet supported in Mantle services and such. Overall Mantle is being built in the context of very different contracts than early OFBiz, more ERP oriented in general, which is why certain things like payroll exist in Mantle but never were implemented in OFBiz. As strange as it may be (and really not my preference), the initial standards based in integrations in Mantle are for various EDI X12 messages as opposed to the OAGIS ones in OFBiz (I still like that standard MUCH more and plan to build around it eventually… but contracts do set priority, especially for larger efforts like that). The UI layer in the HiveMind (ERP and project management for service orgs) and POP Commerce (ERP and ecommerce for retail and wholesale) are also being built from scratch, and now in the hundreds of screens. The goal has always been to start from scratch with Moqui/Mantle/etc, based on many of the ideas and patterns that emerged over time in OFBiz. As for the application structure, and even screen designs, in OFBiz: they could be much better. Without customization and enhancement so many business processes are left hanging with no UI to complete them (though sometimes there are services in place). The menu structure and such is also little short of painful, and in all larger OFBiz based projects I’ve been on the application level has been redesigned and rewritten, to a lesser or greater extent reusing screens/forms/etc from the OOTB OFBiz apps. Even as open source contributors with limited time and resources, we can do better. OFBiz can be much more usable than it is now, the potential is there. In the mean time, I’ll admit there are other applications I take more inspiration from than OFBiz, on the UI level at least. On the data model and service/logic level there is a lot of inspiration to be taken from OFBiz, even if there is a lot of room for improvement (doing much more with much less code, and much more flexibly too). A framework rewrite may make things more efficient, easy, and clean in OFBiz, but there is a lot of room for improvement in the data model, logic, and UI layer implementations as well. Those sorts of changes can be done maintaining backward compatibility, and without starting over. The accounting in OFBiz is close to adequate to run a business on, but not there in various painful ways that I’ve been through with many clients. The order processing based on the ShoppingCart* objects is abysmal… inflexible and unnecessarily complex. What a revolution in OFBiz? Kill the ShoppingCart* objects, move all the logic to services, and keep cart state in the database instead of session objects. The menu structure in so many applications, and accounting may be the worst of them, is painful and confusing at best. I still see some of the bad decisions I made over a decade ago persisting there. Yes, I know these because they are my sins, my early mistakes… and I gave up on atoning for them as part of OFBiz. Whatever Adrian says, be careful of his comments and direction, he is a big part of the reason I gave up improving things in OFBiz itself. -David
