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 <[email protected]> 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<[email protected]> 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 >>>> >>>> >>>> chris snow wrote: >>>>> >>>>> Hi James, >>>>> >>>>> I spent a lot of time looking at this and came to the conclusion that >>>>> in 10.04 the dependencies between framework and applications became >>>>> too intertwined to make a separate 10.04 framework. Here are some of >>>>> the pages I put together documenting my steps: >>>>> >>>>> https://cwiki.apache.org/confluence/x/eIOJ >>>>> https://cwiki.apache.org/confluence/x/nYTW >>>>> >>>>> I haven't used ofbiz for a while, however recently I started using >>>>> ofbiz 9.04 and I may take another look at using 9.04 as the basis for >>>>> some development effort to make ofbiz more modular (e.g. split the >>>>> project up maven style and make the entity engine a separate project >>>>> that can be used independently of ofbiz). There was also a >>>>> interesting work by Raj to use OSGi to make the dependencies in ofbiz >>>>> more explicit and controllable - >>>>> https://sourceforge.net/projects/ofbiz-osgi/ >>>>> >>>>> David's new project is very interesting, because he will be 'vetting' >>>>> all code that gets committed, which doesn't happen with the ofbiz svn >>>>> repository. >>>>> >>>>> Cheers, >>>>> >>>>> Chris >>>>> >>>>> On Fri, Sep 17, 2010 at 3:24 AM, james_sg<[email protected]> wrote: >>>>>> >>>>>> Does anyone know the status of this? >>>>>> >>>>>> --james >>>>>> >>>>>> >>>>>> BJ Freeman wrote: >>>>>>> >>>>>>> I am for standalone framework. David has been working on that project >>>>>>> for a while, if I remember correctly. >>>>>>> >>>>>>> #2 bothers me though. The design of ofbiz was that the entity was the >>>>>>> controlling factor for creating DB and UI. I was one of the major >>>>>>> reasons I came to ofbiz. >>>>>>> That said, any work that wants to be done on UI integration that makes >>>>>>> ofbiz look classy, I think should be the focus. >>>>>>> A lot of work has been done in that area. >>>>>>> But integrating other UI interfaces that keep the design idea of the >>>>>>> entity being to controlling focus is what I would like to see. >>>>>>> >>>>>>> I don't see ofbiz being object oriented in the normal sense. >>>>>>> >>>>>>> I see the effort for the help files and a easily understood UI from >>>>>>> the >>>>>>> user point of view being the main factors in promoting ofbiz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Chris Snow sent the following on 2/24/2010 10:47 PM: >>>>>>>> >>>>>>>> Here are some benefits of a 10.04 standalone framework release: >>>>>>>> >>>>>>>> 1) Standalone framework users would be a form of quality control >>>>>>>> helping >>>>>>>> to ensure more incorrect dependencies don't find there way into >>>>>>>> ofbiz. >>>>>>>> 2) we would be able to promote the framework in its own right thus >>>>>>>> competing with OpenERP's OpenObject platform >>>>>>>> 3) a much larger potential user base than ecommerce or erp users. >>>>>>>> >>>>>>>> Any more that I have missed? >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> >>>>>> http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543258.html >>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543697.html >>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>> >>> >> >>
smime.p7s
Description: S/MIME cryptographic signature
