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 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. 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 ). 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. |
Miles Huang wrote:
> 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 > 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. So we trade new users having to learn the OFBiz way for new users having to learn the Grails way. What have we gained? -Adrian |
In reply to this post by Miles Huang
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. |
In reply to this post by Miles Huang
I like developing with ofbiz, but it is very cumbersome compared to
developing with grails. I have even started creating some prototypes in grails to get some idea of what would be required to implement ofbiz in grails. Personaly, I don't think grails is suitable for building large applications like ofbiz. The business components would have to be either separated by directory structure within grails, or by creating a separate grails application for each component and using something like spring integration or web services for wiring the applications together. Either way, modularity is an issue. I've even looked at doing the same in JBoss seam. The same problem as grails with modularity. Some other thoughts... The more I learn about OSGi, the more that I think this is the way forward for modularity. Hibernate or JPA for persistence, although I think an application dictionary approach like Adempiere would reduce hand coding dramatically. jBPM could be used for the business services. This would have two advantages, GUI tools for business users, automatic documentation of the services. Perhaps even Flex and BlazeDS for the front end. This gives thick client functionality in a thin client. Miles Huang wrote: > 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. > |
Administrator
|
Chris,
I agree that OSGI would be a better option than Grail. And yes, you put some good cards on the table, but... challenging isn'it ? If we succeed in removing components dependencies and take the time to think well about it, then why not? Jacques From: "Christopher Snow" <[hidden email]> >I like developing with ofbiz, but it is very cumbersome compared to > developing with grails. I have even started creating some prototypes in > grails to get some idea of what would be required to implement ofbiz in > grails. > > Personaly, I don't think grails is suitable for building large > applications like ofbiz. The business components would have to be either > separated by directory structure within grails, or by creating a > separate grails application for each component and using something like > spring integration or web services for wiring the applications together. > Either way, modularity is an issue. > > I've even looked at doing the same in JBoss seam. The same problem as > grails with modularity. > > Some other thoughts... > > The more I learn about OSGi, the more that I think this is the way > forward for modularity. > Hibernate or JPA for persistence, although I think an application > dictionary approach like Adempiere would reduce hand coding dramatically. > jBPM could be used for the business services. This would have two > advantages, GUI tools for business users, automatic documentation of the > services. > Perhaps even Flex and BlazeDS for the front end. This gives thick client > functionality in a thin client. > > > > Miles Huang wrote: >> 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. >> > |
In reply to this post by Adrian Crum
Just list some of the gains by different roles involved in the OFBIZ
ecosystem: * For OFBIZ provider business owners and end-users: As such a sophisticated business application, the training cost for new comers is much high. The cost can be branched into 2 parts: 1) Learning the business model and logic implemented by OFBIZ 2) Learning OFBIZ's unique technical platform The first part cost is no doubt value-able and unavoidable, because it's closely related to the business and specific product. But the second part is the cost that doesn't gain any direct benefits to the business. So they like to find a way to cut down such cost. To find a new developer familiar with Grails is much easier than find a new developer familiar with OFBIZ platform, isn't it? The second part cost can be cut down to 0 by hire a qualified developer. * For NEW developers: Assume the worst case, the new developers doesn't familiar either of these technologies. Then he has 2 choices: 1) Spend 2 months to get familiar with the unique OFBIZ technical platform, which may get the OFBIZ job done, but nothing else. 2) Spend 2 months to learn a technology like Grails, which can not only solve the OFBIZ related requirements, but also suitable to solve a wide-range of web development problems. Which one do you think he/she would like to spend their time into? * For current Experts: They may need to learn a new technologies, but this is one-time cost. After this, they can be released from the long-last technical platform maintain task, concentrate on the core business issues. Although I don't know them yet, I bet the maintainers of the OFBIZ technical platform may have gathered a lot of improvement idea for the core platform already, inspired by other leading platforms. But they have limited time/effort to do so, or even just wondering: does it worthwhile to re-invent the wheels? -Miles On Wed, 2010-02-24 at 13:03 -0800, Adrian Crum wrote: > Miles Huang wrote: > > 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 > > > 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. > > So we trade new users having to learn the OFBiz way for new users having > to learn the Grails way. What have we gained? > > -Adrian |
In reply to this post by Chris Snow-3
May be the Grails plugin mechanism is a good solution for the modularity problem. If we separate the OFBIZ components into stand-alone Grails plugins, each component is just like separated Grails applications, which can be maintained in their own source directory structure. And during development period, the Grails framework can provide sophisticated mechanisms to resolve the OFBIZ module dependency. At runtime, the dependent components are just deployed alongside with the referencing components in the same web application, remote service call is not required.
I'm not familiar with OSGi, so I can't say much about it. But if we need to support dynamical deploy/undeploy componets and multi-version module, the OSGi promise sounds attractive. Through a quick glance at the presentation from spring source ( OSGi 4.2 the Blueprint Service RI provider ), my understanding is the OSGi will take the responsibility to manage the web application dynamic module, while the web app framework such as Grails will take the responsibility to construct the dynamic module implementation framework. Does this mean OSGI and Grails technology can be integrated without overlaps and conflicts? |
Plugins could be used for separating the modules, this will be more
interesting in Grails 2.0 when the plugin framework will use OSGi - http://jira.codehaus.org/browse/GRAILS-2221 Rather than bring ofbiz to grails, you may find it would be easier to bring grails to ofbiz, for example it should be relatively trivial to sit a grails app on top of ofbiz (i.e. as a war file), and use grails to access the current ofbiz services. Note that you can already use groovy for writing ofbiz services. Eventually, when GSP gets separated from grails, this could be used in ofbiz instead of ftl - http://jira.codehaus.org/browse/GRAILS-5657 Note that OpenTaps 1.5 (ofbiz derivative) uses hibernate for the persistence layer instead of the home grown ofbiz ORM. It would be nice to see an option like that in ofbiz! Miles Huang wrote: > May be the Grails plugin mechanism is a good solution for the modularity > problem. If we separate the OFBIZ components into stand-alone Grails > plugins, each component is just like separated Grails applications, which > can be maintained in their own source directory structure. And during > development period, the Grails framework can provide sophisticated > mechanisms to resolve the OFBIZ module dependency. At runtime, the dependent > components are just deployed alongside with the referencing components in > the same web application, remote service call is not required. > > I'm not familiar with OSGi, so I can't say much about it. But if we need to > support dynamical deploy/undeploy componets and multi-version module, the > OSGi promise sounds attractive. Through a quick glance at the presentation > from spring source ( OSGi 4.2 the Blueprint Service RI provider ), my > understanding is the OSGi will take the responsibility to manage the web > application dynamic module, while the web app framework such as Grails will > take the responsibility to construct the dynamic module implementation > framework. Does this mean OSGI and Grails technology can be integrated > without overlaps and conflicts? > |
Le 25/02/2010 14:31, Christopher Snow a écrit :
> Note that OpenTaps 1.5 (ofbiz derivative) uses hibernate for the > persistence layer instead of the home grown ofbiz ORM. It would be nice > to see an option like that in ofbiz! > Hi Chris, Licenses are not compatible... we can't integrate Hibernate in OFBiz as it is under a LGPL product (https://www.hibernate.org/356.html), see http://www.apache.org/legal/resolved.html#category-x It's the same reason cobertura is not included, or selenium-server... Cheers, -- Erwan de FERRIERES www.nereide.biz |
In reply to this post by Chris Snow-3
On Thu, 2010-02-25 at 05:31 -0800, Chris Snow-2 [via OFBiz] wrote:
> Plugins could be used for separating the modules, this will be more > interesting in Grails 2.0 when the plugin framework will use OSGi - > http://jira.codehaus.org/browse/GRAILS-2221 > This is a good side witness on the correctness of "Don't re-invent wheels". Would it be nice to upgrade a 3rd-party library and sit-back, then suddenly an excellent new feature bring in? On Thu, 2010-02-25 at 05:31 -0800, Chris Snow-2 [via OFBiz] wrote: > Rather than bring ofbiz to grails, you may find it would be easier to > bring grails to ofbiz, for example it should be relatively trivial to > sit a grails app on top of ofbiz (i.e. as a war file), and use grails > to > access the current ofbiz services. > Nice idea. Instead of move the whole platform to Grails as a huge step, bring in Grails to OFBIZ, a reversed way could be an easier and more acceptable choice. May be one or some components could be re-written in Grails, while keep interoperability with other components. When this could be done, more people can make judgement based on the running code. And this bring in a gradational upgrade path. |
As with all other possible alternate technologies and practices, if you really like something the thing to do is a proof of concept project. For a really simple project you could re-implement the example application on your preferred technology. That would at least be a starting point for comparison of the technologies and development approaches. Beyond that some parts of different apps could be built out to further demonstrate the superiority of the new tools. Without that, I guess there really isn't much to discuss, and that's fine because also without that it's clear that no one really cares a whole lot about it (unless of course someone else does all the work!). -David On Feb 25, 2010, at 10:42 PM, Miles Huang wrote: > > On Thu, 2010-02-25 at 05:31 -0800, Chris Snow-2 [via OFBiz] wrote: >> Plugins could be used for separating the modules, this will be more >> interesting in Grails 2.0 when the plugin framework will use OSGi - >> http://jira.codehaus.org/browse/GRAILS-2221 >> > > This is a good side witness on the correctness of "Don't re-invent > wheels". Would it be nice to upgrade a 3rd-party library and sit-back, > then suddenly an excellent new feature bring in? > > > On Thu, 2010-02-25 at 05:31 -0800, Chris Snow-2 [via OFBiz] wrote: >> Rather than bring ofbiz to grails, you may find it would be easier to >> bring grails to ofbiz, for example it should be relatively trivial to >> sit a grails app on top of ofbiz (i.e. as a war file), and use grails >> to >> access the current ofbiz services. >> > > Nice idea. Instead of move the whole platform to Grails as a huge step, > bring in Grails to OFBIZ, a reversed way could be an easier and more > acceptable choice. May be one or some components could be re-written in > Grails, while keep interoperability with other components. > > When this could be done, more people can make judgement based on the > running code. And this bring in a gradational upgrade path. > > > > > -- > View this message in context: http://n4.nabble.com/Brain-storm-OFBIZ-on-Grails-is-this-a-right-way-for-the-future-tp1568009p1570179.html > Sent from the OFBiz - User mailing list archive at Nabble.com. |
Administrator
|
In reply to this post by Miles Huang
Miles,
Well tried, from your argumentation I guess that 1) you certainly know Grail, 2) most of us don't, 3) you don't know much about OFBiz yet So you try to push Grail and we brake on it. As David wisely suggested in another email a POC is the way for you now... Thanks for you interest in OFBiz Jacques From: <[hidden email]> > Just list some of the gains by different roles involved in the OFBIZ > ecosystem: > > * For OFBIZ provider business owners and end-users: > As such a sophisticated business application, the training cost for new > comers is much high. The cost can be branched into 2 parts: > 1) Learning the business model and logic implemented by OFBIZ > 2) Learning OFBIZ's unique technical platform > The first part cost is no doubt value-able and unavoidable, because it's > closely related to the business and specific product. > But the second part is the cost that doesn't gain any direct benefits to > the business. So they like to find a way to cut down such cost. To find > a new developer familiar with Grails is much easier than find a new > developer familiar with OFBIZ platform, isn't it? The second part cost > can be cut down to 0 by hire a qualified developer. > > * For NEW developers: > Assume the worst case, the new developers doesn't familiar either of > these technologies. Then he has 2 choices: > 1) Spend 2 months to get familiar with the unique OFBIZ technical > platform, which may get the OFBIZ job done, but nothing else. > 2) Spend 2 months to learn a technology like Grails, which can not only > solve the OFBIZ related requirements, but also suitable to solve a > wide-range of web development problems. > Which one do you think he/she would like to spend their time into? > > * For current Experts: > They may need to learn a new technologies, but this is one-time cost. > After this, they can be released from the long-last technical platform > maintain task, concentrate on the core business issues. > Although I don't know them yet, I bet the maintainers of the OFBIZ > technical platform may have gathered a lot of improvement idea for the > core platform already, inspired by other leading platforms. But they > have limited time/effort to do so, or even just wondering: does it > worthwhile to re-invent the wheels? > > -Miles > > > On Wed, 2010-02-24 at 13:03 -0800, Adrian Crum wrote: >> Miles Huang wrote: >> > 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 >> >> > 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. >> >> So we trade new users having to learn the OFBiz way for new users having >> to learn the Grails way. What have we gained? >> >> -Adrian > > |
On Fri, 2010-02-26 at 10:06 +0100, Jacques Le Roux wrote:
> Miles, > > Well tried, from your argumentation I guess that > > 1) you certainly know Grail, > 2) most of us don't, I don't think most of you don't. Grails development is merely writing Groovy code, with which most of you are familiar already. What make Grails source code difference is many DSL extension specifically to solve common WEB application requirements. Again you are also familiar with DSL concept already, the mini-lang could be considered as a DSL based on XML. Grails use Groovy DSL to gain similar high programming efficiency. > 3) you don't know much about OFBiz yet > > So you try to push Grail and we brake on it. As David wisely suggested in another email a POC is the way for you now... > > Thanks for you interest in OFBiz > > Jacques Nice summary. I agree a POC will make things clear. A sample Grails OFBIZ component would be a better discussion base. Now I've heard the voice from the community and it's time to do more research on the subject and learn more on OFBIZ itself. Hope I can work out a sample component in Grails recently. Thanks, Miles. |
Hi Miles,
i really like to see a POC of an Grails OFBiz component. I think this could be an interesting project. So Miles keep on working :-) 2010/2/26 [hidden email] <[hidden email]> > On Fri, 2010-02-26 at 10:06 +0100, Jacques Le Roux wrote: > > Miles, > > > > Well tried, from your argumentation I guess that > > > > 1) you certainly know Grail, > > 2) most of us don't, > I don't think most of you don't. Grails development is merely writing > Groovy code, with which most of you are familiar already. What make > Grails source code difference is many DSL extension specifically to > solve common WEB application requirements. Again you are also familiar > with DSL concept already, the mini-lang could be considered as a DSL > based on XML. Grails use Groovy DSL to gain similar high programming > efficiency. > > > 3) you don't know much about OFBiz yet > > > > So you try to push Grail and we brake on it. As David wisely suggested in > another email a POC is the way for you now... > > > > Thanks for you interest in OFBiz > > > > Jacques > > Nice summary. I agree a POC will make things clear. A sample Grails > OFBIZ component would be a better discussion base. > > Now I've heard the voice from the community and it's time to do more > research on the subject and learn more on OFBIZ itself. Hope I can work > out a sample component in Grails recently. > > Thanks, > Miles. > > > -- http://www.lynx.de |
In reply to this post by Miles Huang
Hi Miles,
I'm currently doing some work on making a standalone ofbiz development framework (i.e. no business functionality). Your questions have got me thinking: "what does the ofbiz framework give you that the grails framework doesn't?" A possible answer: "Ofbiz gives you a ready made layout for backend management UI (i.e. screens, menus, forms)" I can't think of anything other than this that the ofbiz framework provides that grails doesn't. Cheers, Chris Miles Huang wrote: > 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. > |
One more - inline...
Christopher Snow wrote: > Hi Miles, > > I'm currently doing some work on making a standalone ofbiz development > framework (i.e. no business functionality). Your questions have got > me thinking: > > "what does the ofbiz framework give you that the grails framework > doesn't?" > > A possible answer: > > "Ofbiz gives you a ready made layout for backend management UI (i.e. > screens, menus, forms)" and all its business functionality. > > I can't think of anything other than this that the ofbiz framework > provides that grails doesn't. > > Cheers, > > Chris > > > Miles Huang wrote: >> 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. >> > |
On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>> I can't think of anything other than this that the ofbiz framework provides that grails doesn't. > If you are blind, all you can see is darkness. Jacopo |
Hey come on Jacopo - overall I'm actually trying to promote the use of
ofbiz. I've invested a considerable amount of time in it. I was hoping that my question would get ofbiz supporters to list some of the benefits of ofbiz over grails. Jacopo Cappellato wrote: > On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote: > > >>> I can't think of anything other than this that the ofbiz framework provides that grails doesn't. >>> > > If you are blind, all you can see is darkness. > > Jacopo > > |
On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote: > Hey come on Jacopo - overall I'm actually trying to promote the use of ofbiz. I've invested a considerable amount of time in it. > > I was hoping that my question would get ofbiz supporters to list some of the benefits of ofbiz over grails. > Eh eh... this time your attempt will not help you to get easy information (at least from me): you will have to do your own research :-) Jacopo > Jacopo Cappellato wrote: >> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote: >> >> >>>> I can't think of anything other than this that the ofbiz framework provides that grails doesn't. >>>> >> >> If you are blind, all you can see is darkness. >> >> Jacopo >> >> > |
I'm not looking for easy information. Based on my experience of ofbiz
and grails - I really don't know what else ofbiz brings to the table. I was hoping that I'd missed something fairly obvious which is why I threw the question out to the list. Jacopo Cappellato wrote: > On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote: > > >> Hey come on Jacopo - overall I'm actually trying to promote the use of ofbiz. I've invested a considerable amount of time in it. >> >> I was hoping that my question would get ofbiz supporters to list some of the benefits of ofbiz over grails. >> >> > > Eh eh... this time your attempt will not help you to get easy information (at least from me): you will have to do your own research :-) > > Jacopo > > > >> Jacopo Cappellato wrote: >> >>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote: >>> >>> >>> >>>>> I can't think of anything other than this that the ofbiz framework provides that grails doesn't. >>>>> >>>>> >>> If you are blind, all you can see is darkness. >>> >>> Jacopo >>> >>> >>> > > |
Free forum by Nabble | Edit this page |