I am not sure how you first paragraph relates to minilang and jumping. Minilang is defines as events (not ECA) or Service in other places. This is the same for Java and would require the same tracing. ECA are keyed off of ENtities changes and Service, whether Minilang or Java.
Simple has nothing to do with the length of code but making a line of code that takes multiple java code lines to accomplish. I do agree that all mini code should be reviewed and take repetitive code and break it out as a re-factor. That is a major effort and based on the way people code and add to the SVN without reviewing what code is available, I doubt it would stay clean. ki...@objectedge.com sent the following on 11/20/2011 8:21 AM: > I agree that minilang is easy understand as long as the methods are truly > simple. i.e: you don't have to jump between other methods/services, eca > rules, etc. > > Take an example of createCustomermethod in ecommerce. This simple-method > is over 400 lines. How is that simple :-) Now whether you write it java or > minilang it will be difficult for the reader to understand. But I feel it > is better to write such methods in Java. Of course, even in Java it should > be made more modular (using refactoring tools). Then you can use find > references or implementation. Selecting variable highlights it across > entire method/class. You can use debugging tools: set breakpoint, view > variables, step in/over, drop to frame, etc. > > Ideally the simple-method shouldn't grow beyond scrollable window in > Eclipse say 40 lines. > > Regards, > Kiran Gawde > > Senior Software Architect > Object Edge Inc > (925) 943 5558 x108 > > "There are two kind of people: Those who do the work and those who take > the credit. Try to be in the first group because there is less competition > there." > "Never give up on what you really want to do. The person with big dreams > is more powerful than one with all the facts". > > > > > From: BJ Freeman <bjf...@free-man.net> > To: dev@ofbiz.apache.org > Date: 11/19/2011 06:07 PM > Subject: Re: Why not overcome minlang's weakness.....attract new > developers instead of letting something so easily fixed scare them off > > > > 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? >> >> > >
