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<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.
