Hi BJ, I treat OFBiz entity engine as an ORM that uses Map for the Object part.
The gui modeler is a desktop application (not sure if it is swt based), that helps with the editing of the database definition files, and database schema migration. The gui modeler is not used in the web application, nor does it use JNLP. Cayenne also doesn't generate the html forms from the database. Anyway, I can't think of a strong business case for making entity engine swappable. I thought it is worth mentioning Cayenne since it is similar to OFBiz entity engine. - james BJ Freeman wrote: > > One of the reason I came to ofbiz was to get away from the bloat of ORM. > if I read the modeler right that is swt based Gui which introduces a > communication layer back to the server, unlike ofbiz being generated on > the fly into html, from the server. > > BTw I have a Commercial Swt Gui Generator and use it for my legacy apps > I converted to ofbiz, as well as the communications layer using JNL. > > ========================= > BJ Freeman > Strategic Power Office with Supplier Automation > <http://www.businessesnetwork.com/automation/viewforum.php?f=52> > Specialtymarket.com <http://www.specialtymarket.com/> > Systems Integrator-- Glad to Assist > > Chat Y! messenger: bjfr33man > > james_sg sent the following on 9/18/2010 12:24 AM: > > >> >> Hi all, >> >> Apache Cayenne has the closest match to OFBiz Entity Engine. >> >> A few points about Cayenne: >> 1. Cayenne has generic object while OFBiz has Generic Value. >> 2. Cayene has DerivedDbEntity (depreciating) to OFBiz's View Entity. >> 3. Cayenne has a gui modeler to map the database. >> 4. Cayenne supports applications running in cluster. >> 5. OFBiz requires the developer to explicitly save each generic value. In >> Cayenne, the developer to save the Generic Object and any associated >> Generic >> Objects are implicitly saved. >> 6. Like OFBiz, the database definition files for Cayenne can be separated >> and grouped under domains and combined at runtime. >> 7. Cayenne gui modeler has function to merge database changes, but OFBiz >> does that automatically. >> >> If there is a need or business case to support the swapping of the entity >> engine, it should support similar ORM and follows the api used in OFBiz. >> >> Also note there is a JPA standard for ORM that uses POJO. >> >> Regards, >> James >> >> >> Scott Gray-2 wrote: >>> >>> Hi Chris, >>> >>> Could you explain how you envisage swapping the entity engine with >>> hibernate considering one uses Maps (GenericValue) and the other uses >>> POJOs to represent data? >>> >>> Thanks >>> Scott >>> >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> On 18/09/2010, at 1:32 AM, chris snow wrote: >>> >>>> I would see entity engine and service engine as separate modules. >>>> >>>> Each module should have clearly defined api defining how they interact >>>> with the outside world. A clearly defined api will facilitate >>>> swapping parts. For example, the entity engine could be replaced with >>>> a hibernate based engine as long as the api was implemented. >>>> >>>> (also there would be a module for Birt) >>>> >>>> On Fri, Sep 17, 2010 at 2:06 PM, BJ Freeman<bjf...@free-man.net> >>>> wrote: >>>>> to me framework is what has not ability to interact with the real >>>>> world, >>>>> like party, but just the tools. >>>>> so base layer is Entity and service engine. >>>>> Next layer is Webapp and Widgets. >>>>> next layer is Webtools >>>>> next layer is security and common >>>>> >>>>> A person should be able to enable those things that they want for >>>>> their >>>>> application. >>>>> >>>>> >>>>> >>>>> chris snow sent the following on 9/17/2010 4:11 AM: >>>>>> >>>>>> If you follow my instructions for 9.04 that will to a large extent >>>>>> give you framework independence. >>>>>> >>>>>> I think 9.04 makes a good basis for looking at modularising parts of >>>>>> ofbiz. For example, I would like to see the entity engine live in >>>>>> its >>>>>> own project. The entity engine from what I remember is currently >>>>>> tightly tied in to performing duties such as reading configuration >>>>>> files. Based on this, I would next focus on giving the entity engine >>>>>> an api for loading it's global configuration and also component >>>>>> configurations. That way, the entity engine could be added to ofbiz >>>>>> as a pure jar file and be configured by some other module (e.g. a >>>>>> configuration service). Isolating parts of the system like the >>>>>> entity >>>>>> engine has a lot of benefits. For example, BJ Freeman has mentioned >>>>>> improvements to the entity engine such as on the fly entity changes. >>>>>> This would be made much easier if the entity engine was not so deeply >>>>>> intertwined with the rest of the ofbiz code. >>>>>> >>>>>> I think github would be the ideal place for hosting this kind of >>>>>> effort. That way non ofbiz commiters could more easily contribute. >>>>>> >>>>>> On Fri, Sep 17, 2010 at 11:49 AM, james_sg<snowme...@hotmail.com> >>>>>> wrote: >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> I believe framework separation is a win-win situation and things >>>>>>> will >>>>>>> get >>>>>>> sorted out when the common agreement is there. >>>>>>> >>>>>>> I am using 9.04. For non-erp project, I have other favorite >>>>>>> framework. >>>>>>> >>>>>>> -james >>>>>>> >>>>>>> >>> >>> >> > > -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2544837.html Sent from the OFBiz - User mailing list archive at Nabble.com.
