I'm more speaking at the business level . You may reuse artifacts there...
Jacques
From: "Christopher Snow" <sno...@snowconsulting.co.uk>
Hi Jacques,
Thanks for the comments.
Not sure how grails handles extension of artifacts (except that
Controllers and Services are classes so theoretically could be extended).
Grails only needs to be restarted when the hibernate definitions have
changed (I think). Controller and Service changes are dynamically
reloaded in development mode without a restart.
Grails has: |"grails create-app helloworld" which is the equivalent of
creating an ofbiz component.
In ofbiz, I always have to jump into the ofbiz code, even if its just to
configure it (e.g. data sources). In grails, the component
configuration is done in the component itself. I would never expect you
to modify the core grails code and create patches to ship with your
application - this is a big disadvantage with ofbiz.
Please don't think I'm giving ofbiz a hard time. Don't forget, I'm
interested in creating a standalone ofbiz framework (which would be
especially useful for my current government client), but I'm not sure
that the framework on it's own carrys any benefits compared to grails.
It's the business applications that give ofbiz the most advantage.
Cheers,
Chris
|
Jacques Le Roux wrote:
And one of the most important thing but not obvious in OFBiz,
extension and reutilisation of artifacts.
From hot-deploy, you can build your own applicaiton based on the trunk
(or release but I'd recommend trunk for easier update later) without
touching much of OFBiz itself. If you handle it right you may end with
a couple of small patches. There are even small tools around, see ant
- p, to deal with hat. This is where is the real OFBiz expertise, it
takes some time to understand and use...
Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
reboot, compile, reboot, compile, reboot, compile, reboot, compile,
reboot, OK you see...
Jacques
From: "Ruth Hoffman" <rhoff...@aesolves.com>
Hi Jacopo:
IMO, one should always give positive affirmations when responding to
posts like these. OFBiz has plenty of great things we can say that
shouldn't require much effort on your part to comment on:
How about the seamless and transparent database support by way of the
Entity Engine? If you want to develop an application or implement
ERP, then you don't need to worry about the database. You don't need
to stress over whether to use Hiberanate or JDO or native SQL or
whatever the latest database technology fad happens to be. The EE is
here, its proven and best of all I don't have to deal with it! I can
get on to developing my applications.
Or the really cool Service Engine that lets me write reusable code.
Java or otherwise!
Or all the framework tools that have been integrated and proven.
Everything from Internationalization and localization support to XML
document handling. (Personally, I'm tired of having to integrate XML
parsers every time I need that functionality in an application.)
How hard is it to list some of these features? Take the "high road".
Ruth
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
