On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
Chris,
Framework independence has been a goal for quite a while. There is no
disagreement that the framework should run on its own. The
disagreements arise in what constitutes the framework.
Let's assume for a moment that framework independence means
running the
components in the framework folder independently from anything
else in
OFBiz. Right away the problem with that idea is that visual
themes are
in a separate folder outside the framework folder. Does framework
independence include the visual themes folder? That has not been
discussed. Then there are the multitude of dependencies upon the
applications folder.
I'm a newbie here, but I have a lot of gray hair. Seems like
trying to
separate dependencies by folder or subject matter is an exercise
doomed
to failure.
TCP/IP has taken over the world because it has a clear model based on
separate layers (the 7-layer OSI model). Changes on one level (like
10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
rest. Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
means to map IP addresses to hostnames at the application layer--
TCP/IP
doesn't care.
From my perspective, achieving this objective will require a two
pronged approach: 1) Identify the framework dependencies on outside
components, and 2) avoid introducing new framework dependencies on
outside components.
This assumes the "framework" is the lowest level. If the framework
depends on outside components, then the hierarchy has been upset, and
spaghetti dependencies are the inevitable result. Dependencies
HAVE to
be unidirectional, or you never get out of the maze. IMHO, the
biggest
problem with MVC is that it has never seemed to me that the layers are
very well defined. Everything seems pretty interdependent, and you
quickly get into a rock/paper/scissors kind of analysis, as you
describe.
Is there a comprehensible map of the layers in OFBiz? All I have seen
is very detailed charts that seem to obfuscate, rather than
clarify, the
relationships of the various modules. But I'm sure I have not seen
everything. Is there a 30,000-foot overview of the software levels?
The first prong can be accomplished through contributions from people
like you - find the dependencies and create patches to fix them.
The responsibility of the second prong is up to the committers. We
need
to be more vigilant to guard against introducing new dependencies.
Which requires a clear model of what layer the code under
consideration
belongs to, and what are the well-defined layers below it that can be
dependencies.
Personally I believe it will be possible, BUT it won't be easy. The
obstacles to overcome will be getting people to contribute to the
effort, and getting committers to avoid introducing new
dependencies.
Again, I think we need to reduce the learning curve by providing clear
maps. You shouldn't need to know everything to be able to contribute
meaningful and error-free code.
-Adrian
--- On Fri, 2/5/10, Christopher Snow <sno...@snowconsulting.co.uk>
wrote:
From: Christopher Snow <sno...@snowconsulting.co.uk>
Subject: what a mess! is framework independence ever going to be
possible?
To: user@ofbiz.apache.org
Date: Friday, February 5, 2010, 10:58 PM
I'm back to the process of working
out how to get a standalone framework running based on
trunk, but I have found that the dependencies have got out
of hand (if I've understood the code right):
Framework depends on Themes
Themes depends on Content
Content depends on Party
The questions I'm starting to ask myself are:
"Is is ever going to be possible to have framework
independence in trunk? Independence in 9.04 is
relatively trivial (rewrite security screens) perhaps the
most sensible thing would be to do a fork of 9.04 and then
back port all framework related commits from trunk? "
Any ideas anyone?
Many thanks,
Chris
--
Matt Warnock <mwarn...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.
