Andrew,
Yeah, we all tried. Maybe I have my head so buried in Java I can't see the
simple methods in Minilang.
For now, given a hot-soup mix of problems from screen/form widgets and problems with some
constructs in Minilang, I'm forced to drive things forward this way: Use Java services but
leverage every convenience method in Minilang.
Once I'm done with this current project (or when I'm fired), I can come back here to "explore and
contribute". Oh well. Back to work. :( ... :) ... :/
I still say that OFBiz rules! And I intend to prove my instincts right, after
I'm done with project.
With regards Ian's comments, I personally like winning the Le Mans (less docs, more progress, but
then why do bugfix rates seem to slow down recently?). I'm a wannabe race car driver who takes
apart race cars, so I don't quite care for driver's manual in glove compartment. But then, I'm
also NOT known for having a forte in amassing world-wide adoption for OFBiz, nor can I be held
responsible for OFBiz's future popularity. :P
Jonathon
Andrew Sykes wrote:
Jonathon,
Ok, well, I tried ;-)
- Andrew
On Thu, 2007-01-18 at 21:51 +0800, Jonathon -- Improov wrote:
Andrew, Chris, Ian,
I would definitely choose Minilang over Java, if I didn't have a pressing "do it this minute"
schedule. It is definitely the right step forward.
I tried Minilang for a while, then realized there ARE some constructs I can't quite do like I
would with Java. Same for screen/form widgets. I posted a short question asking if there's any
docs for screen/form widgets. No response thus far. But I've since learned what env-name,
map-name, etc mean. Not by docs I can find, but through the widget framework Java sources. Simple
concepts like "how do I extract a field value and put it to a variable for later use", or even
"how do I create a variable for computation" required some digging into widget framework Java sources.
So, what did I do? I got the job done. Java works. Minilang can wait. :P Screen/form widgets can
wait (I used a Java service attached by an ECA).
Did I do a messy buggy Java routine? I'd ask you the same question. With some basic programming
principles, it's not difficult to write reusable extensible code (see the mutable checks sequence
I wrote for http://issues.apache.org/jira/browse/OFBIZ-627).
Sure, I'll eventually find it easier to do things in Minilang. Many Minilang constructs are direct
clones of Java functions anyway, so converting from one to the other and back won't be so tough.
But it's the variables, scope, "where did that variable's value got stomped" problems that put the
brick wall up for me.
So, as things stand now, I (being a Java programmer of sorts), found it easier in Java. A simple
Java programmer like me knows certain "tricks of trade" to figure out the structure of Minilang or
widget XMLs. But what about non-programmers?
> 6/ So much functionality is already implemented in minilang that you ignore
> it at your peril.
Anyway, I am able to tap all of Minilang's features using Java alone, so I do get best of both
worlds. :)
Actually, to be fair, Minilang isn't so bad in terms of docs (by now? recently?). See
http://ofbiz.apache.org/docs/minilang.html . I was really struggling with widget XMLs.
Right now, my project is moving ahead. And that's what counts. Sigh. Couldn't there be a time when
we abolish work, and everybody does things simply for exploration and science?
Chris,
> Also, documentation doesn't write itself. If you find
> something that didn't work as expected or a task was
> difficult to accomplish but you eventually accomplish
> it, do a short write about how you got from point A to
> point B and drop it into the wiki on docs.ofbiz.org or
> write it to the mailing list and ask if someone can
> find an appropriate place for it.
I'd be fired! I did try to get quickstart advice from mailing list, remember? But now that I've
posted questions, waited for response, dug in myself, and found answered my posts myself, I can't
find much time left to write up those docs. I don't even have enough time to submit my
enhancements and bugfixes!
Yes, bad bad programmer, not very opensource-spirited. But like I said, I can be a very
opensource-spirited non-programmer (after being fired), or I can just "do my job" and hope I can
swing back some time to contribute.
And I'll definitely want to do something for OFBiz. As I told someone here before, I'm thoroughly
enjoying OFBiz (like the manufacturing and product Virtual BOMs stuff done by Jacopo?).
> There's a funny point in learning OFBiz. You start
> out looking at it as this huge monstrosity that's just
> too much to figure out and you get frustrated with the
> lack of documentation available (even given the sites
> linked off of ofbiz.apache.org and the tens of
> thousands of mailing list posts available and the
> number of video tutorials available). But you start
> playing with it a bit, and you pass an "aha" moment.
> You don't realize the moment that you pass it but when
> you look back and think "how can I make the learning
> curve easier for the next guy", you realize everything
> was there, and it's difficult to figure out what you
> can add to those websites that could make it any
> clearer.
Hindsight is always easier. I know what you mean, Chris.
It's like we stare at some seemingly random numbers scrolling through screen, we think it's noise.
But after we spot the patterns, we wonder how we didn't see it before!
I can't learn "The Matrix green downward-scrolling font" inside of 1 week. I need to get into the
Matrix and do some work RIGHT AWAY (like run the nice noodle restaurant at the corner). So,
instead of reading those green fonts, I pulled out the Matrix engine and started plugging away at
the interfaces. (Aha! So touching this and that interface gives me very good soup noodles!).
Jonathon
Andrew Sykes wrote:
Ian, Jonathon,
I definitely don't agree with treating Java is your language of choice
as a way to avoid learning Minilang, here's some reasons why...
1/ Minilang is far quicker to write.
2/ Minilang is much more limited in scope, so less danger of...
2a. Writing unidiomatic code
2b. Writing buggy code
3/ Being a simpler language, minilang can be handled by far more junior
personnel, and in some cases, I've seen non development staff being
fairly productive.
4/ Java developers are easier to hire, but not ones with a good
understanding of the OfBiz API.
5/ Learning minilang is a fast-track route to adopting the OfBiz
developer's mindset.
6/ So much functionality is already implemented in minilang that you
ignore it at your peril.
7/ When you finally have to adopt Minilang you'll have a load of
unmaintainable java legacy. This will no doubt seem more and more
cryptic as time goes on.
I could probably go on...
This type of approach breaks the golden rule when adopting something as
large as OfBiz, that is, read read read!, learn learn learn!, and only
then should you think of letting yourself loose on the code! You'll
thank yourself later!
No doubt various people will counter this with a whole lot of personal
dislikes about minilang, but I'll be surprised if any of these people
have been using OfBiz in anger for any length of time.
Sorry if this seems a little condescending, but I've seen this kind of
argument in my consultancy work several times, and the resulting costly
dodgy java or furious back-peddling that results from it.
- Andrew
On Thu, 2007-01-18 at 19:38 +0800, Jonathon -- Improov wrote:
Er, Ian. I forgot to mention this.
The docs for engineers aren't too comprehensive either. Try putting your best Java developers into
picking up OFBiz. Take the screen widgets and form widgets for example. See how they fare. Like I
said, Java is more documented than OFBiz-specific technologies.
BUT.. but it's entirely possible to use Java only, plus non-OFBiz-specific technologies like
Freemarker for front-end development convenience, and to skip Minilang and screen/form widgets to
a large extent. Non-OFBiz-specific technologies are generally better documented since their
developers focus develoment time solely on those techs, like Freemarker (front-end tool)
developers don't delve into entity engines (backend tools).
As I was telling my boss, it's actually easier to hire Java programmers than to hire Minilang or
screen/form widget programmers.
So, beware of the implications. Say I code customizations for you in Minilang and screen/form
widgets, using almost or entirely zero Java. Future tech support could be an really hairy issue
for you.
BUT... at some point (I can't guarantee when), Minilang and screen/form widget docs will be
complete, audited to be comprehensive, etc. You'll then probably find that programming in Minilang
is more cost-effective than in Java. (Either that, or I get paid by someone to completely
reverse-engineer and document all of Minilang and screen/form widget in a reasonable timeframe ---
say a month. Not an impossible task, just a mountain of Java codes, is all).
For now, Java is perhaps your best bet.
To the other folks in overalls, I've been meaning to ask this. Is there any way at all to insert
debug messages inside of Minilang and screen/form widget codes? I find it easier to debug Java
codes for now.
Jonathon
Jonathon -- Improov wrote:
Ian,
Amen! Yeah, God is good. OFBiz is good. Both can be hard to understand.
But I do believe that both are loving, very loving. Amen.
If there's any way we can all help each other (Paul, Ian, Jonathon), let
me know.
Jonathon
Ian McNulty wrote:
Hi Jonathon and Paul,
Could I dive in here and say I'm currently trying to get a working
model up and running that I could demo to small business clients in
the UK.
OFbiz looks so beautifully designed from the ground up, streets ahead
of the competition and adaptable to almost any situation from running
a one-man consultancy to a multinational enterprise.
It looks like the most awesome super-car you've ever seen. I can't
believe everybody won't want one.
As Jonathon says, the community seems entirely focussed on moving
forward rapidly and winning the next Le Mans. Which is how it should be.
Imo this explains the lack of docs and the small bugs. The mass of
available documentation is actually almost as awesome as the framework
itself. Problem is that it is all aimed at engineers who need to
understand how it works ... not how to work it. Enough workshop
manuals to fill shelves in the garage, but no simple driver handbooks
you can put in the glove compartment.
This is a very fundamental difference. An entirely opposite point of
view.
Try talking to the average driver about the thermodynamics of
combustion and they glaze over in seconds. They neither need nor want
to know. They simply want to drive it. They pay the garage to take
care of all that for them so they can free themselves up to deal with
other things - like where to drive to.
It's the little, superficial things that are most important. How does
the door latch sound? Where is the gear shift and indicator switch?
How often does it break down?
This is true for all levels of users. More so in fact for the
President of a large Corporation to whom image arriving at the golf
club is everything, than to the small businessman in the street who
accepts he may have to get his hands dirty occasionally.
Winning the Le Mans is obviously a huge selling point and an essential
place to start. In those circumstance, a door latch which needs a
knack to open, the absence of a drivers handbook and the need for team
of mechanics to tune it before every race is absolutely par for the
course. And a racing driver who complains about such things will -
quite rightly - be quickly shown the door.
But for the average driver in the street it's exactly the opposite.
One sticking door latch, one miss-start, one breakdown on the first
test drive and they've had their one bite of the cherry and ain't
never coming back for more.
Imo this is the only problem I'd like to see solved.
I started out a few weeks ago trying to point out that this list is
more for users in overalls at the pit stop than drivers in business
suits on their way to the office.
Imo a forum for user-drivers rather than user-engineers would help
focus the view from the other end of the telescope and prevent
discussion of such superficial issues from clogging the inboxes of the
rocket scientists who really need to be concentrating on getting us to
Mars.
I personally would like to contribute towards the development of some
kind of drivers handbook. But if I can't get a working model going for
myself then it's hard to know where to start.
Ian
Jonathon -- Improov wrote:
Hi Paul,
I believe I'm currently doing it for a small business as well.
You'll need to customize. Customization in this case involves
defaulting many values and code execution paths for a more condensed
workflow. That is, you can cut out some unnecessary steps in the
workflow and also auto-populate default values for some fields (or
leave them blank and unused).
I propose that we work together on this? I have yet to hit the
accounting and GL side of things. I have figured out the ecommerce
(PO, SO) and product configuration side of things, though. And also
manufacturing, because my boss does manufacture stuff.
You'll find that being a novice Java developer is ALL you need to be,
the framework is that easy to use. Well, you also need acute
reverse-engineering skills because the only way you'll find out how
things work is by diving into the framework source codes (see
GenericDelegator.java for entity-related functions). No docs.
Community is too being moving OFBiz forward rapidly.
In fact, you may find it easily initially to use Java instead of
Minilang. Java is a lot more documented than Minilang.
Tell you what. I can offer you very quick answers to "how do I do
this or that". I'm a reverse-engineer by trade; I have small crack
teams that mathematically take apart legacy system codes to break
vendor-lock for my clients. So, figuring out OFBiz, given that it's
opensource no less, is really... an interesting exercise, not a
tedious impractical one.
You can help me with your accounting knowledge. (Yes, help me!! I beg
you!)
How about that?
One warning, though. There are quite a few bugs in OFBiz. They're
small issues if you can dive in to fix them yourself. But if you're
waiting for the community to fix them, you could be looking at weeks
before a patch goes in, especially for non-trivial fixes that take
time to review/audit. I'm currently holding quite a number of fixes
in-house, not yet reviewed by community and merged back into OFBiz.
I'm deploying a customized system for my boss inside of 1 month. And
he has quite a bit of customizations to do, particularly for the
manufacturing side of things. Oh, the Manufacturing module is very
feature-rich (thanks Jacopo!), just that my boss has special needs.
I'd say we could work together and customize OFBiz for you inside of
2 weeks?
Jonathon
Paul Gear wrote:
Hi folks,
I'm looking at different accounting/business management packages for
use
in my small business, and i was excited when i found how comprehensive
and easy to install opentaps was.
However, it is a daunting application for the beginner, and it leads me
to ask: is it asking for trouble trying to use it as a small business
accounting package? My requirements are fairly simple: invoicing
(services only, no inventory), general ledger, and GST tracking for the
Australian tax system.
I'm a novice Java developer, so i can get through most basic problems
OK, but understanding the framework is a bit more complex an
undertaking. Am i just creating work for myself thinking that i can
use
OFBiz/opentaps for my small business?
Thanks in advance,
Paul
<http://paulgear.webhop.net>
--
Did you know? Using HTML email rather than plain text is less
efficient, taking anywhere from 2 to 20 times longer to download, and a
corresponding amount more space on disk. Learn more about using email
efficiently at <http://www.expita.com/nomime.html>.
