Ian,
As discussed before, you would/could write whatever user docs you could just by using and testing
OFBiz. For any other functionalities you can't easily figure out that way, you can then pop a
quick question to me, and I'll do a 2-minute rip through the source codes to give you a definitive
answer (aka a "source codes say so, and that's how it works" kinda answer).
As for 10 minutes to know OFBiz, look through David's "overview of OFBiz
framework".
As for reading OFBiz like an open REFERENCE book, it has to do with the ability to rip through the
source codes inside of minutes to conclusively figure out what buttons do what actions/effects.
Jonathon
Ian McNulty wrote:
Jonathon,
Have just been thinking about what you've been saying about learning the
OFBiz framework inside of 10 minutes and how to read OFBiz 'like an open
REFERENCE book.'
A short document describing exactly how to go about such a thing
couldn't take more than 10 minutes to read by definition, and probably
wouldn't take you much longer than that to write.
I'd certainly be interested in reading such a thing and I bet a lot of
other people would too. It could be a major drawing point for our site.
Just a thought! (Or a wish fulfilment on my part perhaps. Wading through
the 1000+ pages of awful, miserable rubbish generated by Les Austin, the
technical writer drafted in by David at apparently huge expense. Wishing
I could find something myself that I could put together in a couple of
hours rather than a couple of months!)
Ian
Jonathon -- Improov wrote:
Cedric,
> Jonathon, a collaboration? Yes, why not? But I am sure I will not
show you
> much things because you are more experienced than me =)
I started looking at OFBiz framework in Jan 07 (last month). I
probably spent no more than a week(?) on learning OFBiz framework
itself; much of my time was spent on data mapping and struggling(!!)
with freeing my boss' data from legacy systems, and also on comparing
OFBiz with other solutions (he kept knocking OFBiz big-time). I had no
docs, no references (save xsd schemas), I even missed the cookbooks
altogether (which really are quite skeletal, anyway).
Believe me, OFBiz is easy to pick up.
Somewhat exact time requirements (in case your boss asks):
1. 10 minutes to learn structure of OFBiz, so you know how to move
around.
2. 1-2 minutes to look up anything related to OFBiz, since you'll be
reading
OFBiz like an open REFERENCE book.
> there are questions about the use of screen/form widgets and
> Beanshell/minilang. I am not well experienced but I don't know if
developers
> will like to learn these new things instead of working with what
they know.
As I mentioned in other threads, it IS possible to learn OFBiz inside
of 10 minutes.
But you could be right. IMHO, the lack of clear OFBiz framework
references (not videos that are unsearchable) may be hindering the
explosive growth of the OFBiz-enabled engineer population. Also IMHO,
an explosion in the number of OFBiz-enabled engineers will likely feed
back into OFBiz very rapidly. And further IMHO, David Jones (creator
of OFBiz) will then probably have a whole army of willing volunteers
to choose from (many open source projects employ ULTRA STRINGENT
qualifying criteria to screen volunteers before making them
committers; you do get many top brains in open source projects, so
good that you/I probably can't ever argue with those).
And finally, IMHO, I could be entirely wrong in above paragraph. I am
not David Jones; I never created an open source project myself.
Bottom line. OFBiz framework is solid (may need tweaks, but
enhancements are on the way all the time). I'll be sorry if I missed it.
Jonathon
PRONZATO Cedric RD-BIZZ-GRE wrote:
Hi all,
Yes, you are all true! My approach is bottom-up learning. All of you
here seem to read in me like an opened book; I now know that OFBiz is
a training area for FBI Profilers. :)
My aim (I think) was to fully understand the framework to be able to
change/replace/add new *core* functionalities and test them in a real
ecommerce environment.
Yet I never played with 'call to a service' or so as the documents
about that was enough clear. I said: All should be OK on this part.
Entity engine and Service engine are clear and in respect of all the
common and trusted laws of java development. (By the way is there any
plan to turn to the new standards? OFBiz was in advance in 2000 but
now much developer well knows Spring just to name one ...)
So after these 2 majors things there are questions about the use of
screen/form widgets and Beanshell/minilang. I am not well experienced
but I don't know if developers will like to learn these new things
instead of working with what they know. So I decided to not
investigate it much.
Jonathon, a collaboration? Yes, why not? But I am sure I will not
show you much things because you are more experienced than me =) I
will check about what I am allowed to do with my company policy but I
am confidant as OFBiz is a personal choice not too much tied to a
project need. I stay you tuned.
I now have to think about what is wrong on this approach, think about
what is the next thing I have to investigate ...
Thank you all,
Regards,
Cédric
-----Message d'origine-----
De : Jonathon -- Improov [mailto:[EMAIL PROTECTED] Envoyé : vendredi
9 février 2007 20:12
À : user@ofbiz.apache.org
Objet : Re: General questions
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
À : user@ofbiz.apache.org
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
