On Fri, 2010-02-26 at 09:22 -0800, BJ Freeman wrote: > > [email protected] sent the following on 2/26/2010 8:45 AM: > > On Fri, 2010-02-26 at 09:06 -0500, Ruth Hoffman wrote: > >> 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. > >> > > I'm sorry to say this is also a Grails built in feature. Grails can > > simply write the domain model as a Groovy bean. Just give a really > > feature rich and yet simple example: > > class Person { > > String pid > > String firstName > > String lastName > > BigDecimal salary > > Date birthday > > String notes > > > > static constraints = { > > pid(blank:false, unique: true) > > firstName(blank:false) > > lastName(blank:false) > > notes(blank:true, nullable:true, maxSize:5000) > > } > > > > } > > This is all the code you need to write to define a entity model, then > > CRUD methods, nearly every possible simple finder methods (up to 2 > Actually once you define the enity, CRUD is atomatically genterated. > > > fields composite criteria), auto SQL table DML maintenance with re-sync > what you call re-sync is done at restart of ofbiz > > ability on every time you change the model, are all ready for you. You > > can also add some constraints for validation logic and storage hint > > (most have default value so you don't need to code for every one), just > > declaration, that's enough. > how is that different than ofbiz which also updates the UI with changes > to the entity. Sorry I haven't mentioned this. Grails scaffolding mechanism can generate UI based on the domain model define, with validation, and reflect the changes if you have made.
> > Constraints check are available on presentation/service/persistence > > tier. Quite like OFBIZ entity engine, but more coding efficient, isn't > > it? > using the mini language is more efficient. > I haven't touch much of the mini-lang part yet. What I've demoed is the equivalence of the OFBIZ entity definition XML plus validation code written in mini-lang events. > > And the sophisticated model relation management and auto > > optimized-locking mechanism, which seems to be a weak point of OFBIZ > > entity engine. > > > >> 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 is that different than ofbiz? > >> > >> > > XML process, persistence, i18n support, are all readily built in Grails > > platform. > again how is that different than ofbiz other than how it is accomplished? > > > > I'm only try following the question and answer of Christopher has raised: "I was hoping that my question would get ofbiz supporters to list some of the benefits of ofbiz over grails." So sorry no much "grails over ofbiz" here ;-)
