Skip,
> Ah well, "undocumented" is probably not the right word given that we all
> have the source. Perhaps "hidden" might be better? But no, that would
> imply the intent to hide something which is surely not the case. Perhaps
> "unpublished"?
Actually, for open source and free software, "as is" is the key phrase. We give it to you
"as is". :)
> This is all tongue-in-cheek David. My point is that here is a really cool
> feature that went un-noticed by me after looking through all the
> documentation
And that's why some people are paying folks to write in-house documentation.
> It is a simple matter to request that submitters provide at least minimal
> documentation for new features that the committers can then include in the
> base documentation, especially in the entity and widget and other "engines".
Then we'd get less submitters. I don't even write JIRA issues! *apologies*.
> There is no value in any software if the implementer has to spend countless
> hours experimenting and digging through source code to implement some new
> feature, fun as such an exercise may be.
Agreed totally. And that's why there is business in training folks to use OFBiz. I've gotten an
average of 3 week-long engagements per month. :) Meet all kinds of folks, though, heh. I *am*
funny. :P (playful reference to David's Willy Wonka).
> And who sez that "Documented features are somewhat the exception, not the
> norm." in open source software. I can point you to scads of open source
> software with excellent documention, and some of it used by Ofbiz itself
> (ftl and tomcat come instantly to mind).
Tomcat documentation was incomplete before. It's always work-in-progress.
FTL is smaller than OFBiz, in a way.
Common ground between those: they are specialized packages that deal with a widely needed layer --
the webserver and the templating (MVC).
Those projects will naturally get more use than OFBiz. It's like a toothbrush gets more market
than a laptop. More ROI in documenting those completely.
And yes, some authors make a living documenting popular tools like Tomcat and Joomla and
osCommerce and such. Reverse-engineers make a living doing hands-on training soon after the
technology is published.
Maybe it's not entirely true that documentation is the exception and not the norm. I'd say it's
all down to market supply-and-demand.
> Also, have an overview look at the most successful open soure projects. All
> (that I know of) are very well documented. The success of any open source
> project is determined by its committers and the quality of their code. The
> more committers, the more successful the project becomes. You get more
> committers with good documentation.
Chicken and egg issue that David and I fought over in epic battles, since my joining OFBiz
community in Jan 2007. :)
But like David, I need to make a living too. I once suggested we do an "OFBiz Engineer's Guide".
Sadly, my altruism often gets bought over by the highest bidder.
Yeah, you did hit a sore spot. If I weren't working with highest bidders right now, I'd be
shooting back at you sorely. :P And yes, I must humbly admit that I do lots of codes that didn't
make it back into OFBiz. Maybe if I change that, I'd be really sore.
If we all earned $10K per month for spending 40-hour weeks in OFBiz ML, I'd probably be going
around greeting people like "hey sunshine, how's the weather?". :)
Jonathon
[EMAIL PROTECTED] wrote:
Ah well, "undocumented" is probably not the right word given that we all
have the source. Perhaps "hidden" might be better? But no, that would
imply the intent to hide something which is surely not the case. Perhaps
"unpublished"?
This is all tongue-in-cheek David. My point is that here is a really cool
feature that went un-noticed by me after looking through all the
documentation and a substantial part of the source code, including the
documentation in the link you provided. Someone added this feature,
apparently a couple of years ago, but did not take the 5 minutes to note its
existance.
It is a simple matter to request that submitters provide at least minimal
documentation for new features that the committers can then include in the
base documentation, especially in the entity and widget and other "engines".
There is no value in any software if the implementer has to spend countless
hours experimenting and digging through source code to implement some new
feature, fun as such an exercise may be.
And who sez that "Documented features are somewhat the exception, not the
norm." in open source software. I can point you to scads of open source
software with excellent documention, and some of it used by Ofbiz itself
(ftl and tomcat come instantly to mind).
Also, have an overview look at the most successful open soure projects. All
(that I know of) are very well documented. The success of any open source
project is determined by its committers and the quality of their code. The
more committers, the more successful the project becomes. You get more
committers with good documentation.
This is not so say that Ofbiz documentation is bad. It's just not as good
(read that complete) as it could be with a few policy changes.
Skip
-----Original Message-----
From: David E Jones [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 04, 2007 1:07 PM
To: user@ofbiz.apache.org
Subject: Re: Entity engine, "many" relations, foreign keys
On Dec 4, 2007, at 1:57 PM, [EMAIL PROTECTED] wrote:
Gads Adrian. I never knew of the existence of this tag. Thanks.
It is
perfect. Someone needs to document it in the entity engine guide or
at
least somewhere prominent. I just did a search for this tag and found
dozens of uses, but somehow, I missed it even though I looked at
OrderHeader's definition a gazillion times.
Are there any other cool undocumented DB features?
Undocumented features? You're funny. ;)
This isn't commercial closed source software where the only way you
can find out about a feature is through documentation. Documented
features are somewhat the exception, not the norm.
Of course, there are significantly more complete materials available,
like these:
http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diag
rams
-David