OK Guys. I was hoping to keep quiet until I had something useful to
show, but the cat is now out of the bag. I've been sitting at my desk
solidly for 13 hours now trying to make a contribution by trying to pull
together the User pdfs into something useful and I'm rapidly losing my
marbles.
I'm sure David and Les did an excellent job under the circumstances.
It's just that the pdfs contain so many html tags and complicated
paragraph numbers which need to be cut out. I've been suffering from RSI
in my mouse arm for several years now and dragging and dropping 1000
pages of text is causing me a lot of misery and pain. I blasted off a
reply to Jonathon's over-bounding enthusiasm without stopping to count
to 10.
Not an excuse. Just some kind of an explanation, if such a thing is
possible.
I guess Jacopo proved to be right in the end. I have ended up as nothing
more than a troll. Sad or wot? :(
Ian
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
--
----------------------------------------------------------------------------------------------
mcnultyMEDIA
60 Birkdale Gardens
Durham
DH1 2UL
t: +44 (0)191 384 4736
e: [EMAIL PROTECTED]
w: www.mcnultymedia.co.uk
==============================================================================================
This communication is for the exclusive use of the intended recipient(s) named
above and is confidential. Any form of distribution, copying, discussion or use
of this communication, its contents, or any information contained herein
without prior consent is strictly prohibited. If you receive this communication
in error, please notify the sender by email or by telephone on +44 (0)191 384
4736
This email has been checked for viruses, however, we cannot accept any
liability sustained as a result of software viruses and would recommend that
you carry out your own virus checks before opening any attachment.
==============================================================================================