You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Justin Robinson <ju...@venturenet.co.za> on 2011/11/19 13:57:39 UTC
Why not overcome minlang's weakness.....attract new developers
instead of letting something so easily fixed scare them off
"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?
--
Regards,
Justin
Venture-Net Research & Development
Re: Why not overcome minlang's weakness.....attract new developers
instead of letting something so easily fixed scare them off
Posted by Erwan de FERRIERES <er...@nereide.fr>.
Le 22/11/2011 02:25, Anne a écrit :
> Last week I attended the Open Source Developers Conference in Australia. I
> went to a few talks that discussed using Groovy to create a DSL. At the
> time, I thought it would be a great replacement for minilang. Properly
> designed, it could have all the benefits of minilang, combined with the
> benefits of Groovy, and the possibility of compiling to a jar for
> production. An added advantage is that groovy is already fully supported
> OOTB in OFBiz, so no new third-party jars need be added.
>
> One such talk was "Groovy DSLs from beginner to expert" by Paul King, the
> slides of which are available on slideshare.net. One of his examples was a
> Medical Prescription DSL, where the resultant groovy script was:
>
> take 2.pills of chloroquinine after 6.hours
>
> Unfortunately I don't currently have the time to work on the design and
> implementation of a groovy-based DSL for OFBiz. :-(
>
> Cheers,
> Anne.
>
>
>
>
> On 22 November 2011 04:32, BJ Freeman<bj...@free-man.net> wrote:
>
>> 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.
>>
>>
>>
>>
>> kiran@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<bj...@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?
>>>>
http://www.slideshare.net/paulk_asert/groovy-dsls-from-beginner-to-expert
and there are a lot of interesting conferences on parleys.com, which are
free to watch !
>>>>
>>>
>>>
>>
>
>
>
--
Erwan de FERRIERES
www.nereide.biz
Re: Why not overcome minlang's weakness.....attract new developers
instead of letting something so easily fixed scare them off
Posted by Anne <an...@cohsoft.com.au>.
Last week I attended the Open Source Developers Conference in Australia. I
went to a few talks that discussed using Groovy to create a DSL. At the
time, I thought it would be a great replacement for minilang. Properly
designed, it could have all the benefits of minilang, combined with the
benefits of Groovy, and the possibility of compiling to a jar for
production. An added advantage is that groovy is already fully supported
OOTB in OFBiz, so no new third-party jars need be added.
One such talk was "Groovy DSLs from beginner to expert" by Paul King, the
slides of which are available on slideshare.net. One of his examples was a
Medical Prescription DSL, where the resultant groovy script was:
take 2.pills of chloroquinine after 6.hours
Unfortunately I don't currently have the time to work on the design and
implementation of a groovy-based DSL for OFBiz. :-(
Cheers,
Anne.
On 22 November 2011 04:32, BJ Freeman <bj...@free-man.net> wrote:
> 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.
>
>
>
>
> kiran@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 <bj...@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?
> >>
> >>
> >
> >
>
--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sales@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Re: Why not overcome minlang's weakness.....attract new developers
instead of letting something so easily fixed scare them off
Posted by BJ Freeman <bj...@free-man.net>.
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.
kiran@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 <bj...@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?
>>
>>
>
>
Re: Why not overcome minlang's weakness.....attract new developers instead
of letting something so easily fixed scare them off
Posted by ki...@objectedge.com.
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 <bj...@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?
>
>
Re: Why not overcome minlang's weakness.....attract new developers
instead of letting something so easily fixed scare them off
Posted by BJ Freeman <bj...@free-man.net>.
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?
>
>
Re: Why not overcome minlang's weakness.....attract new developers instead
of letting something so easily fixed scare them off
Posted by ki...@objectedge.com.
Hello Justin,
I agree with you.
I haven't tried converting mini-lang to Java method so far. But I believe,
the pain of converting the mini-lang code to Java can be made simpler, if
we implement an AbstractService class with many utility methods.
Two other drawback of mini-lang are:
1. It is interpretive nature and forces heavy use of reflection. And it
would definitely have performance implication. Not sure if there are
benchmarks published for throughput.
2. Doesn't support extension by inheritance (template method pattern).
There are two choices:
1. Write the plugin to simplify coding in minilang.
2. Convert services in minilang to Java
I would prefer the second option as there is limited development community
for ofbiz. And creating the plugin for mini-lang and maintaining it would
be difficult. Whereas many users can help us in this migration. e.g: I can
help migrate all the simple services in ecommerce. Someone else can do the
same for other application.
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: Justin Robinson <ju...@venturenet.co.za>
To: dev@ofbiz.apache.org
Date: 11/19/2011 09:59 AM
Subject: Why not overcome minlang's weakness.....attract new
developers instead of letting something so easily fixed scare them off
"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?
--
Regards,
Justin
Venture-Net Research & Development