the porting usually refers to the UI, this can be handles but adding a interface to ofbiz like has been done for others.
if that is what your proposing and want to put the energy in, then go for it. for instance I use swing and SWT. but not many are interested so it stays in my svn for my customers. Miles Huang sent the following on 2/24/2010 12:40 PM: > 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.
