> Additionally, Ofbiz follows many of the models only loosely with lots of
> added fields and entities. Even after having read this book twice and used
> Ofbiz for some 4 months, I still run across fields that I haven't a clue what
> they are for.
That is true. The Data Model book is the definitive guide here, IMHO. It's well thought-out.
Still, business requirements may or may not follow that book. I did ask long ago why OFBiz data
models don't follow that nice book. Can't recall seeing a response to that.
About the framework, there are quite a number of undocumented quirks. Some are half-implemented
features that could lead you running off a cliff. It will be good to have a comprehensive set of
docs that tell us exactly which features are available and fully implemented, and which switches
have quirks we need to watch out for.
The same goes for OFBiz. Months ago, I suggested that we shrink-wrap a version of OFBiz that has
only the "fully implemented features". Clients find it incredibly irritating to see features that
are half-baked whenever I showcase OFBiz to them. I haven't gotten that off the ground yet. As I
mentioned before (forgot where), I found it easier to market myself than to market OFBiz at the
moment. I intend to change that over the coming year, if I'm given the opportunity to do so.
> See, I am already forming this team in my head for the next job:)
I'm still looking to form that team. That's why I'm still fighting hard to doc OFBiz so I can
train new programmers on it. You have anything in mind now? Any programmer you wanna send to me
for test-training?
Jonathon
[EMAIL PROTECTED] wrote:
Jonathon
I agree with you almost completely. I also think the framework is well
documented. Any toon with minimal reading skills and a week can get up to a
fair speed. That documentation along with the examples and tutorials are a
complete introduction in my view.
The documentation on the ERP stuff though is abysmal. I know there is a
nice Data Model resource book, but it is my view that even if I find it well
written, many without previous modeling experience will not. When I bought
my book, I bought two, one for me and one for the client (with whom I've
have a long relationship). The client is very experienced in business and
has some programming skills as well. He's had the book now for 4 months and
still hasn't got a handle on the schema (I also gave him the schema
diagram). Additionally, Ofbiz follows many of the models only loosely with
lots of added fields and entities. Even after having read this book twice
and used Ofbiz for some 4 months, I still run across fields that I haven't a
clue what they are for.
In most of my previous work, the project leader knew almost nothing about
programming. It was his job to model the business, draw use charts and
prototype screens using some handy drawing tool, get it all agreed on with
the customer, then hand it off to us grunts to code.
It is my view that one person with indepth understanding of Ofbiz ERP is
required. That person does not need framework skills although it would be
REAL helpful. Then, two programmers who understand the framework at least
mostly, and a third screen designer who understood widgets and ftl. That
would make a hellofa team. I just spent the day coding some data munching
stuff that most any reasonably skilled java programmer could write; no
ofbiz experience required. It is therefore my view that only one of the two
grunts need to have indepth framework skills so long as they sit close
together or can collaborate using some fast means like IM.
See, I am already forming this team in my head for the next job:)
Skip
-----Original Message-----
From: Jonathon -- Improov [mailto:[EMAIL PROTECTED]
Sent: Friday, November 23, 2007 7:58 PM
To: dev@ofbiz.apache.org
Subject: Re: svn commit: r597479 -
/ofbiz/trunk/applications/party/entitydef/entitymodel.xml
> I still maintain that there is no such thing as too much documentation
> (unless it's bad).
I'm ok with that. I don't have a war machine behind a banner called "death
to redundant
documentation". :) I don't have war machines at all.
You just gave me an important tip. Is it true that a book on "OFBiz:
business application guide"
will be more useful than "OFBiz: a framework guide"?
The former is incredibly vast.
It seems you agreed with the fact that OFBiz projects need at least one
OFBiz expert who knows all
of OFBiz the business application. May work even if he doesn't know the
framework stuff.
Jonathon
[EMAIL PROTECTED] wrote:
Jonathon
I still maintain that there is no such thing as too much documentation
(unless it's bad). I have hundreds of books that refer to regularly so I
don't have to remember details I us only infrequently.
I initially was going to put a screen designer with me on the current
project to write the widget and ftl code because I don't have the
imagination to be able to know a good UI screen before I see it working
and
others with us do. Sadly, that did not work because I spent so much time
hunting down answers to questions like "what does this field do?" that I
couldn't get any work done.
Such a shame too because these excellent UI designers are typically poor
programmers.
Skip
-----Original Message-----
From: Jonathon -- Improov [mailto:[EMAIL PROTECTED]
Sent: Friday, November 23, 2007 3:40 AM
To: dev@ofbiz.apache.org
Subject: Re: svn commit: r597479 -
/ofbiz/trunk/applications/party/entitydef/entitymodel.xml
Skip,
Well, not yet. About 10 months ago, I proudly voiced an ambition to create
enough documentation to
rapidly train a whole bunch of OFBiz-capable developers or engineers. I'm
not there yet.
Frankly, I don't know if publishing a comprehensive "Guide to OFBiz" will
help or hurt the
project. Actually, I think I don't know much at all.
We'll see next year if I'm a boon or a bane. Oh well.
Here, please pardon my terminology again, I don't know how else to say
this.
(This has irritated
David before). There are 2 parts to OFBiz. The framework, and the ERP
aspects. The framework is
huge, but is really tiny compared to the ERP aspects in OFBiz that works
OOTB. It should be
possible to have an army of developers who only know the framework aspects
of OFBiz, assign a
single OFBiz expert (who knows *all* of OFBiz), and produce great
software.
Not yet. Not yet...
Jonathon
[EMAIL PROTECTED] wrote:
David
On this knowledge/experience point, I was talking about teams of people.
You have one (or more) team leader with a full grasp of the concepts and
others who write code under their direction. I do not think a single
person
could attempt Ofbiz without a full understanding of the issues. In this
team environment, the majority of the contributors only need knowledge of
their specific area.
I would bet a dollar to a donut that this team implementation is
happening
now in many instances with some of the members not having a full grasp of
the business or database aspects.
Skip
-----Original Message-----
From: David E Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 22, 2007 11:47 PM
To: dev@ofbiz.apache.org
Subject: Re: svn commit: r597479 -
/ofbiz/trunk/applications/party/entitydef/entitymodel.xml
I hope I don't burst any bubbles... but this specific paragraph has a
couple of real doosies (IMO of course):
On Nov 22, 2007, at 10:23 PM, [EMAIL PROTECTED] wrote:
I was also trying to point out that "obvious" is always relative to
experience and education.
To some extend, yes, but I think you gave examples of where this is
not the case. The real point of this was the informational content, ie
the lack of redundancy and other information theory 101 types of
things (well, that certainly wasn't a 101 class when I took it, but
this part of it is a basic concept).
I promise you that over the life of Ofbiz
(assuming that it becomes as successful as I think it will), the
majority of
those who write code for it will have zero business experience and
little to
no database experience.
This may very well be the case, of course all such people are welcome
in the OFBiz world. However (and this might be the big bubble bursting
part...), if such people think they can contribute over a reasonable
scope and period of time they will HAVE to learn about such things.
These are things that are not made up in OFBiz, but rather things in
the world that OFBiz uses (ie OFBiz is a consumer or carrier of the
concepts not the producer).
I'm guessing you get this and the above was just a partial thought...
if so forgive me for taking your thought and walking with it for a bit.
-David
