Cedric,
I get the same impression as Adrian too.
Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart
OFBiz at the source code level too.
Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be
spending way too much time doing brute-force studies from the bottom-up. Better to just learn from
playing with OFBiz framework (not the framework source codes), such as service engine and entity
engine, in this case.
While it is true that learning by playing with the framework will certainly be faster, I do admit
it is not as easy as many would hope. Technical references for working the OFBiz framework are not
all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there
are no "javadocs equivalent" for the OFBiz framework, except at
http://www.undersunconsulting.com/ecommerce/control/main .
In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't
use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang.
I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within
your scope" to learn the OFBiz framework in any way possible, such as from studying the source
codes or playing with the framework itself. No use complaining what isn't there; better to get
things working somehow.
For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice
polished expensive "welcome mat/carpet" for new users.
If you do want to get help learning the OFBiz framework, you can either work with me and write
down all that I've discovered through my own reverse-engineering, or you can employ some of the
experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current
project, so your help here would be much appreciated.
Hope you enjoy OFBiz as much as I have. :)
Jonathon
Adrian Crum wrote:
Cedric,
I might be wrong, but I get the impression you are trying to approach
OFBiz from the bottom up (examining java classes versus examining
higher-level layers). I made that mistake when I first got involved with
OFBiz.
It would be better to look at things like the service engine, entity
engine, screen widgets, etc. Get an idea of how the presentation layer
works, then work your way down to the service layer, then down to the
database schema, etc.
Typically, the only reason anyone would want to get into the java source
would be to fix a bug or make a modification at a very low level of the
architecture "stack."
PRONZATO Cedric RD-BIZZ-GRE wrote:
Re,
Yes you are true but I think I didn't explained myself.
These questions may have been answered in the javadocs. I am sure you
know (you that architects of OFBiz) why you decided to make a
Container class and so on.
So perhaps a little enhancement of javadoc on foundation classes to
explain why and where to use it would be so nice.
I hope I do not look like too much arrogant with my questions on that
thread "General questions"; I just expose the problems I was faced to.
Regards,
Cédric
-----Message d'origine-----
De : David E. Jones [mailto:[EMAIL PROTECTED] Envoyé : vendredi
9 février 2007 18:12
À : [email protected]
Objet : Re: General questions
On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
A related problem is how to do "framework" components, I mean
patterns. I think about my SMSC component, I base my code on the mail
container and questions arised:
- When do I have to make my own xml language (ie. MCA for the mail
container)?
- When do I have to make a Container? I guess the answer is if you
have to manage the lifetime (create/release connections, ...).
- When do I have to make an Engine?
- ...
So I guess we can finish with the following statement: "How to
*use* is quite well documented but how to *make* is a bit less".
Have you ever found such a document for anything?
My usual approach is generally something like:
1. understand everything that exists, or research anything that is
unclear 2. write something manually a number of times so you know what
is always the same, and what varies 3. see if a paramerized tool would
be helpful 4. apply a significant amount of "genius"
5. apply even more "sweat" to try stuff
6. create an incredible tool or service or however it is best implemented
If there was a way to make creation deterministic, what would be the
point of creativity?
-David
