Jonathon, What are you finding so confusing about minilang that is not covered here http://docs.ofbiz.org/x/GAM ? This document has been improved upon recently, but the bottom half has been accessible from the ofbiz.org site for two years that I can attest. Coming from someone who had ZERO java experience starting with OFBiz (me) I find the elements are rather self explanatory. It's also not as if there aren't plenty of examples using each one. I have no idea how well minilang would hold up to creating various kinds of other programs, but for writing business logic, it's pretty straight forward. If you're not finding that to be the case, please ask questions there are plenty of people here more than willing to help clarify.
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. 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. I digress, just ask questions. If you're unable to find your answer on a first pass through nabble and on the ofbiz.apache.org ask the question to the mailing list and someone may be able to find the right document for you a bit faster or clarify a point in a document that may be a bit unclear. --- Jonathon -- Improov <[EMAIL PROTECTED]> 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 > === message truncated ===
