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 <[email protected]> > > 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" <[email protected]> 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... > >
