Hi OFBIZ users and developers, First of all, I'm a novice of OFBIZ. I've just started to learn and use it for a couple of month. So if I have made some mistake in the following post, criticisms are welcomed :clap:
Does anyone using OFBIZ interested in porting OFBIZ to leverage a mature and decent web platform, more specifically Grails? The idea comes from the post from Christopher Snow, "There was some interest in porting openerp to jython", and the recent hot topic "groovy service code instead of minilang". Excuse me, I'm going a step further.:-P The problem an OFBIZ novice commonly facing is when he/she has to go further than the OFBIZ OOTB functionality ( which proves he/she is becoming a really OFBIZ user:drunk: ). He/she have to learn a lot of techniques in the unique OFBIZ way, which is commonly a well defined web framework/OR-mapping tool should take care. This make learning-curve steep. I fully understand the historical reason of OBFIZ, such as OFBIZ utilize the IoC idea earlier than Spring, entity-engine evolution over EJB2, and the ability to avoid the compile-deploy-test cycle and make development more efficient. And I really admire them, especially considering the age when OFBIZ developers invent them. But these are not unique features of OFBIZ now a days. Leading web development platforms such as RoR and Grails has go much further than what OFBIZ's technical platform can provide, since they have dedicated man power to spend in researching these area. What make things worse is many ways to accomplish same goal in OFBIZ. xml mini-lang, groovy, bsh, java, just named some. It giving developers freedom to choose technology what they like, sounds good. But it is a different story for the long term platform maintainers and customizers. With adequate open practice, can we gain enough experience to concentrate on a consistent way to do development task in OFBIZ? (To make me clear, I'm not advocating a single programming language to solve any problem). So..., why I'm still interested in OFBIZ? I must admit even with the complains, I'm still an OFBIZ fans till now. The answer is the business level functionalities. This is the real strength of OFBIZ. Since most services and actions have implemented in groovy/Java, porting these code to Grails are smooth. With the leverage of Groovy DSL over mini-lang, we will go further. Theoretically the chance to migrate the whole OFBIZ package to Grails platform are possible (more serious research work needs to be done in this area), while keeping the strength of OFBIZ - the business level assets accumulated in years. Of course it will not be an easy step, only great gains worth such huge change. So what we may gain from the transition: * Faster development speed - more efficient, on-rails level; * Less code - less maintenance spend; * More concentrate - No more re-invent wheel. Let's concentrate on what makes OFBIZ unique and leading-edge in limited resource; * More 3rd party software integration ability - provided by the Grails platform and plenty of plugins; * Easier deployment - no more embedding Tomcat, just standard war packages, which is deployable to any container, even cloud computing providers; * Last but not least, more smooth learning curve - the key factor to gain more new coming user and make success. Is this a right way to the future? Any thoughts? Regards, Miles. -- View this message in context: http://n4.nabble.com/Brain-storm-OFBIZ-on-Grails-is-this-a-right-way-for-the-future-tp1568009p1568009.html Sent from the OFBiz - User mailing list archive at Nabble.com.
