short answer is to add to webtools artifacts. Have you investigated that section of ofbiz? The basics is Java increases bloat by creating classes. I find the concept the ofbiz is java based is what throws a lot of people. The frame of mind that Ofbiz was made to work in a java environment is more accurate in my opinion. It takes more lines of code in Java to accomplish the same n minilang. However a happy medium is to use Grovvy.
I shy away from Opentaps because they broke the design rules that brought me to ofbiz. Justin Robinson sent the following on 11/19/2011 4:57 AM: > "But Minilang would be the better option because with Minilang, the > developers time is much reduced as it is used to implement simple and > repetitive tasks" - from the article OFBiz Framework: An Innovative > Approach to > E-commerce<http://www.dotcominfoway.com/blog/ofbiz-framework-an-innovative-approach-to-e-commerce> > > Why not overcome minlang's weakness..... > > Minilang seems to be one of the reasons for the branch in projects (well > that's entirely speculation on my part)....it seems a bone of contention > and I've seen posts where people complain about how difficult it is to > debug, how they've had to get rid of developers who refused to learn it. > On the wiki of one of the main down stream projects Opentaps it says: don't > ever write one in > minilang!<http://www.opentaps.org/docs/index.php/Danc_-_temp#Services> > > > I personally don't enjoy working in minilang, scanning hundreds of lines of > minilang & then using 'simple method' names together with "search & find" > to move between files to trace a path of execution looking for a bug or > that one small operation somewhere in the service chain I need to disable, > gives me a headache. > > However a couple of months ago I decided to rewrite a minilang method in > java so that I could alter it's functionality, it had to do with processing > returns, anyway by the end of it I had a better understanding of the *upside > to minlang*, because all it does is move data around by calling other > simple methods, *to write that in java takes a lot more code then it does > in minilang*....... > > Grouping business logic into modular scripts called "simple methods" and > then using what has be already been defined as building blocks to weave > into the already existing web of simple methods, your new customised higher > level service seems a good idea to me. > > The problem as I see it is there is no tool or framework to quickly get > information about what services exist, how would they'd effect the data and > what their IN's and OUT's are, in other words how they'd best fit together; > in order to define a new one that will fit the specific needs for the > service I'm writing. > When I use words like weave and web, anyone who has worked in minilang > knows what I mean. But how many GUI development tools exist to deal with > just that exact same problem in other frameworks? I can think of a few open > source eclipse plug-ins that would act as a good starting template, to > create such a tool. > > In some ofbiz supported enterprises I suspect that they, even have their > team set-up to get get around these problems, with say a master weaver who > facilitates the integration of new simple methods. > > Meta-programming definitely has it's advantages, but for places where it's > gained the most *popularity*, it usually comes with a tool which supports > it's use. > *Then every one ruled by reason can create service solutions in ofbiz, not > just the programmers willing to learn minilang!* > > I'd be more then happy to donate some time to such an undertaking if anyone > else thinks it's worth the effort? > >
