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
|
In reply to this post by BJ Freeman
I'm sorry for pushing this off-track by mentioning hibernate. The important
point is that the technologies aren't important. There are many technologies that could be used for the entity engine, and as BJ has pointed out, the ofbiz entity engine is very good. The problem for me is that the entity engine is deeply interwined with the rest of ofbiz. These dependencies need to be managed. Having a more modular ofbiz has advantages for ofbiz as a whole and for each module. On 18 Sep 2010 09:03, "BJ Freeman" <[hidden email]> 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/viewf... 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 abo... |
Chris I may be dense, but what dependencies do you see from the entity
engine to the rest of ofbiz? I agree that from the rest of ofbiz the entity engine is core, and is to me the very reason that ofbiz is great. But from a framework point of view you can strip away the application and specialpurpose and build anything you want on top of the framework. which is why it is called a framework. outside of the base and supporting files in framework, you could probably reemove 50% of the framework and still have the entiy engine work. So is it just a technical thing or is there really a gain in what you are saying? Just trying to get a Grasp on what you goal and scope is. chris snow sent the following on 9/18/2010 1:48 AM: > I'm sorry for pushing this off-track by mentioning hibernate. The important > point is that the technologies aren't important. There are many technologies that could be used for the entity engine, and as BJ has pointed > out, the ofbiz entity engine is very good. The problem for me is that the > entity engine is deeply interwined with the rest of ofbiz. These > dependencies need to be managed. Having a more modular ofbiz has advantages > for ofbiz as a whole and for each module. > > On 18 Sep 2010 09:03, "BJ Freeman"<[hidden email]> 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/viewf... > 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 abo... > |
to give you an example, when first came to ofbiz and had many DB based
projects. They already had a data model i had develop over 10 years. so I did not use the applications or data model, that ofbiz had. I induced my data from the db into entity defs and converted the code I had into entity and service engines using the minilanq and java. BJ Freeman sent the following on 9/18/2010 2:02 AM: > Chris I may be dense, but what dependencies do you see from the entity > engine to the rest of ofbiz? > I agree that from the rest of ofbiz the entity engine is core, and is to > me the very reason that ofbiz is great. > But from a framework point of view you can strip away the application > and specialpurpose and build anything you want on top of the framework. > which is why it is called a framework. > > outside of the base and supporting files in framework, you could > probably reemove 50% of the framework and still have the entiy engine work. > > So is it just a technical thing or is there really a gain in what you > are saying? > > Just trying to get a Grasp on what you goal and scope is. > > chris snow sent the following on 9/18/2010 1:48 AM: >> I'm sorry for pushing this off-track by mentioning hibernate. The >> important >> point is that the technologies aren't important. There are many > technologies that could be used for the entity engine, and as BJ has > pointed >> out, the ofbiz entity engine is very good. The problem for me is that the >> entity engine is deeply interwined with the rest of ofbiz. These >> dependencies need to be managed. Having a more modular ofbiz has >> advantages >> for ofbiz as a whole and for each module. >> >> On 18 Sep 2010 09:03, "BJ Freeman"<[hidden email]> 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/viewf... >> 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 abo... >> > > |
In reply to this post by BJ Freeman
Hi BJ, there are parts of ofbiz that could be 'easily' used outside of
ofbiz if they weren't all part of the same code base. The Entity Engine example is one part that could become a library. Other parts include the datatype coverters and temporal expressions. At the moment if I want to use these parts of ofbiz in external applications, I have to manually extract them from the ofbiz code base. The framework would then be an assembly of libraries. By splitting ofbiz up, each library (entity engine, converters, temporal expressions, etc) could be developed independently of the rest of the ofbiz code. Do you want me do list the advantages of this approach? On Sat, Sep 18, 2010 at 10:02 AM, BJ Freeman <[hidden email]> wrote: > Chris I may be dense, but what dependencies do you see from the entity > engine to the rest of ofbiz? > I agree that from the rest of ofbiz the entity engine is core, and is to me > the very reason that ofbiz is great. > But from a framework point of view you can strip away the application and > specialpurpose and build anything you want on top of the framework. > which is why it is called a framework. > > outside of the base and supporting files in framework, you could probably > reemove 50% of the framework and still have the entiy engine work. > > So is it just a technical thing or is there really a gain in what you are > saying? > > Just trying to get a Grasp on what you goal and scope is. > > chris snow sent the following on 9/18/2010 1:48 AM: >> >> I'm sorry for pushing this off-track by mentioning hibernate. The >> important >> point is that the technologies aren't important. There are many > > technologies that could be used for the entity engine, and as BJ has > pointed >> >> out, the ofbiz entity engine is very good. The problem for me is that the >> entity engine is deeply interwined with the rest of ofbiz. These >> dependencies need to be managed. Having a more modular ofbiz has >> advantages >> for ofbiz as a whole and for each module. >> >> On 18 Sep 2010 09:03, "BJ Freeman"<[hidden email]> 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/viewf... >> 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 abo... >> > > |
Thanks for the taking the time to explain.
So you planning a seperate project? I don't see the business need for distribution in this environment of just the Jars, for the framework. I could see them in another environment that is not directly related to this project(svn). chris snow sent the following on 9/18/2010 2:42 AM: > Hi BJ, there are parts of ofbiz that could be 'easily' used outside of > ofbiz if they weren't all part of the same code base. The Entity > Engine example is one part that could become a library. Other parts > include the datatype coverters and temporal expressions. At the > moment if I want to use these parts of ofbiz in external applications, > I have to manually extract them from the ofbiz code base. > > The framework would then be an assembly of libraries. By splitting > ofbiz up, each library (entity engine, converters, temporal > expressions, etc) could be developed independently of the rest of the > ofbiz code. Do you want me do list the advantages of this approach? > > > On Sat, Sep 18, 2010 at 10:02 AM, BJ Freeman<[hidden email]> wrote: >> Chris I may be dense, but what dependencies do you see from the entity >> engine to the rest of ofbiz? >> I agree that from the rest of ofbiz the entity engine is core, and is to me >> the very reason that ofbiz is great. >> But from a framework point of view you can strip away the application and >> specialpurpose and build anything you want on top of the framework. >> which is why it is called a framework. >> >> outside of the base and supporting files in framework, you could probably >> reemove 50% of the framework and still have the entiy engine work. >> >> So is it just a technical thing or is there really a gain in what you are >> saying? >> >> Just trying to get a Grasp on what you goal and scope is. >> >> chris snow sent the following on 9/18/2010 1:48 AM: >>> >>> I'm sorry for pushing this off-track by mentioning hibernate. The >>> important >>> point is that the technologies aren't important. There are many >> >> technologies that could be used for the entity engine, and as BJ has >> pointed >>> >>> out, the ofbiz entity engine is very good. The problem for me is that the >>> entity engine is deeply interwined with the rest of ofbiz. These >>> dependencies need to be managed. Having a more modular ofbiz has >>> advantages >>> for ofbiz as a whole and for each module. >>> >>> On 18 Sep 2010 09:03, "BJ Freeman"<[hidden email]> 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/viewf... >>> 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 abo... >>> >> >> > |
In reply to this post by chris snow
--- On Sat, 9/18/10, chris snow <[hidden email]> wrote:
> Hi BJ, there are parts of ofbiz that > could be 'easily' used outside of > ofbiz if they weren't all part of the same code base. > The Entity > Engine example is one part that could become a > library. Other parts > include the datatype coverters and temporal > expressions. At the > moment if I want to use these parts of ofbiz in external > applications, > I have to manually extract them from the ofbiz code base. Actually, the conversion framework is a separate library: http://commons.apache.org/sandbox/convert/ > The framework would then be an assembly of libraries. By > splitting > ofbiz up, each library (entity engine, converters, > temporal > expressions, etc) could be developed independently of the > rest of the > ofbiz code. Someone had suggested some time ago in a similar discussion that the OFBiz framework itself could be condensed down to a single jar file. -Adrian |
In reply to this post by james_sg
James, I think that was BJ's point: the OFBiz Entity Engine is NOT an ORM tool, ie there is no attempt to map between an object model and the relational model in the database. We simply use the relational model itself. This reduces redundancy (you don't have to create an object model), and it avoid the often big/annoying problem of "impedance mismatch" between the two very different ways of modeling and managing data. I never did understand why the lords of Java always felt the need to map EVERYTHING to an object model instead of creating objects that make it easier to work with the natural model of each thing (ie relational databases, services, etc, etc). I guess once you get used to a certain way of doing things it's hard to imagine doing it in any way different. -David On Sep 18, 2010, at 2:38 AM, james_sg wrote: > > 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<[hidden email]> >>>>> 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<[hidden email]> >>>>>>> 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. |
In reply to this post by chris snow
When was the last time you worked on a project where you only needed a tool for persistence and didn't need tools for anything else? On the other hand, if you really LIKE to roll your own framework for each project, and based on tools that aren't necessarily meant to work together, then the approach you mentioned below is a great way to enjoy endless evenings and weekends. On the other hand, if you want to focus on developing things needed for applications instead of digging around in a framework for weeks and deciding how to do every little thing, then it's nice to have a complete framework to start with so you can efficiently work on the stuff that is important to your client. -David On Sep 18, 2010, at 2:48 AM, chris snow wrote: > I'm sorry for pushing this off-track by mentioning hibernate. The important > point is that the technologies aren't important. There are many > technologies that could be used for the entity engine, and as BJ has pointed > out, the ofbiz entity engine is very good. The problem for me is that the > entity engine is deeply interwined with the rest of ofbiz. These > dependencies need to be managed. Having a more modular ofbiz has advantages > for ofbiz as a whole and for each module. > > On 18 Sep 2010 09:03, "BJ Freeman" <[hidden email]> 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/viewf... > 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 abo... |
That's my idea also.
Any office automation system needs everything is now in the framework folder (entity engine, service engine, job scheduling, screen widgets, portals, localization, themes, webslinger!, etc.) plus IMO a basic party management system to allow users to login and interact with the system itself. Users should be able to read some help or some sort of documentation in the system they log in even before using any specific application and this is why a basic content application should be also part of the "OFBiz core" system. Any user that logs in a system should be emailed back if they forgot the password. Or they should be able to communicate with the system admin to ask "hey! When my specific application will be available in the system?" This is why a basic communication mechanism should be also part of the "OFBiz core". I use the "OFBiz core" term because I see that any time we speak about the framework-only distribution we never agree. May be this vision could find more people on the same page. (Or may be no one) I have not worked with any other framework than OFBiz so may be someone could say: "hey! But what you call "OFBiz core" is nothing more than what you get using XXYYZZ". If this is could you please give me any pointer? Thank you, Bruno 2010/9/18 David E Jones <[hidden email]> > > When was the last time you worked on a project where you only needed a tool > for persistence and didn't need tools for anything else? > > On the other hand, if you really LIKE to roll your own framework for each > project, and based on tools that aren't necessarily meant to work together, > then the approach you mentioned below is a great way to enjoy endless > evenings and weekends. On the other hand, if you want to focus on developing > things needed for applications instead of digging around in a framework for > weeks and deciding how to do every little thing, then it's nice to have a > complete framework to start with so you can efficiently work on the stuff > that is important to your client. > > -David > > > On Sep 18, 2010, at 2:48 AM, chris snow wrote: > > > I'm sorry for pushing this off-track by mentioning hibernate. The > important > > point is that the technologies aren't important. There are many > > technologies that could be used for the entity engine, and as BJ has > pointed > > out, the ofbiz entity engine is very good. The problem for me is that the > > entity engine is deeply interwined with the rest of ofbiz. These > > dependencies need to be managed. Having a more modular ofbiz has > advantages > > for ofbiz as a whole and for each module. > > > > On 18 Sep 2010 09:03, "BJ Freeman" <[hidden email]> 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/viewf... > > 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 abo... > > |
In reply to this post by David E. Jones-2
Making the entity engine available as a standalone module definitely has appeal. For example, the entity engine would sit nicely alongside an ESB such as mule for providing a very flexible and quick to develop persistence adapter.
When I talk about the framework being more modular, I am looking far into the future (i.e. I'm dreaming). The first step is to aim for framework/application independence. Someone is going to have to dig around in the framework from time to time. If parts of the framework could be worked on independently of the rest of the framework, it would make those parts much easier to maintain. |
In reply to this post by chris snow
On Sat, 2010-09-18 at 10:42 +0100, chris snow wrote: > Hi BJ, there are parts of ofbiz that could be 'easily' used outside of > ofbiz if they weren't all part of the same code base. The Entity > Engine example is one part that could become a library. Other parts > include the datatype coverters and temporal expressions. At the > moment if I want to use these parts of ofbiz in external applications, > I have to manually extract them from the ofbiz code base. > > The framework would then be an assembly of libraries. By splitting > ofbiz up, each library (entity engine, converters, temporal > expressions, etc) could be developed independently of the rest of the > ofbiz code. Do you want me do list the advantages of this approach? Nope. But it might be nice if: 1) Everyone stopped top posting so that ofbiz newbies could more easily follow the chronology of discussion threads. 2) You listed the disadvantages of your approach. Thank you and have a nice day;) -- Ken Gunderson <[hidden email]> |
In reply to this post by Bruno Busco
Might I suggest Setup method.
https://issues.apache.org/jira/browse/OFBIZ-635 have a group "System Setup" Bruno Busco sent the following on 9/18/2010 1:11 PM: > That's my idea also. > Any office automation system needs everything is now in the framework folder > (entity engine, service engine, job scheduling, screen widgets, portals, > localization, themes, webslinger!, etc.) plus IMO a basic party management > system to allow users to login and interact with the system itself. > > Users should be able to read some help or some sort of documentation in the > system they log in even before using any specific application and this is > why a basic content application should be also part of the "OFBiz core" > system. > Any user that logs in a system should be emailed back if they forgot the > password. Or they should be able to communicate with the system admin to ask > "hey! When my specific application will be available in the system?" > > This is why a basic communication mechanism should be also part of the > "OFBiz core". > > I use the "OFBiz core" term because I see that any time we speak about the > framework-only distribution we never agree. May be this vision could find > more people on the same page. (Or may be no one) > > I have not worked with any other framework than OFBiz so may be someone > could say: "hey! But what you call "OFBiz core" is nothing more than what > you get using XXYYZZ". > If this is could you please give me any pointer? > > Thank you, > Bruno > > > 2010/9/18 David E Jones<[hidden email]> > >> >> When was the last time you worked on a project where you only needed a tool >> for persistence and didn't need tools for anything else? >> >> On the other hand, if you really LIKE to roll your own framework for each >> project, and based on tools that aren't necessarily meant to work together, >> then the approach you mentioned below is a great way to enjoy endless >> evenings and weekends. On the other hand, if you want to focus on developing >> things needed for applications instead of digging around in a framework for >> weeks and deciding how to do every little thing, then it's nice to have a >> complete framework to start with so you can efficiently work on the stuff >> that is important to your client. >> >> -David >> >> >> On Sep 18, 2010, at 2:48 AM, chris snow wrote: >> >>> I'm sorry for pushing this off-track by mentioning hibernate. The >> important >>> point is that the technologies aren't important. There are many >>> technologies that could be used for the entity engine, and as BJ has >> pointed >>> out, the ofbiz entity engine is very good. The problem for me is that the >>> entity engine is deeply interwined with the rest of ofbiz. These >>> dependencies need to be managed. Having a more modular ofbiz has >> advantages >>> for ofbiz as a whole and for each module. >>> >>> On 18 Sep 2010 09:03, "BJ Freeman"<[hidden email]> 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/viewf... >>> 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 abo... >> >> > |
In reply to this post by David E. Jones-2
Hi David,
Thanks for the correction. - james
|
In reply to this post by chris snow
Do you think if it was made clear that in packages, org.ofbiz.(module)
in the java docs would effectively give you the individual "API" of that module, would help? http://ci.apache.org/projects/ofbiz/site/javadocs/ or after the change http://ci.apache.org/projects/ofbiz/site/javadocs/10.04/ chris snow sent the following on 9/18/2010 1:39 PM: > > Making the entity engine available as a standalone module definitely has > appeal. For example, the entity engine would sit nicely alongside an ESB > such as mule for providing a very flexible and quick to develop persistence > adapter. > > When I talk about the framework being more modular, I am looking far into > the future (i.e. I'm dreaming). The first step is to aim for > framework/application independence. > > Someone is going to have to dig around in the framework from time to time. > If parts of the framework could be worked on independently of the rest of > the framework, it would make those parts much easier to maintain. > > |
In reply to this post by David E. Jones-2
I'm not sure whether I'm the 1st suggested standalone framework release.
But I have given it up. OFBiz was/is built for consultants' satisfaction, it's an ideal agile system for consultants to prove ecommerce is possible and affordable for everyone. Threads in this topic shows a typical discussion between a consultant and a developer. They have different concepts on framework. As a developer, I think framework should only have tomcat, entity engine and service engine. Auth? Tomcat has valve. Perhaps we can change framework to another word, for example, server. Shi Jinghai/Beijing Langhua Ltd. 在 2010-09-18六的 10:56 -0600,David E Jones写道: > James, > > I think that was BJ's point: the OFBiz Entity Engine is NOT an ORM tool, ie there is no attempt to map between an object model and the relational model in the database. We simply use the relational model itself. This reduces redundancy (you don't have to create an object model), and it avoid the often big/annoying problem of "impedance mismatch" between the two very different ways of modeling and managing data. > > I never did understand why the lords of Java always felt the need to map EVERYTHING to an object model instead of creating objects that make it easier to work with the natural model of each thing (ie relational databases, services, etc, etc). I guess once you get used to a certain way of doing things it's hard to imagine doing it in any way different. > > -David > > > On Sep 18, 2010, at 2:38 AM, james_sg wrote: > > > > > 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<[hidden email]> > >>>>> 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<[hidden email]> > >>>>>>> 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. > |
the discussion about separating the framework came before version 4.0
was David's effort that separated the application and created the framework folder. And yes to garner interest in ofbiz the Ecommerce Application as well as the Engineering were added. If you have read the Data Model books Vol II you will see they are considered secondary application. It took me a year to seperate the "frame work" in ver 3.0. mostly because of the learning curve and lack of documentation. However it is possible even more so with Trunk. The problem is every is not on the same page as to what would be in the Trunk. That said, if you follow the commits you will see others are gradually cleaning up the dependencies, so there will be a Frame work stand alone at some point. Considering the Scope of ofbiz it seems to be a "normal" progression for a community based project. Shi Jinghai sent the following on 9/19/2010 6:50 AM: > I'm not sure whether I'm the 1st suggested standalone framework release. > But I have given it up. > > OFBiz was/is built for consultants' satisfaction, it's an ideal agile > system for consultants to prove ecommerce is possible and affordable for > everyone. > > Threads in this topic shows a typical discussion between a consultant > and a developer. They have different concepts on framework. > > As a developer, I think framework should only have tomcat, entity engine > and service engine. Auth? Tomcat has valve. > > Perhaps we can change framework to another word, for example, server. > > Shi Jinghai/Beijing Langhua Ltd. > > > 在 2010-09-18六的 10:56 -0600,David E Jones写道: >> James, >> >> I think that was BJ's point: the OFBiz Entity Engine is NOT an ORM tool, ie there is no attempt to map between an object model and the relational model in the database. We simply use the relational model itself. This reduces redundancy (you don't have to create an object model), and it avoid the often big/annoying problem of "impedance mismatch" between the two very different ways of modeling and managing data. >> >> I never did understand why the lords of Java always felt the need to map EVERYTHING to an object model instead of creating objects that make it easier to work with the natural model of each thing (ie relational databases, services, etc, etc). I guess once you get used to a certain way of doing things it's hard to imagine doing it in any way different. >> >> -David >> >> >> On Sep 18, 2010, at 2:38 AM, james_sg wrote: >> >>> >>> 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<[hidden email]> >>>>>>> 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<[hidden email]> >>>>>>>>> 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. >> > > |
Free forum by Nabble | Edit this page |