I believe the Agreement portion should be a part of the Party component, as was
mentioned previously. From my perspective, an Agreement will ALWAYS involve a
Party, whereas an Order MIGHT involve an Agreement.
Chris Howe wrote:
I agree on the benefit of loosely coupled
architecture, but for a different reason. I find it
beneficial as a community because if it were
modularized to the point of what I find ideal, the
different higher level functionalities would find it
easier to fork and we would only be worried about
solving our own problems and not each other's
problems. Finding solutions to each other's problems
gives us a more robust and closer to complete
application.
I do find the agreement dependency discussion to be a
bit of backward logic. An order is dependent on an
agreement, an agreement is not dependent on an order.
It's just that the agreement logic isn't as far along
as the order because most companies don't find as much
benefit in keeping track of agreements in a database.
As it is, I would find it beneficial to reorganize
quite a bit of the structure. However, this requires
quite a bit of community feedback to decide on the
logic patterns to be used. The project as it is today
follows pretty much a single logic pattern. While
others might make things easier to understand, mixing
of the patterns would make things, in general, more
difficult to understand. Moving agreement related
stuff would be mixing the patterns.
--- "David E. Jones" <[EMAIL PROTECTED]>
wrote:
Part of the point of a loosely coupled architecture
like the one we
use in OFBiz is the while reduction of dependencies
can be helpful to
keep things better organized, they are not
necessary.
In other words when a cluster of functionality that
is fairly
coherent (like the Agreement stuff) has dependencies
on other things
you can still keep it all in one place, even if it
results in cross-
dependencies. Of course, the other side of this is
that certain parts
of things are more "core" to a certain piece but in
addition may have
things that are not necessary that extend it and
those can and
usually should be put in other places (which is part
of the point of
the new extend-entity stuff).
Being able to keep this all together is one reason I
like putting it
in the order component. It makes sense for the most
common use of the
existing artifacts, plus it is a higher level
component and it is
fine for it to depend on lower level things like
Product, Party, and
WorkEffort.
-David
On Aug 16, 2006, at 8:00 AM, Jacopo Cappellato
wrote:
To summarize:
should we only move the following two entities
(and their services)
from party to product:
AgreementProductAppl
AgreementPromoAppl
and the following one from party to workeffort:
AgreementWorkEffortAppl
?
And move all the ui (and more complex services)
from accounting to
order?
Jacopo
Chris Howe wrote:
I like to think of the ideal dependency structure
this
way:
Party
Product
Content
Workeffort
The data layer and basic logic layer independent
of
each other and everything else, utilizing ONLY
itself
and the OFBiz framework. For ERP, this
essentially
creates an ERP framework. No UI. These are
basic
services, very simple simple-methods, etc.
In this thought experiment Agreement remains in
Party
as you can have Employment Agreements, Order
Agreements, Service Agreements, Warranty
Agreements?,
Content Agreements, Production Agreements, and
any
number of other agreements. Again, these four
would
have no UI outside of possibly something similar
to
what webtools provides or the state of these
components about a year to 18 months ago. The UI
would only prove as an example of the robustness
and
likely never used in production environment.
On top of that you build:
Accounting
Manufacturing
Marketing
Human Resources
Content Management
This again is your lower level data manipulation
logic. A lot of your "join" entity logic goes
here. (ie *Role,
*Content, *WorkeffortAppl?)
Next tier
Order
After these three tiers you can start building
interrelated operation applications that go on
top. This is where
real ERP logic goes and OFBiz actually
becomes useful in a business. You start getting
user
specific, purpose driven UI. This is where most
of the
backend UI begins.
After that ecommerce and pos get thrown on top as
UI
applications that have very little logic of their
own.
This sort of structure modularizes OFBiz and
makes it
very easy to see where custom needs begin.
Anyway, my two cents.
But you do need to keep in mind
employment agreements breaks any idea of moving
the
agreement data model over to product or order.
I'm
not sure if people's suggestions were to move the
data
model, or just the UI.
