You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2012/03/08 19:02:39 UTC
Groovy services and a DSL for OFBiz - a POC
Hi all,
I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
Please review my notes here:
https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
Regards,
Jacopo
PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
Okay, well it seems I am not able to articulate the advantage of keeping
things generic and extensible - so I will stop trying.
-Adrian
On 3/9/2012 1:16 PM, Jacopo Cappellato wrote:
> On Mar 9, 2012, at 12:59 PM, Adrian Crum wrote:
>
>>> What I don't see in your plan is what we want to do with the existing "applications" code and new code that will come: continue with Minilang, switch to Groovy, use a mix of languages?
>> Anything we want. As long as we keep it generic, we are free to add/remove any scripting language. On the other hard, if we make it all Groovy-centric, then we have a lot of re-engineering to do if we decide to make a change.
> I really don't see how using a Groovy specific DSL for OFBiz would make the system more Groovy-centric than using Groovy with a generic/general purpose helper class.
>
> OFBiz (I mean the applications, not the framework) will become Groovy-centric if and when we will decide to use Groovy as the primary language to implement their services/events/scripts; that will be the big decision; the fact that all the Groovy services/events/scripts will mostly use a small DSL well suited to be integrated in Groovy to extend its language will actually make it easier for us to migrate out of Groovy:
> 1) convert the DSL class (100 lines of code?) into a generic helper class well suited for the new language (or discard it completely if the new language will come with the features we need ootb)
> 2) convert all the Groovy services/events/scripts to the new language
>
> The big effort will be #2 and not #1 and we are now discussing about #1.
>
> Jacopo
>
>>> If my interpretation of your vision is correct, I have also some doubts about #2: the risk is that we implement a big api to do everything we think a potential user of an unknown language would need; the risk is that we loose the advantages of each specific language.
>> Again, I think there is some confusion on what a "DSL for OFBiz" means. If it means we can add OFBiz-specific extensions to an existing language, then the API can be kept simple.
>>
>> -Adrian
>>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 9, 2012, at 12:59 PM, Adrian Crum wrote:
>>
>> What I don't see in your plan is what we want to do with the existing "applications" code and new code that will come: continue with Minilang, switch to Groovy, use a mix of languages?
>
> Anything we want. As long as we keep it generic, we are free to add/remove any scripting language. On the other hard, if we make it all Groovy-centric, then we have a lot of re-engineering to do if we decide to make a change.
I really don't see how using a Groovy specific DSL for OFBiz would make the system more Groovy-centric than using Groovy with a generic/general purpose helper class.
OFBiz (I mean the applications, not the framework) will become Groovy-centric if and when we will decide to use Groovy as the primary language to implement their services/events/scripts; that will be the big decision; the fact that all the Groovy services/events/scripts will mostly use a small DSL well suited to be integrated in Groovy to extend its language will actually make it easier for us to migrate out of Groovy:
1) convert the DSL class (100 lines of code?) into a generic helper class well suited for the new language (or discard it completely if the new language will come with the features we need ootb)
2) convert all the Groovy services/events/scripts to the new language
The big effort will be #2 and not #1 and we are now discussing about #1.
Jacopo
>
>> If my interpretation of your vision is correct, I have also some doubts about #2: the risk is that we implement a big api to do everything we think a potential user of an unknown language would need; the risk is that we loose the advantages of each specific language.
>
> Again, I think there is some confusion on what a "DSL for OFBiz" means. If it means we can add OFBiz-specific extensions to an existing language, then the API can be kept simple.
>
> -Adrian
>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 3/9/2012 11:48 AM, Jacopo Cappellato wrote:
> On Mar 9, 2012, at 12:28 PM, Adrian Crum wrote:
>
>> I'm not suggesting that we extend the DSL for any language. I'm suggesting the opposite - keep it generic so all languages can use it.
>>
>> I'm having a hard time understanding the push back on this. All I'm suggesting is that we make the DSL a Java interface/class instead of a Groovy script so the DSL can be reused in other scripting languages. Is there something fundamentally wrong with that idea that I'm not understanding?
> Adrian, no there is nothing wrong but I think we are not understanding each other's vision and goal.
> I see the work I am doing like a small "plugin" to add to Groovy a few things to make it a perfect language for OFBiz applications (like Minilang). This is similar to the concept of creating some custom freemarker transforms to simplify the creation of pages.
> So to me the logical step is:
> 1) select the language that is closest to what we need (or create one, like Minilang)
> 2) add to it what is missing (this is my small DSL)
> 3) then use it
> The effort I am doing is to see if Groovy + a small DSL can be a valid choice for the future of OFBiz. When this effort is done, if you (or anyone else) will see a potential to reuse the same DSL for other scripting languages, I would be more than happy to see it converted in a language independent way (this would be a trivial effort).
>
> What (I think) you are proposing is:
> 1) make OFBiz framework independent from any specific scripting language (apart from Java)
Exactly.
> 2) implement a DSL to write OFBiz applications in Java as a series of method calls to an helper class
No, provide a helper class that developers can use to implement a DSL.
> 3) the user will then chose the scripting language of his preference and then will use the DSL to write code
Yes, the developer can choose a scripting language. Whether or not the
scripting language has been extended to a DSL by incorporating the
helper class is a separate issue.
>
> What I don't see in your plan is what we want to do with the existing "applications" code and new code that will come: continue with Minilang, switch to Groovy, use a mix of languages?
Anything we want. As long as we keep it generic, we are free to
add/remove any scripting language. On the other hard, if we make it all
Groovy-centric, then we have a lot of re-engineering to do if we decide
to make a change.
> If my interpretation of your vision is correct, I have also some doubts about #2: the risk is that we implement a big api to do everything we think a potential user of an unknown language would need; the risk is that we loose the advantages of each specific language.
Again, I think there is some confusion on what a "DSL for OFBiz" means.
If it means we can add OFBiz-specific extensions to an existing
language, then the API can be kept simple.
-Adrian
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 9, 2012, at 12:28 PM, Adrian Crum wrote:
> I'm not suggesting that we extend the DSL for any language. I'm suggesting the opposite - keep it generic so all languages can use it.
>
> I'm having a hard time understanding the push back on this. All I'm suggesting is that we make the DSL a Java interface/class instead of a Groovy script so the DSL can be reused in other scripting languages. Is there something fundamentally wrong with that idea that I'm not understanding?
Adrian, no there is nothing wrong but I think we are not understanding each other's vision and goal.
I see the work I am doing like a small "plugin" to add to Groovy a few things to make it a perfect language for OFBiz applications (like Minilang). This is similar to the concept of creating some custom freemarker transforms to simplify the creation of pages.
So to me the logical step is:
1) select the language that is closest to what we need (or create one, like Minilang)
2) add to it what is missing (this is my small DSL)
3) then use it
The effort I am doing is to see if Groovy + a small DSL can be a valid choice for the future of OFBiz. When this effort is done, if you (or anyone else) will see a potential to reuse the same DSL for other scripting languages, I would be more than happy to see it converted in a language independent way (this would be a trivial effort).
What (I think) you are proposing is:
1) make OFBiz framework independent from any specific scripting language (apart from Java)
2) implement a DSL to write OFBiz applications in Java as a series of method calls to an helper class
3) the user will then chose the scripting language of his preference and then will use the DSL to write code
What I don't see in your plan is what we want to do with the existing "applications" code and new code that will come: continue with Minilang, switch to Groovy, use a mix of languages?
If my interpretation of your vision is correct, I have also some doubts about #2: the risk is that we implement a big api to do everything we think a potential user of an unknown language would need; the risk is that we loose the advantages of each specific language.
Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 9, 2012, at 12:28 PM, Adrian Crum wrote:
>> Your method would be used instead.
>
> Exactly. You don't see a problem with that?
>
Frankly speaking I don't; I mean, it would be a problem and when we will code services etc. we will have to follow a few rules.
But I could use the same exact argument against the proposal of passing to the context a "script" object with a reference to the helper method: I could assign to it a value; and the same applies to any object passed in the context of minilang.
But again, I think that this would be an acceptable compromise and I don't see a relevant problem.
Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 10/03/2012, at 12:28 AM, Adrian Crum wrote:
> On 3/9/2012 10:55 AM, Jacopo Cappellato wrote:
>> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
>>
>>> I noticed how you set up the GroovyBaseScript class - so that the methods are accessible as if they were a part of the script. That approach might cause problems with name clash. I might write a method in my script that is the same as a DSL method, and then I get odd behavior I can't explain until I look through the DSL reference and discover a matching method name.
>> Your method would be used instead.
>
> Exactly. You don't see a problem with that?
For what it's worth the methods could be marked 'final' to avoid an accidental override.
Regards
Scott
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 3/9/2012 10:55 AM, Jacopo Cappellato wrote:
> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
>
>> I noticed how you set up the GroovyBaseScript class - so that the methods are accessible as if they were a part of the script. That approach might cause problems with name clash. I might write a method in my script that is the same as a DSL method, and then I get odd behavior I can't explain until I look through the DSL reference and discover a matching method name.
> Your method would be used instead.
Exactly. You don't see a problem with that?
>
>> The approach I suggested earlier would solve that problem by putting the DSL object in the script context (bindings). Instead of:
>>
>> party = makeValue("Party");
>>
>> use:
>>
>> party = script.makeValue("Party");
>>
>> Another advantage of this approach is the syntax remains the same across languages. In JavaScript:
>>
>> var party = script.makeValue("Party");
>>
>> in Jython:
>>
>> party = script.makeValue("Party");
>>
>> etc...
>>
>> If Groovy users REALLY REALLY want to make the DSL methods accessible as if they were a part of the script, then we can have GroovyBaseScript implement the DSL interface and delegate to the script object:
>>
>> Map makeValue(String entityName) throws ExecutionServiceException {
>> return binding.getVariable('script').makeValue(entityName);
>> }
> We can discuss how to extend the DSL to all the languages out there
I'm not suggesting that we extend the DSL for any language. I'm
suggesting the opposite - keep it generic so all languages can use it.
I'm having a hard time understanding the push back on this. All I'm
suggesting is that we make the DSL a Java interface/class instead of a
Groovy script so the DSL can be reused in other scripting languages. Is
there something fundamentally wrong with that idea that I'm not
understanding?
> ; for now I would still like to concentrate on this implementation that makes use of Groovy; when the effort will be (mostly) finalized we will have a good implementation of a DSL for OFBiz and it will be easy to extend it to be usable by all scripts. But at the moment I would like to avoid to loose any of the Groovy abilities just because I want to support all languages: at the moment it is not a big decision because the specific framework code for Groovy will be limited to a few lines; the big decision will be to choose the preferred set of languages for the future of OFBiz... that will be the real dependency/decision (even if we will invoke them in a language independent way); currently we have: * Minilang and Java for services
> * Groovy (and widgets) for data preparation scripts
> In the future we may want to use Groovy also for the service part (I don't know); at that point OFBiz will have a huge dependency on Groovy code (this is already true for the data preparation) and maintaining one small Groovy dependent class in the framework to make the services/data scripts more elegant would not worry me at all (when the next language will be chosen we will of course have to convert this small class and then the huge amount of services and data scripts).
>
> Jacopo
>
>> -Adrian
>>
>>
>> On 3/8/2012 9:56 PM, Jacopo Cappellato wrote:
>>> On Mar 8, 2012, at 8:30 PM, Adrian Crum wrote:
>>>
>>>> I like the general concept, but I think it can be made generic so it is reusable in other languages. That is what I was trying to describe earlier.
>>>>
>>>> I looked at GroovyBaseScript and I don't see any reason why it needs to be made Groovy-specific. Have the class access bindings from JSR-223 and Tah-dah! It works for all scripting languages.
>>> Thank you Adrian.
>>> In this first step I was actually focused on the definition (and their design as DSL) of all the implicit rules that make Minilang such a productive tool, and I have used Groovy because it helps to implement this kind of patterns.
>>> But if we can enhance and reuse the same class for all the JSR-223 compliant scripting languages that would be nice.
>>>
>>> Jacopo
>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>> Hi all,
>>>>>
>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>
>>>>> Please review my notes here:
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>
>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jacopo
>>>>>
>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 3/9/2012 1:21 PM, Jacopo Cappellato wrote:
> On Mar 9, 2012, at 12:36 PM, Adrian Crum wrote:
>
>> On 3/9/2012 11:30 AM, Jacopo Cappellato wrote:
>>>> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
>>>>> Another advantage of this approach is the syntax remains the same across languages.
>>> I also have some doubts that a language independent DSL would be very useful: the main concept is to extend the language of your preference in a tr
>>>
>>> For example, in order to copy contents of maps from map to map in Groovy you can do something like:
>>>
>>> lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
>> Now I understand the confusion - there is nothing "DSL" about copying a Map. In my mind the "Domain" in an OFBiz DSL is "OFBiz" - so the DSL adds OFBiz-specific extensions to the language.
>>
>> What you're describing would be handled by third-party libraries.
> I am simply saying that, if the goal is to be ready to switch from Groovy to the next language that will come, and we have code like this:
>
> lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
> record = findOne('InventoryItem', lookupFieldMap)
>
> then the difficult part will be to convert the first line, not the second.
> I don't see how the following code:
>
> lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
> record = script.findOne('InventoryItem', lookupFieldMap)
>
> would make it easier.
If we're talking about Groovy specifically, then you are correct. The
difference is, in JavaScript it would not be possible to do this:
var record = script.findOne('InventoryItem', lookupFieldMap);
-Adrian
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 9, 2012, at 12:36 PM, Adrian Crum wrote:
>
> On 3/9/2012 11:30 AM, Jacopo Cappellato wrote:
>>> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
>>>> Another advantage of this approach is the syntax remains the same across languages.
>> I also have some doubts that a language independent DSL would be very useful: the main concept is to extend the language of your preference in a tr
>>
>> For example, in order to copy contents of maps from map to map in Groovy you can do something like:
>>
>> lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
>
> Now I understand the confusion - there is nothing "DSL" about copying a Map. In my mind the "Domain" in an OFBiz DSL is "OFBiz" - so the DSL adds OFBiz-specific extensions to the language.
>
> What you're describing would be handled by third-party libraries.
I am simply saying that, if the goal is to be ready to switch from Groovy to the next language that will come, and we have code like this:
lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
record = findOne('InventoryItem', lookupFieldMap)
then the difficult part will be to convert the first line, not the second.
I don't see how the following code:
lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
record = script.findOne('InventoryItem', lookupFieldMap)
would make it easier.
Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 3/9/2012 11:30 AM, Jacopo Cappellato wrote:
>> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
>>> Another advantage of this approach is the syntax remains the same across languages.
> I also have some doubts that a language independent DSL would be very useful: the main concept is to extend the language of your preference in a tr
>
> For example, in order to copy contents of maps from map to map in Groovy you can do something like:
>
> lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
Now I understand the confusion - there is nothing "DSL" about copying a
Map. In my mind the "Domain" in an OFBiz DSL is "OFBiz" - so the DSL
adds OFBiz-specific extensions to the language.
What you're describing would be handled by third-party libraries.
-Adrian
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
>> Another advantage of this approach is the syntax remains the same across languages.
I also have some doubts that a language independent DSL would be very useful: the main concept is to extend the language of your preference in a tr
For example, in order to copy contents of maps from map to map in Groovy you can do something like:
lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId'])
so for Groovy a utility method to transfer items from map to map would not be needed; but in another (less powerful) language it may be useful to have. Since we do not know what language the user will choose, it would be difficult to predict the useful methods in our DSL... and we may end up implementing a new language that is "language independent"; I want to avoid this and simply add the minimal amount of code to complete a specific language very powerful for what we need in OFBiz applications.
A (super lightweight) DSL, specific to the language chosen by the community for the OFBiz applications, is the best choice in my opinion.
Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote:
> I noticed how you set up the GroovyBaseScript class - so that the methods are accessible as if they were a part of the script. That approach might cause problems with name clash. I might write a method in my script that is the same as a DSL method, and then I get odd behavior I can't explain until I look through the DSL reference and discover a matching method name.
Your method would be used instead.
>
> The approach I suggested earlier would solve that problem by putting the DSL object in the script context (bindings). Instead of:
>
> party = makeValue("Party");
>
> use:
>
> party = script.makeValue("Party");
>
> Another advantage of this approach is the syntax remains the same across languages. In JavaScript:
>
> var party = script.makeValue("Party");
>
> in Jython:
>
> party = script.makeValue("Party");
>
> etc...
>
> If Groovy users REALLY REALLY want to make the DSL methods accessible as if they were a part of the script, then we can have GroovyBaseScript implement the DSL interface and delegate to the script object:
>
> Map makeValue(String entityName) throws ExecutionServiceException {
> return binding.getVariable('script').makeValue(entityName);
> }
We can discuss how to extend the DSL to all the languages out there; for now I would still like to concentrate on this implementation that makes use of Groovy; when the effort will be (mostly) finalized we will have a good implementation of a DSL for OFBiz and it will be easy to extend it to be usable by all scripts. But at the moment I would like to avoid to loose any of the Groovy abilities just because I want to support all languages: at the moment it is not a big decision because the specific framework code for Groovy will be limited to a few lines; the big decision will be to choose the preferred set of languages for the future of OFBiz... that will be the real dependency/decision (even if we will invoke them in a language independent way); currently we have:
* Minilang and Java for services
* Groovy (and widgets) for data preparation scripts
In the future we may want to use Groovy also for the service part (I don't know); at that point OFBiz will have a huge dependency on Groovy code (this is already true for the data preparation) and maintaining one small Groovy dependent class in the framework to make the services/data scripts more elegant would not worry me at all (when the next language will be chosen we will of course have to convert this small class and then the huge amount of services and data scripts).
Jacopo
>
> -Adrian
>
>
> On 3/8/2012 9:56 PM, Jacopo Cappellato wrote:
>> On Mar 8, 2012, at 8:30 PM, Adrian Crum wrote:
>>
>>> I like the general concept, but I think it can be made generic so it is reusable in other languages. That is what I was trying to describe earlier.
>>>
>>> I looked at GroovyBaseScript and I don't see any reason why it needs to be made Groovy-specific. Have the class access bindings from JSR-223 and Tah-dah! It works for all scripting languages.
>> Thank you Adrian.
>> In this first step I was actually focused on the definition (and their design as DSL) of all the implicit rules that make Minilang such a productive tool, and I have used Groovy because it helps to implement this kind of patterns.
>> But if we can enhance and reuse the same class for all the JSR-223 compliant scripting languages that would be nice.
>>
>> Jacopo
>>
>>> -Adrian
>>>
>>>
>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>> Hi all,
>>>>
>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>
>>>> Please review my notes here:
>>>>
>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>
>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>
>>>> Regards,
>>>>
>>>> Jacopo
>>>>
>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
I noticed how you set up the GroovyBaseScript class - so that the
methods are accessible as if they were a part of the script. That
approach might cause problems with name clash. I might write a method in
my script that is the same as a DSL method, and then I get odd behavior
I can't explain until I look through the DSL reference and discover a
matching method name.
The approach I suggested earlier would solve that problem by putting the
DSL object in the script context (bindings). Instead of:
party = makeValue("Party");
use:
party = script.makeValue("Party");
Another advantage of this approach is the syntax remains the same across
languages. In JavaScript:
var party = script.makeValue("Party");
in Jython:
party = script.makeValue("Party");
etc...
If Groovy users REALLY REALLY want to make the DSL methods accessible as
if they were a part of the script, then we can have GroovyBaseScript
implement the DSL interface and delegate to the script object:
Map makeValue(String entityName) throws ExecutionServiceException {
return binding.getVariable('script').makeValue(entityName);
}
-Adrian
On 3/8/2012 9:56 PM, Jacopo Cappellato wrote:
> On Mar 8, 2012, at 8:30 PM, Adrian Crum wrote:
>
>> I like the general concept, but I think it can be made generic so it is reusable in other languages. That is what I was trying to describe earlier.
>>
>> I looked at GroovyBaseScript and I don't see any reason why it needs to be made Groovy-specific. Have the class access bindings from JSR-223 and Tah-dah! It works for all scripting languages.
> Thank you Adrian.
> In this first step I was actually focused on the definition (and their design as DSL) of all the implicit rules that make Minilang such a productive tool, and I have used Groovy because it helps to implement this kind of patterns.
> But if we can enhance and reuse the same class for all the JSR-223 compliant scripting languages that would be nice.
>
> Jacopo
>
>> -Adrian
>>
>>
>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>> Hi all,
>>>
>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>
>>> Please review my notes here:
>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>
>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 8, 2012, at 8:30 PM, Adrian Crum wrote:
> I like the general concept, but I think it can be made generic so it is reusable in other languages. That is what I was trying to describe earlier.
>
> I looked at GroovyBaseScript and I don't see any reason why it needs to be made Groovy-specific. Have the class access bindings from JSR-223 and Tah-dah! It works for all scripting languages.
Thank you Adrian.
In this first step I was actually focused on the definition (and their design as DSL) of all the implicit rules that make Minilang such a productive tool, and I have used Groovy because it helps to implement this kind of patterns.
But if we can enhance and reuse the same class for all the JSR-223 compliant scripting languages that would be nice.
Jacopo
>
> -Adrian
>
>
> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>> Hi all,
>>
>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>
>> Please review my notes here:
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>
>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>
>> Regards,
>>
>> Jacopo
>>
>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
I like the general concept, but I think it can be made generic so it is
reusable in other languages. That is what I was trying to describe earlier.
I looked at GroovyBaseScript and I don't see any reason why it needs to
be made Groovy-specific. Have the class access bindings from JSR-223 and
Tah-dah! It works for all scripting languages.
-Adrian
On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
> Hi all,
>
> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>
> Please review my notes here:
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>
> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>
> Regards,
>
> Jacopo
>
> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Yes, but I really think that, if we define what is part of the "core OFBiz framework" we could even go with merging the "core code" into one component.
That would be even easier... but this is food for another day, I can survive even if makeValue returns a Map for now.
Jacopo
On Mar 13, 2012, at 12:14 PM, Adrian Crum wrote:
> Yes, the arch-nemesis of innovation - component cross-dependency.
>
> That's why the script helper needs a factory.
>
> I was thinking we can insert a script component in between the service and common component dependency. Move all of the script classes there - *Util.java, event handlers, services engines, etc. It would make life a lot easier.
>
> -Adrian
>
> On 3/13/2012 11:08 AM, Jacopo Cappellato wrote:
>> Is there a reason for not returning a GenericValue from:
>>
>> Map<String, Object> makeValue(String entityName)
>>
>> ?
>>
>> Well, the good reason is probably the dependency issue between framework components... in my opinion it would be a good time to start thinking to drop it and consider the "core framework components" all together: base+service+entity
>>
>> Jacopo
>>
>>
>> On Mar 13, 2012, at 11:51 AM, Jacopo Cappellato wrote:
>>
>>> I think that this is because of the way it is initialized:
>>>
>>> ScriptContext scriptContext = new SimpleScriptContext();
>>> ScriptHelper helper = createScriptHelper(scriptContext);
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>>>
>>>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>>>
>>>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>>>> Hey Adrian,
>>>>>>
>>>>>> a quick question before I dig into the details.
>>>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> Jacopo,
>>>>>>>>>
>>>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>>>
>>>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>>>
>>>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>>>
>>>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>>>
>>>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>>>
>>>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>>>
>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> private final ScriptHelper helper;
>>>>>>>>>
>>>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>>>> return helper.makeValue(entityName);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>>>> Adrian, thank you for your work.
>>>>>>>>>>
>>>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>>>
>>>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>>>
>>>>>>>>>> Kind regards and again thank you,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>>>
>>>>>>>>>>> Jacopo,
>>>>>>>>>>>
>>>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>>>
>>>>>>>>>>> -Adrian
>>>>>>>>>>>
>>>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>>>
>>>>>>>>>>>> Please review my notes here:
>>>>>>>>>>>>
>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>>>
>>>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
Yes, the arch-nemesis of innovation - component cross-dependency.
That's why the script helper needs a factory.
I was thinking we can insert a script component in between the service
and common component dependency. Move all of the script classes there -
*Util.java, event handlers, services engines, etc. It would make life a
lot easier.
-Adrian
On 3/13/2012 11:08 AM, Jacopo Cappellato wrote:
> Is there a reason for not returning a GenericValue from:
>
> Map<String, Object> makeValue(String entityName)
>
> ?
>
> Well, the good reason is probably the dependency issue between framework components... in my opinion it would be a good time to start thinking to drop it and consider the "core framework components" all together: base+service+entity
>
> Jacopo
>
>
> On Mar 13, 2012, at 11:51 AM, Jacopo Cappellato wrote:
>
>> I think that this is because of the way it is initialized:
>>
>> ScriptContext scriptContext = new SimpleScriptContext();
>> ScriptHelper helper = createScriptHelper(scriptContext);
>>
>> Jacopo
>>
>> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>>
>>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>>
>>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>>> Hey Adrian,
>>>>>
>>>>> a quick question before I dig into the details.
>>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>>
>>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Jacopo,
>>>>>>>>
>>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>>
>>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>>
>>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>>
>>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>>
>>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>>
>>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>>
>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>>> ...
>>>>>>>>
>>>>>>>> private final ScriptHelper helper;
>>>>>>>>
>>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>>> return helper.makeValue(entityName);
>>>>>>>> }
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>>> Adrian, thank you for your work.
>>>>>>>>>
>>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>>
>>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>>
>>>>>>>>> Kind regards and again thank you,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>>
>>>>>>>>>> Jacopo,
>>>>>>>>>>
>>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>>
>>>>>>>>>>> Please review my notes here:
>>>>>>>>>>>
>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>>
>>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Is there a reason for not returning a GenericValue from:
Map<String, Object> makeValue(String entityName)
?
Well, the good reason is probably the dependency issue between framework components... in my opinion it would be a good time to start thinking to drop it and consider the "core framework components" all together: base+service+entity
Jacopo
On Mar 13, 2012, at 11:51 AM, Jacopo Cappellato wrote:
> I think that this is because of the way it is initialized:
>
> ScriptContext scriptContext = new SimpleScriptContext();
> ScriptHelper helper = createScriptHelper(scriptContext);
>
> Jacopo
>
> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>
>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>
>> Jacopo
>>
>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>
>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>
>>> -Adrian
>>>
>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>> Hey Adrian,
>>>>
>>>> a quick question before I dig into the details.
>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>
>>>> Thanks,
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>
>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> Jacopo,
>>>>>>>
>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>
>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>
>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>
>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>
>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>
>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>
>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>> ...
>>>>>>>
>>>>>>> private final ScriptHelper helper;
>>>>>>>
>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>> }
>>>>>>>
>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>> return helper.makeValue(entityName);
>>>>>>> }
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>> Adrian, thank you for your work.
>>>>>>>>
>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>
>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>
>>>>>>>> Kind regards and again thank you,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> Jacopo,
>>>>>>>>>
>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>
>>>>>>>>>> Please review my notes here:
>>>>>>>>>>
>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>
>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
>>
>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
oops... please ignore my last one (doesn't make much sense)
Jacopo
On Mar 13, 2012, at 4:34 PM, Jacopo Cappellato wrote:
> Adrian,
>
> are you sure it is ok to create a ScriptHelper in this way:
>
> public static ScriptHelper createScriptHelper(ScriptContext context) {
> if (helperFactory != null) {
> return helperFactory.getInstance(context);
> }
> return null;
> }
>
> ?
>
> I think you need a new one for every new context... but maybe I am missing your intentions.
>
> Jacopo
>
> On Mar 13, 2012, at 11:51 AM, Jacopo Cappellato wrote:
>
>> I think that this is because of the way it is initialized:
>>
>> ScriptContext scriptContext = new SimpleScriptContext();
>> ScriptHelper helper = createScriptHelper(scriptContext);
>>
>> Jacopo
>>
>> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>>
>>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>>
>>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>>> Hey Adrian,
>>>>>
>>>>> a quick question before I dig into the details.
>>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>>
>>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Jacopo,
>>>>>>>>
>>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>>
>>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>>
>>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>>
>>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>>
>>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>>
>>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>>
>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>>> ...
>>>>>>>>
>>>>>>>> private final ScriptHelper helper;
>>>>>>>>
>>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>>> return helper.makeValue(entityName);
>>>>>>>> }
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>>> Adrian, thank you for your work.
>>>>>>>>>
>>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>>
>>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>>
>>>>>>>>> Kind regards and again thank you,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>>
>>>>>>>>>> Jacopo,
>>>>>>>>>>
>>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>>
>>>>>>>>>>> Please review my notes here:
>>>>>>>>>>>
>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>>
>>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
>>>
>>
>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Adrian,
are you sure it is ok to create a ScriptHelper in this way:
public static ScriptHelper createScriptHelper(ScriptContext context) {
if (helperFactory != null) {
return helperFactory.getInstance(context);
}
return null;
}
?
I think you need a new one for every new context... but maybe I am missing your intentions.
Jacopo
On Mar 13, 2012, at 11:51 AM, Jacopo Cappellato wrote:
> I think that this is because of the way it is initialized:
>
> ScriptContext scriptContext = new SimpleScriptContext();
> ScriptHelper helper = createScriptHelper(scriptContext);
>
> Jacopo
>
> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>
>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>
>> Jacopo
>>
>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>
>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>
>>> -Adrian
>>>
>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>> Hey Adrian,
>>>>
>>>> a quick question before I dig into the details.
>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>
>>>> Thanks,
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>
>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> Jacopo,
>>>>>>>
>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>
>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>
>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>
>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>
>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>
>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>
>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>> ...
>>>>>>>
>>>>>>> private final ScriptHelper helper;
>>>>>>>
>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>> }
>>>>>>>
>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>> return helper.makeValue(entityName);
>>>>>>> }
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>> Adrian, thank you for your work.
>>>>>>>>
>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>
>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>
>>>>>>>> Kind regards and again thank you,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> Jacopo,
>>>>>>>>>
>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>
>>>>>>>>>> Please review my notes here:
>>>>>>>>>>
>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>
>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
>>
>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
I think that this is because of the way it is initialized:
ScriptContext scriptContext = new SimpleScriptContext();
ScriptHelper helper = createScriptHelper(scriptContext);
Jacopo
On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>
> Jacopo
>
> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>
>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>
>> -Adrian
>>
>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>> Hey Adrian,
>>>
>>> a quick question before I dig into the details.
>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>
>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>
>>>>>> Jacopo,
>>>>>>
>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>
>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>
>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>
>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>
>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>
>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>
>>>>
>>>>> Jacopo
>>>>>
>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>> ...
>>>>>>
>>>>>> private final ScriptHelper helper;
>>>>>>
>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>> return helper.runService(serviceName, inputMap);
>>>>>> }
>>>>>>
>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>> return helper.makeValue(entityName);
>>>>>> }
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> }
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>> Adrian, thank you for your work.
>>>>>>>
>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>
>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>
>>>>>>> Kind regards and again thank you,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>
>>>>>>>
>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Jacopo,
>>>>>>>>
>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>
>>>>>>>>> Please review my notes here:
>>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>
>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Apache Jelly is probably the project you're looking to create :-)
http://commons.apache.org/jelly/
Regards
Scott
On 14/03/2012, at 9:49 PM, Jacopo Cappellato wrote:
> This is nice.
> It would be also nice to move Minilang framework code out of the OFBiz framework to become a separate project for the language itself (and "OFBiz applications" could use it as they use Groovy); but I know this will be impossible because of the dependencies on OFBiz services/delegator.
>
> Jacopo
>
> On Mar 14, 2012, at 9:34 AM, Adrian Crum wrote:
>
>> Speaking of consolidation, once I have the mini-language grammar finalized, I will have mini-language implement JSR-223 so that it can be run in the same generic way. Then we will be able to remove a some of the mini-language specific classes (service/event engines).
>>
>> -Adrian
>>
>> On 3/14/2012 8:29 AM, Jacopo Cappellato wrote:
>>> On Mar 14, 2012, at 9:23 AM, Adrian Crum wrote:
>>>
>>>> On 3/14/2012 7:56 AM, Jacopo Cappellato wrote:
>>>>> * after the switch to JSR-223 the "DSL method" are accessed thru the "ofbiz" reference (instead of being directly available as method calls)
>>>> You could implement your own script engine factory to enable the extended Script class + DSL idea (GroovyBaseScript).
>>> Yes, this is what I meant... however I think it is fine to keep the "ofbiz." syntax for now and see how it goes (the switch in the future would be a matter of a few search-and-replace operations).
>>> Actually a more compelling reason for using a custom engine would be to enable debugging... but even if we decide to do this I would prefer to continue to use the "ofbiz." syntax (i.e. do not inject the GroovyBaseScript)... in this way the decision engine switch will not affect in any way the code in the scripts. When everything will be consolidated it will be easier to see what the is the best way to go.
>>>
>>> Jacopo
>>>
>>>> -Adrian
>>>>
>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Anne <an...@cohsoft.com.au>.
On 15 March 2012 16:37, Jacopo Cappellato <jacopo.cappellato@hotwaxmedia.com
> wrote:
> On Mar 15, 2012, at 1:40 AM, Anne wrote:
>
> > I go away for a few days, and you drop the DSL idea and replace it with
> an
> > old-fashioned language-agnostic helper class.
>
> :-)
>
> Anne, I must admit that I had the same reaction at the beginning, but in a
> community you have to blend your plans/ideas with the ones from others if
> they have strong opinions on them.
Yes, Jacopo, I agree. Way I see it, if the community decides to do
something I don't want (which isn't the case here!) I have two choices. I
can silently live with it, or silently leave.
I am happy with the helper class, just not as happy as I was when I thought
a DSL was being developed. The helper class is a big improvement over the
current system, and I am pleased it exists.
I also accepted to see my work being re-routed when I realized we could
> still implement Groovy services and events in a very nice way: if you
> review the "new" version of my services/events, apart from the ugly
> "ofbiz." prefix, all the important things are exactly the same.
>
That is good to hear, though it is the possible directions the DSL could
have gone in the future that I was looking forward to, rather than what had
already been achieved.
> I have the following short term plans:
> * we will expand the DSL (i.e. the helper class) a little bit in order to
> provide a couple more frequently used operations
> * I will keep a close eye at the way the "helper" class evolves in order
> to avoid the risk of seeing it become another ugly complex api
> * at some point we may decide to wrap it into a Groovy friendly class to
> enable full DSL
> * we have also some plans to implement a Groovy builder for complex
> dynamic view entities or entity queries: this would complete the DSL for
> Groovy (if possible we will implement it in a Java friendly way, but if not
> it will be a Groovy only thing)
>
+1 to all of this.
Cheers,
Anne.
--
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: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 15, 2012, at 1:40 AM, Anne wrote:
> I go away for a few days, and you drop the DSL idea and replace it with an
> old-fashioned language-agnostic helper class.
:-)
Anne, I must admit that I had the same reaction at the beginning, but in a community you have to blend your plans/ideas with the ones from others if they have strong opinions on them. I also accepted to see my work being re-routed when I realized we could still implement Groovy services and events in a very nice way: if you review the "new" version of my services/events, apart from the ugly "ofbiz." prefix, all the important things are exactly the same.
So for now we can use this work assuming we have at disposal a nice language: Groovy powered by an OFBiz DSL
I have the following short term plans:
* we will expand the DSL (i.e. the helper class) a little bit in order to provide a couple more frequently used operations
* I will keep a close eye at the way the "helper" class evolves in order to avoid the risk of seeing it become another ugly complex api
* at some point we may decide to wrap it into a Groovy friendly class to enable full DSL
* we have also some plans to implement a Groovy builder for complex dynamic view entities or entity queries: this would complete the DSL for Groovy (if possible we will implement it in a Java friendly way, but if not it will be a Groovy only thing)
Then the "OFBiz applications" will have a great language to migrate to (if the community will see the benefit of migrating the existing "application" code from Java and Minilang to the new Groovy) or simply to use it for new development.
Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Anne <an...@cohsoft.com.au>.
I go away for a few days, and you drop the DSL idea and replace it with an
old-fashioned language-agnostic helper class. I don't have a problem with
that. It gives up the ability to develop a nice DSL which would necessarily
be groovy based, but replaces it with the advantage of being able to use
almost any scripting language (but without direct DSL support).
Maybe once the helper class is mature, there won't be much point creating a
DSL. If there is still a point, a DSL probably would be easier to create
using the helper class.
Unfortunately I don't have time to help much with this effort at the
moment, although I would really like to. I'll try to at least grab the
changes soon and play with them, so I can give feedback.
I do think it critical that the debugger works. The editing aids my editor
gives me for groovy must also work. These are the two biggest issues with
minilang, and why I no longer use minilang except for the simplest services.
+1 to Jacopo's suggestion to concentrate on implementing what is actually
used, and not what one thinks might be useful.
Good work, everyone (especially Jacopo and Adrian).
Cheers,
Anne.
--
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: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
Actually, it is impossible because a lot of framework code depends on
mini-language.
-Adrian
On 3/14/2012 8:49 AM, Jacopo Cappellato wrote:
> This is nice.
> It would be also nice to move Minilang framework code out of the OFBiz framework to become a separate project for the language itself (and "OFBiz applications" could use it as they use Groovy); but I know this will be impossible because of the dependencies on OFBiz services/delegator.
>
> Jacopo
>
> On Mar 14, 2012, at 9:34 AM, Adrian Crum wrote:
>
>> Speaking of consolidation, once I have the mini-language grammar finalized, I will have mini-language implement JSR-223 so that it can be run in the same generic way. Then we will be able to remove a some of the mini-language specific classes (service/event engines).
>>
>> -Adrian
>>
>> On 3/14/2012 8:29 AM, Jacopo Cappellato wrote:
>>> On Mar 14, 2012, at 9:23 AM, Adrian Crum wrote:
>>>
>>>> On 3/14/2012 7:56 AM, Jacopo Cappellato wrote:
>>>>> * after the switch to JSR-223 the "DSL method" are accessed thru the "ofbiz" reference (instead of being directly available as method calls)
>>>> You could implement your own script engine factory to enable the extended Script class + DSL idea (GroovyBaseScript).
>>> Yes, this is what I meant... however I think it is fine to keep the "ofbiz." syntax for now and see how it goes (the switch in the future would be a matter of a few search-and-replace operations).
>>> Actually a more compelling reason for using a custom engine would be to enable debugging... but even if we decide to do this I would prefer to continue to use the "ofbiz." syntax (i.e. do not inject the GroovyBaseScript)... in this way the decision engine switch will not affect in any way the code in the scripts. When everything will be consolidated it will be easier to see what the is the best way to go.
>>>
>>> Jacopo
>>>
>>>> -Adrian
>>>>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
This is nice.
It would be also nice to move Minilang framework code out of the OFBiz framework to become a separate project for the language itself (and "OFBiz applications" could use it as they use Groovy); but I know this will be impossible because of the dependencies on OFBiz services/delegator.
Jacopo
On Mar 14, 2012, at 9:34 AM, Adrian Crum wrote:
> Speaking of consolidation, once I have the mini-language grammar finalized, I will have mini-language implement JSR-223 so that it can be run in the same generic way. Then we will be able to remove a some of the mini-language specific classes (service/event engines).
>
> -Adrian
>
> On 3/14/2012 8:29 AM, Jacopo Cappellato wrote:
>> On Mar 14, 2012, at 9:23 AM, Adrian Crum wrote:
>>
>>> On 3/14/2012 7:56 AM, Jacopo Cappellato wrote:
>>>> * after the switch to JSR-223 the "DSL method" are accessed thru the "ofbiz" reference (instead of being directly available as method calls)
>>> You could implement your own script engine factory to enable the extended Script class + DSL idea (GroovyBaseScript).
>> Yes, this is what I meant... however I think it is fine to keep the "ofbiz." syntax for now and see how it goes (the switch in the future would be a matter of a few search-and-replace operations).
>> Actually a more compelling reason for using a custom engine would be to enable debugging... but even if we decide to do this I would prefer to continue to use the "ofbiz." syntax (i.e. do not inject the GroovyBaseScript)... in this way the decision engine switch will not affect in any way the code in the scripts. When everything will be consolidated it will be easier to see what the is the best way to go.
>>
>> Jacopo
>>
>>> -Adrian
>>>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
Speaking of consolidation, once I have the mini-language grammar
finalized, I will have mini-language implement JSR-223 so that it can be
run in the same generic way. Then we will be able to remove a some of
the mini-language specific classes (service/event engines).
-Adrian
On 3/14/2012 8:29 AM, Jacopo Cappellato wrote:
> On Mar 14, 2012, at 9:23 AM, Adrian Crum wrote:
>
>> On 3/14/2012 7:56 AM, Jacopo Cappellato wrote:
>>> * after the switch to JSR-223 the "DSL method" are accessed thru the "ofbiz" reference (instead of being directly available as method calls)
>> You could implement your own script engine factory to enable the extended Script class + DSL idea (GroovyBaseScript).
> Yes, this is what I meant... however I think it is fine to keep the "ofbiz." syntax for now and see how it goes (the switch in the future would be a matter of a few search-and-replace operations).
> Actually a more compelling reason for using a custom engine would be to enable debugging... but even if we decide to do this I would prefer to continue to use the "ofbiz." syntax (i.e. do not inject the GroovyBaseScript)... in this way the decision engine switch will not affect in any way the code in the scripts. When everything will be consolidated it will be easier to see what the is the best way to go.
>
> Jacopo
>
>> -Adrian
>>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 14, 2012, at 9:23 AM, Adrian Crum wrote:
> On 3/14/2012 7:56 AM, Jacopo Cappellato wrote:
>> * after the switch to JSR-223 the "DSL method" are accessed thru the "ofbiz" reference (instead of being directly available as method calls)
>
> You could implement your own script engine factory to enable the extended Script class + DSL idea (GroovyBaseScript).
Yes, this is what I meant... however I think it is fine to keep the "ofbiz." syntax for now and see how it goes (the switch in the future would be a matter of a few search-and-replace operations).
Actually a more compelling reason for using a custom engine would be to enable debugging... but even if we decide to do this I would prefer to continue to use the "ofbiz." syntax (i.e. do not inject the GroovyBaseScript)... in this way the decision engine switch will not affect in any way the code in the scripts. When everything will be consolidated it will be easier to see what the is the best way to go.
Jacopo
>
> -Adrian
>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 3/14/2012 7:56 AM, Jacopo Cappellato wrote:
> * after the switch to JSR-223 the "DSL method" are accessed thru the "ofbiz" reference (instead of being directly available as method calls)
You could implement your own script engine factory to enable the
extended Script class + DSL idea (GroovyBaseScript).
-Adrian
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
That's great news Jacopo! Thank you very much for working on this.
This effort will accomplish much more than just implement an OFBiz DSL -
it also opens up other interesting possibilities. For example, a user
could drop a JSR-223 PHP script engine in OFBiz and with a little
tweaking here and there, be able to use products like Drupal and Joomla
as an OFBiz front end. Also, server-side JavaScript is gaining in
popularity - which makes sense. Why have two teams of developers - one
for client-side JavaScript, and another for server-side scripting? You
can use the same tools and skill sets on both sides of the connection.
-Adrian
On 3/14/2012 7:56 AM, Jacopo Cappellato wrote:
> Adrian, all,
>
> I am summarizing here the results of my initial tests of the Groovy service and event executed by Adrian's Script* classes (using JSR-223).
>
> First of all, here are the service and events updated to work with the new code (they run with the latest enhancements I committed to framework code):
>
> =====================================================================
> import org.ofbiz.base.util.UtilDateTime
> import org.ofbiz.entity.util.EntityUtil
>
> // THIS IS A SERVICE
> def setLastInventoryCount() {
> inventoryItem = ofbiz.findOne('InventoryItem')
> if (!inventoryItem) {
> ofbiz.logWarning("The InventoryItem with inventoryItemId=${parameters.inventoryItemId} doesn't exist.")
> return ofbiz.failure("Inventory item with id ${parameters.inventoryItemId} was not found.")
> }
> List productFacilities = ofbiz.findList('ProductFacility', [productId:inventoryItem.productId, facilityId:inventoryItem.facilityId])
> productFacilities.each {
> countResult = ofbiz.runService('getInventoryAvailableByFacility', [productId:it.productId, facilityId: it.facilityId])
> result = ofbiz.runService('updateProductFacility', [productId:it.productId, facilityId:it.facilityId, lastInventoryCount:countResult.availableToPromiseTotal])
> }
> return ofbiz.success("Updated inventory count for product ${inventoryItem.productId}.")
> }
>
> // THIS IS AN EVENT
> def updateProductCategoryMember() {
> thruDate = parameters.thruDate
> if (!thruDate) {
> thruDate = UtilDateTime.nowTimestamp()
> }
> try {
> productCategoryMember = EntityUtil.getFirst(EntityUtil.filterByDate(ofbiz.findList('ProductCategoryMember', [productCategoryId: parameters.productCategoryId, productId: parameters.productId])))
> if (productCategoryMember) {
> productCategoryMember.setString('thruDate', thruDate)
> productCategoryMember.store()
> }
> } catch(Exception e) {
> return ofbiz.error("The following error occurred setting thruDate on category ${parameters.productCategoryId} for product ${parameters.productId}: ${e.getMessage()}")
> }
> return ofbiz.success("Set thruDate ${thruDate} on category ${parameters.productCategoryId} for product ${parameters.productId}")
> }
> =====================================================================
>
> And here are some comments, each with a face to highlight the result:
> :-) good
> :-/ so and so
> :-( bad
>
> * the code above is the whole content of the file I have created: as you can see is still very clear: no need to declare classes, define accessors; you simply have to write the business logic
> ** :-)
> * after the switch to JSR-223 the "DSL method" are accessed thru the "ofbiz" reference (instead of being directly available as method calls)
> ** :-/ (because of the small added complexity) but also :-) because now the IDE is able to autocomplete the method calls to the "ofbiz" object (with a small tweak that I will explain); this is actually a nice to have feature
> * after the switch to JSR-223 the debugger of my IDE (Idea) is no more able to walk the Groovy services and events; it is working like a charm when using the Groovy specific service engine and event handler
> ** :-( this is really a bummer! is this only an issue with Idea? is it working with Eclipse? Need to research on this
>
> The summary is:
> * the new mechanism works fine and still allows to implement very nice services and events; this is really good
> * the debug issue is rather big one (the lack of debugging tools for Minilang was one of the most frequent complains) but this is an issue that can be researched/addressed and shouldn't block the evaluation/adoption of this "new" language for services/events; even if we will fail to find a solution we could easily run the Groovy services/events using the custom engine/handler and this will not require any code change to the services/events
>
> Next step:
> it would be really nice to continue this proof of concepts by converting some interesting Java services/events and Minilang services/events to Groovy: this will help to complete the ScriptHelper classes and greatly help to appreciate pros and cons.
> Is there any interest in this effort? I see a big potential in this approach, but the opinion from the community will be important.
>
> Kind regards,
>
> Jacopo
>
>
>
> On Mar 13, 2012, at 4:59 PM, Adrian Crum wrote:
>
>> Cool - thanks! My apologies - I had not given much thought to the object construction sequence in that section of code.
>>
>> I'm pretty sure I followed good concurrency practices overall, but there is always a chance I missed something.
>>
>> -Adrian
>>
>> On 3/13/2012 3:49 PM, Jacopo Cappellato wrote:
>>> This is now fixed in rev. 1300202
>>> By the way: we will need to carefully review the way ScriptHelper/ContextHelper are built (and especially how the context is passed) in order to make sure the code is thread safe.
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>>>
>>>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>>>
>>>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>>>> Hey Adrian,
>>>>>>
>>>>>> a quick question before I dig into the details.
>>>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> Jacopo,
>>>>>>>>>
>>>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>>>
>>>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>>>
>>>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>>>
>>>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>>>
>>>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>>>
>>>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>>>
>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> private final ScriptHelper helper;
>>>>>>>>>
>>>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>>>> return helper.makeValue(entityName);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>>>> Adrian, thank you for your work.
>>>>>>>>>>
>>>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>>>
>>>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>>>
>>>>>>>>>> Kind regards and again thank you,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>>>
>>>>>>>>>>> Jacopo,
>>>>>>>>>>>
>>>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>>>
>>>>>>>>>>> -Adrian
>>>>>>>>>>>
>>>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>>>
>>>>>>>>>>>> Please review my notes here:
>>>>>>>>>>>>
>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>>>
>>>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Adrian, all,
I am summarizing here the results of my initial tests of the Groovy service and event executed by Adrian's Script* classes (using JSR-223).
First of all, here are the service and events updated to work with the new code (they run with the latest enhancements I committed to framework code):
=====================================================================
import org.ofbiz.base.util.UtilDateTime
import org.ofbiz.entity.util.EntityUtil
// THIS IS A SERVICE
def setLastInventoryCount() {
inventoryItem = ofbiz.findOne('InventoryItem')
if (!inventoryItem) {
ofbiz.logWarning("The InventoryItem with inventoryItemId=${parameters.inventoryItemId} doesn't exist.")
return ofbiz.failure("Inventory item with id ${parameters.inventoryItemId} was not found.")
}
List productFacilities = ofbiz.findList('ProductFacility', [productId:inventoryItem.productId, facilityId:inventoryItem.facilityId])
productFacilities.each {
countResult = ofbiz.runService('getInventoryAvailableByFacility', [productId:it.productId, facilityId: it.facilityId])
result = ofbiz.runService('updateProductFacility', [productId:it.productId, facilityId:it.facilityId, lastInventoryCount:countResult.availableToPromiseTotal])
}
return ofbiz.success("Updated inventory count for product ${inventoryItem.productId}.")
}
// THIS IS AN EVENT
def updateProductCategoryMember() {
thruDate = parameters.thruDate
if (!thruDate) {
thruDate = UtilDateTime.nowTimestamp()
}
try {
productCategoryMember = EntityUtil.getFirst(EntityUtil.filterByDate(ofbiz.findList('ProductCategoryMember', [productCategoryId: parameters.productCategoryId, productId: parameters.productId])))
if (productCategoryMember) {
productCategoryMember.setString('thruDate', thruDate)
productCategoryMember.store()
}
} catch(Exception e) {
return ofbiz.error("The following error occurred setting thruDate on category ${parameters.productCategoryId} for product ${parameters.productId}: ${e.getMessage()}")
}
return ofbiz.success("Set thruDate ${thruDate} on category ${parameters.productCategoryId} for product ${parameters.productId}")
}
=====================================================================
And here are some comments, each with a face to highlight the result:
:-) good
:-/ so and so
:-( bad
* the code above is the whole content of the file I have created: as you can see is still very clear: no need to declare classes, define accessors; you simply have to write the business logic
** :-)
* after the switch to JSR-223 the "DSL method" are accessed thru the "ofbiz" reference (instead of being directly available as method calls)
** :-/ (because of the small added complexity) but also :-) because now the IDE is able to autocomplete the method calls to the "ofbiz" object (with a small tweak that I will explain); this is actually a nice to have feature
* after the switch to JSR-223 the debugger of my IDE (Idea) is no more able to walk the Groovy services and events; it is working like a charm when using the Groovy specific service engine and event handler
** :-( this is really a bummer! is this only an issue with Idea? is it working with Eclipse? Need to research on this
The summary is:
* the new mechanism works fine and still allows to implement very nice services and events; this is really good
* the debug issue is rather big one (the lack of debugging tools for Minilang was one of the most frequent complains) but this is an issue that can be researched/addressed and shouldn't block the evaluation/adoption of this "new" language for services/events; even if we will fail to find a solution we could easily run the Groovy services/events using the custom engine/handler and this will not require any code change to the services/events
Next step:
it would be really nice to continue this proof of concepts by converting some interesting Java services/events and Minilang services/events to Groovy: this will help to complete the ScriptHelper classes and greatly help to appreciate pros and cons.
Is there any interest in this effort? I see a big potential in this approach, but the opinion from the community will be important.
Kind regards,
Jacopo
On Mar 13, 2012, at 4:59 PM, Adrian Crum wrote:
> Cool - thanks! My apologies - I had not given much thought to the object construction sequence in that section of code.
>
> I'm pretty sure I followed good concurrency practices overall, but there is always a chance I missed something.
>
> -Adrian
>
> On 3/13/2012 3:49 PM, Jacopo Cappellato wrote:
>> This is now fixed in rev. 1300202
>> By the way: we will need to carefully review the way ScriptHelper/ContextHelper are built (and especially how the context is passed) in order to make sure the code is thread safe.
>>
>> Jacopo
>>
>> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>>
>>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>>
>>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>>> Hey Adrian,
>>>>>
>>>>> a quick question before I dig into the details.
>>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>>
>>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Jacopo,
>>>>>>>>
>>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>>
>>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>>
>>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>>
>>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>>
>>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>>
>>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>>
>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>>> ...
>>>>>>>>
>>>>>>>> private final ScriptHelper helper;
>>>>>>>>
>>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>>> return helper.makeValue(entityName);
>>>>>>>> }
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>>> Adrian, thank you for your work.
>>>>>>>>>
>>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>>
>>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>>
>>>>>>>>> Kind regards and again thank you,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>>
>>>>>>>>>> Jacopo,
>>>>>>>>>>
>>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>>
>>>>>>>>>>> Please review my notes here:
>>>>>>>>>>>
>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>>
>>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
Okay, I lied - the bindings are preserved between evaluations.
So go ahead and make whatever changes you need to make.
-Adrian
On 3/14/2012 5:28 AM, Adrian Crum wrote:
> The main reason is to supply a function/method argument if
> modelService.invoke is not empty.
>
> A script containing a function/method is evaluated twice - once to
> evaluate the script as a whole and then again to invoke the
> function/method. Any bindings that were created/used in the first
> evaluation are lost in the function/method call - so the bindings are
> passed as a function/method call argument.
>
> I will update JavaScriptTest.js to illustrate the difference.
>
> -Adrian
>
> On 3/14/2012 5:18 AM, Jacopo Cappellato wrote:
>> Adrian,
>>
>> is there a reason for invoking the script from ScriptEngine and
>> ScriptEventHandler using:
>>
>> Object resultObj =
>> ScriptUtil.executeScript(getLocation(modelService),
>> modelService.invoke, scriptContext, new Object[] { context });
>>
>> rather than
>>
>> Object resultObj =
>> ScriptUtil.executeScript(getLocation(modelService),
>> modelService.invoke, scriptContext, null);
>>
>> I don't know what the args argument is used for but now we have to
>> declare all the Groovy methods (events and services) in this way:
>>
>> def setLastInventoryCount(Map notUsedInputMap) {
>> ...
>> }
>>
>> rather than
>>
>> def setLastInventoryCount() {
>> ...
>> }
>>
>> and I really like the latter form because it is essential and non
>> technical: the service/event *only* contains business rules
>> specifications.
>> Any objections if I change the service/event handlers to pass a null
>> args?
>>
>> Please also see my comments inline:
>>
>> On Mar 13, 2012, at 4:59 PM, Adrian Crum wrote:
>>
>>> Cool - thanks! My apologies - I had not given much thought to the
>>> object construction sequence in that section of code.
>> Np, the code is young and I am happy to help to test/debug it.
>>
>>> I'm pretty sure I followed good concurrency practices overall, but
>>> there is always a chance I missed something.
>> Ok, I didn't look enough closely at the details and in fact it may be
>> good to go.
>>
>> Jacopo
>>
>>> -Adrian
>>>
>>> On 3/13/2012 3:49 PM, Jacopo Cappellato wrote:
>>>> This is now fixed in rev. 1300202
>>>> By the way: we will need to carefully review the way
>>>> ScriptHelper/ContextHelper are built (and especially how the
>>>> context is passed) in order to make sure the code is thread safe.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>>>>
>>>>> Ok thanks... it doesn't work for me because the scriptType is set
>>>>> to UNKNOWN instead of SERVICE... I am debugging it now.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>>>>
>>>>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>>>>> Hey Adrian,
>>>>>>>
>>>>>>> a quick question before I dig into the details.
>>>>>>> I am using the success(..)/error(...) methods to get a result
>>>>>>> Map (for services) or result String (for Events) and I have
>>>>>>> noticed that in the new implementation they are saved using the
>>>>>>> ContextHelper.putResults method.
>>>>>>> Who is supposed to call the ContextHelper.getResults() method?
>>>>>>> It would be nice if this was done automatically by the framework
>>>>>>> (service/event handlers) rather than the script itself... but I
>>>>>>> am testing it with a service and I can't get the message back.
>>>>>>> If you could show me a code snippet it would help... if not do
>>>>>>> not worry I will figure it out.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>>>>
>>>>>>>>>> Jacopo,
>>>>>>>>>>
>>>>>>>>>> Could you share with the rest of us the limitations caused by
>>>>>>>>>> the refactoring?
>>>>>>>>>>
>>>>>>>>> Definitely: I will review, study and use the new code and I
>>>>>>>>> will provide feedback about the gaps I see.
>>>>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>>>>
>>>>>>>>> One thing that I am not sure I like is the fact that now some
>>>>>>>>> of the strings in Groovy will be expanded using the
>>>>>>>>> FlexibleStringExpander rather than the Groovy GStrings... this
>>>>>>>>> could be confusing when you are programming in Groovy.
>>>>>>>>> I was also planning to use closures to manage nicely
>>>>>>>>> EntityListIterators... but I can probably still do this in the
>>>>>>>>> GroovyBaseScript.
>>>>>>>>>
>>>>>>>>>> The work I committed is just a springboard - anyone can
>>>>>>>>>> modify it/extend it in any way they want.
>>>>>>>>> Ok, this is good... and dangerous if anyone will add what they
>>>>>>>>> want without first agreeing/understanding on the purpose of
>>>>>>>>> this class. Do we all agree that it should stay clean and
>>>>>>>>> light by providing simple access for common operations rather
>>>>>>>>> than providing access to all the possible operations? I mean,
>>>>>>>>> it should provide a mechanism to perform tasks in the most
>>>>>>>>> common ways; for special (less frequent) tasks the calling
>>>>>>>>> script should use the features provided natively by the
>>>>>>>>> language and the standard API (delegator/dispatcher/etc...).
>>>>>>>> I agree. Let's keep the API limited to OFBiz-specific
>>>>>>>> artifacts: entity engine, service engine, logging, etc.
>>>>>>>>
>>>>>>>>>> As I mentioned previously, the GroovyBaseScript class can
>>>>>>>>>> simply delegate to the helper class:
>>>>>>>>> Yes, I will re-implement it following this design and let you
>>>>>>>>> know how it goes; but we will still need the Groovy service
>>>>>>>>> engine and Groovy event handlers... in order to keep the
>>>>>>>>> architecture clean should we start to think to them as
>>>>>>>>> extensions for the applications only? I mean that they could
>>>>>>>>> be part of the future release of "OFBiz Applications" and not
>>>>>>>>> part of the future release "OFBiz Framework". In this way the
>>>>>>>>> dependency and custom Groovy code will all be in the
>>>>>>>>> Applications (if they will be reimplemented in Groovy) and the
>>>>>>>>> framework will stay clean and light.
>>>>>>>> I was planning on having mini-lang's MethodContext extend
>>>>>>>> ScriptHelper so all scripting languages (including mini-lang)
>>>>>>>> are running on the same code base.
>>>>>>>>
>>>>>>>> I'm thinking all of this will tie up rather nicely once we have
>>>>>>>> a reduced framework. Scripting can be its own component that
>>>>>>>> runs on top of the new framework. Higher-level applications can
>>>>>>>> then extend the scripting component
>>>>>>>>
>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>>> abstract class GroovyBaseScript extends Script implements
>>>>>>>>>> ScriptHelper {
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> private final ScriptHelper helper;
>>>>>>>>>>
>>>>>>>>>> Map runService(String serviceName, Map inputMap) throws
>>>>>>>>>> ScriptException {
>>>>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>>>>> return helper.makeValue(entityName);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>>>>> Adrian, thank you for your work.
>>>>>>>>>>>
>>>>>>>>>>> What I was writing was actually an extension to Groovy for
>>>>>>>>>>> making it OFBiz friendly; now we have a "reusable" (? by
>>>>>>>>>>> other languages) version of it... my guess is that you did
>>>>>>>>>>> it because you liked the ideas in it (and I appreciate it)
>>>>>>>>>>> and you thought it was useful for other languages as well;
>>>>>>>>>>> and you may be right about this even if, as I initially
>>>>>>>>>>> mentioned, I would have preferred to complete my work, or at
>>>>>>>>>>> least add a bit more to it, test the DSL with more poc and
>>>>>>>>>>> Minilang-->Groovy conversions before crystallizing it into
>>>>>>>>>>> an interface (one of the advantages in doing it in Groovy
>>>>>>>>>>> was that I could implement it without the need to
>>>>>>>>>>> build/restart the system)... now I have an interface and an
>>>>>>>>>>> implementation of it to take care of.
>>>>>>>>>>> But I don't want to complain (*) and I will review your work
>>>>>>>>>>> closely and see what I can do to use it properly in Groovy.
>>>>>>>>>>> This refactoring has introduced a series of limitations that
>>>>>>>>>>> I am determined to resolve and it will require some more
>>>>>>>>>>> study around Groovy and ideas to cope with them... I really
>>>>>>>>>>> want that, if we will ever adopt Groovy as our next language
>>>>>>>>>>> for the applications, it will look as perfect and simple and
>>>>>>>>>>> natural and integrated as possible: the natural language for
>>>>>>>>>>> OFBiz (like Minilang is now) rather than OFBiz implemented
>>>>>>>>>>> in Groovy.
>>>>>>>>>>>
>>>>>>>>>>> But before I proceed: what is the next step in your plan?
>>>>>>>>>>> What should go in the ScriptHelper interface? Am I allowed
>>>>>>>>>>> to enhance it based on my discoveries in my poc work
>>>>>>>>>>> (Minilang-->Groovy) or should I consider it a final
>>>>>>>>>>> interface that doesn't have to be modified? Should I ask
>>>>>>>>>>> before enhancing it? I don't want to hijack your work. And
>>>>>>>>>>> more importantly: can I assume that this helper class will
>>>>>>>>>>> stay light and simple? I really don't want to see it
>>>>>>>>>>> transformed into a huge class containing a big amount of
>>>>>>>>>>> methods from different APIs... the fact that all languages
>>>>>>>>>>> will potentially use it and may wish to extend it with util
>>>>>>>>>>> methods that make sense to them concerns me a little bit
>>>>>>>>>>> (for example, a language with weak support for Map handling
>>>>>>>>>>> may need utils methods to manage Maps that could be useless
>>>>>>>>>>> for Groovy).
>>>>>>>>>>>
>>>>>>>>>>> Kind regards and again thank you,
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> (*) even if I find a bit annoying to see my work intercepted
>>>>>>>>>>> and re-routed while I was in the middle of it, I also
>>>>>>>>>>> appreciate the time and effort you spent on it and I really
>>>>>>>>>>> want to accept the fact that working in a community means
>>>>>>>>>>> that I have to blend and negotiate my own ideas and plans
>>>>>>>>>>> with the ones from others: sometimes it means that you get
>>>>>>>>>>> great help, sometimes it means that your own beautiful and
>>>>>>>>>>> perfect ideas are touched and rearranged to fit other's
>>>>>>>>>>> plans and other's beautiful ideas.
>>>>>>>>>>> I hope that the good attitude and flexibility I am trying to
>>>>>>>>>>> apply here will be also used by you and others when it will
>>>>>>>>>>> be time for you to accept other's proposals/changes
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>
>>>>>>>>>>>> I committed a generic, reusable version of this idea in rev
>>>>>>>>>>>> 1299924.
>>>>>>>>>>>>
>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have just completed my first pass in the implementation
>>>>>>>>>>>>> of a DSL (Domain Specific Language) for OFBiz that can be
>>>>>>>>>>>>> used by Groovy services to act like a modern version of
>>>>>>>>>>>>> Minilang.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review my notes here:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I look forward to your comments and feedback but please
>>>>>>>>>>>>> consider that 1) it is a work in progress, 2) I spent a
>>>>>>>>>>>>> lot of time and mental energy in the effort (reaching
>>>>>>>>>>>>> simplicity is really complex task!)... so please don't be
>>>>>>>>>>>>> too picky :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>
>>>>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service
>>>>>>>>>>>>> mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
The main reason is to supply a function/method argument if
modelService.invoke is not empty.
A script containing a function/method is evaluated twice - once to
evaluate the script as a whole and then again to invoke the
function/method. Any bindings that were created/used in the first
evaluation are lost in the function/method call - so the bindings are
passed as a function/method call argument.
I will update JavaScriptTest.js to illustrate the difference.
-Adrian
On 3/14/2012 5:18 AM, Jacopo Cappellato wrote:
> Adrian,
>
> is there a reason for invoking the script from ScriptEngine and ScriptEventHandler using:
>
> Object resultObj = ScriptUtil.executeScript(getLocation(modelService), modelService.invoke, scriptContext, new Object[] { context });
>
> rather than
>
> Object resultObj = ScriptUtil.executeScript(getLocation(modelService), modelService.invoke, scriptContext, null);
>
> I don't know what the args argument is used for but now we have to declare all the Groovy methods (events and services) in this way:
>
> def setLastInventoryCount(Map notUsedInputMap) {
> ...
> }
>
> rather than
>
> def setLastInventoryCount() {
> ...
> }
>
> and I really like the latter form because it is essential and non technical: the service/event *only* contains business rules specifications.
> Any objections if I change the service/event handlers to pass a null args?
>
> Please also see my comments inline:
>
> On Mar 13, 2012, at 4:59 PM, Adrian Crum wrote:
>
>> Cool - thanks! My apologies - I had not given much thought to the object construction sequence in that section of code.
> Np, the code is young and I am happy to help to test/debug it.
>
>> I'm pretty sure I followed good concurrency practices overall, but there is always a chance I missed something.
> Ok, I didn't look enough closely at the details and in fact it may be good to go.
>
> Jacopo
>
>> -Adrian
>>
>> On 3/13/2012 3:49 PM, Jacopo Cappellato wrote:
>>> This is now fixed in rev. 1300202
>>> By the way: we will need to carefully review the way ScriptHelper/ContextHelper are built (and especially how the context is passed) in order to make sure the code is thread safe.
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>>>
>>>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>>>
>>>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>>>> Hey Adrian,
>>>>>>
>>>>>> a quick question before I dig into the details.
>>>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> Jacopo,
>>>>>>>>>
>>>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>>>
>>>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>>>
>>>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>>>
>>>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>>>
>>>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>>>
>>>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>>>
>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> private final ScriptHelper helper;
>>>>>>>>>
>>>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>>>> return helper.makeValue(entityName);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>>>> Adrian, thank you for your work.
>>>>>>>>>>
>>>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>>>
>>>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>>>
>>>>>>>>>> Kind regards and again thank you,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>>>
>>>>>>>>>>> Jacopo,
>>>>>>>>>>>
>>>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>>>
>>>>>>>>>>> -Adrian
>>>>>>>>>>>
>>>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>>>
>>>>>>>>>>>> Please review my notes here:
>>>>>>>>>>>>
>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>>>
>>>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Adrian,
is there a reason for invoking the script from ScriptEngine and ScriptEventHandler using:
Object resultObj = ScriptUtil.executeScript(getLocation(modelService), modelService.invoke, scriptContext, new Object[] { context });
rather than
Object resultObj = ScriptUtil.executeScript(getLocation(modelService), modelService.invoke, scriptContext, null);
I don't know what the args argument is used for but now we have to declare all the Groovy methods (events and services) in this way:
def setLastInventoryCount(Map notUsedInputMap) {
...
}
rather than
def setLastInventoryCount() {
...
}
and I really like the latter form because it is essential and non technical: the service/event *only* contains business rules specifications.
Any objections if I change the service/event handlers to pass a null args?
Please also see my comments inline:
On Mar 13, 2012, at 4:59 PM, Adrian Crum wrote:
> Cool - thanks! My apologies - I had not given much thought to the object construction sequence in that section of code.
Np, the code is young and I am happy to help to test/debug it.
>
> I'm pretty sure I followed good concurrency practices overall, but there is always a chance I missed something.
Ok, I didn't look enough closely at the details and in fact it may be good to go.
Jacopo
>
> -Adrian
>
> On 3/13/2012 3:49 PM, Jacopo Cappellato wrote:
>> This is now fixed in rev. 1300202
>> By the way: we will need to carefully review the way ScriptHelper/ContextHelper are built (and especially how the context is passed) in order to make sure the code is thread safe.
>>
>> Jacopo
>>
>> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>>
>>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>>
>>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>>> Hey Adrian,
>>>>>
>>>>> a quick question before I dig into the details.
>>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>>
>>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Jacopo,
>>>>>>>>
>>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>>
>>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>>
>>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>>
>>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>>
>>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>>
>>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>>
>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>>> ...
>>>>>>>>
>>>>>>>> private final ScriptHelper helper;
>>>>>>>>
>>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>>> return helper.makeValue(entityName);
>>>>>>>> }
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>>> Adrian, thank you for your work.
>>>>>>>>>
>>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>>
>>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>>
>>>>>>>>> Kind regards and again thank you,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>>
>>>>>>>>>> Jacopo,
>>>>>>>>>>
>>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>>
>>>>>>>>>>> Please review my notes here:
>>>>>>>>>>>
>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>>
>>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
Cool - thanks! My apologies - I had not given much thought to the object
construction sequence in that section of code.
I'm pretty sure I followed good concurrency practices overall, but there
is always a chance I missed something.
-Adrian
On 3/13/2012 3:49 PM, Jacopo Cappellato wrote:
> This is now fixed in rev. 1300202
> By the way: we will need to carefully review the way ScriptHelper/ContextHelper are built (and especially how the context is passed) in order to make sure the code is thread safe.
>
> Jacopo
>
> On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
>
>> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>>
>> Jacopo
>>
>> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>>
>>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>>
>>> -Adrian
>>>
>>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>>> Hey Adrian,
>>>>
>>>> a quick question before I dig into the details.
>>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>>
>>>> Thanks,
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>>
>>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> Jacopo,
>>>>>>>
>>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>>
>>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>>
>>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>>
>>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>>
>>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>>
>>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>>
>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>>> ...
>>>>>>>
>>>>>>> private final ScriptHelper helper;
>>>>>>>
>>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>>> return helper.runService(serviceName, inputMap);
>>>>>>> }
>>>>>>>
>>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>>> return helper.makeValue(entityName);
>>>>>>> }
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>>> Adrian, thank you for your work.
>>>>>>>>
>>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>>
>>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>>
>>>>>>>> Kind regards and again thank you,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> Jacopo,
>>>>>>>>>
>>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>>
>>>>>>>>>> Please review my notes here:
>>>>>>>>>>
>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>>
>>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
This is now fixed in rev. 1300202
By the way: we will need to carefully review the way ScriptHelper/ContextHelper are built (and especially how the context is passed) in order to make sure the code is thread safe.
Jacopo
On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
>
> Jacopo
>
> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>
>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>
>> -Adrian
>>
>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>> Hey Adrian,
>>>
>>> a quick question before I dig into the details.
>>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>
>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>
>>>>>> Jacopo,
>>>>>>
>>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>>
>>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>
>>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>>
>>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>>
>>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>>
>>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>>
>>>>
>>>>> Jacopo
>>>>>
>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>> ...
>>>>>>
>>>>>> private final ScriptHelper helper;
>>>>>>
>>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>>> return helper.runService(serviceName, inputMap);
>>>>>> }
>>>>>>
>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>> return helper.makeValue(entityName);
>>>>>> }
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> }
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>> Adrian, thank you for your work.
>>>>>>>
>>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>
>>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>>
>>>>>>> Kind regards and again thank you,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>>
>>>>>>>
>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Jacopo,
>>>>>>>>
>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>>
>>>>>>>>> Please review my notes here:
>>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>
>>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
>
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN instead of SERVICE... I am debugging it now.
Jacopo
On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>
> -Adrian
>
> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>> Hey Adrian,
>>
>> a quick question before I dig into the details.
>> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
>> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
>> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>>
>> Thanks,
>>
>> Jacopo
>>
>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>
>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>
>>>>> Jacopo,
>>>>>
>>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>>
>>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>
>>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>>
>>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>>
>>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>>
>>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>>
>>>
>>>> Jacopo
>>>>
>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>> ...
>>>>>
>>>>> private final ScriptHelper helper;
>>>>>
>>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>>> return helper.runService(serviceName, inputMap);
>>>>> }
>>>>>
>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>> return helper.makeValue(entityName);
>>>>> }
>>>>>
>>>>> ...
>>>>>
>>>>> }
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>> Adrian, thank you for your work.
>>>>>>
>>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>
>>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>>
>>>>>> Kind regards and again thank you,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>>
>>>>>>
>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> Jacopo,
>>>>>>>
>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>>
>>>>>>>> Please review my notes here:
>>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>
>>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
-Adrian
On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
> Hey Adrian,
>
> a quick question before I dig into the details.
> I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
> Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
> If you could show me a code snippet it would help... if not do not worry I will figure it out.
>
> Thanks,
>
> Jacopo
>
> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>
>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>
>>>> Jacopo,
>>>>
>>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>>
>>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>
>>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>>
>>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>>
>>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>>
>> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>>
>>
>>> Jacopo
>>>
>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>> ...
>>>>
>>>> private final ScriptHelper helper;
>>>>
>>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>>> return helper.runService(serviceName, inputMap);
>>>> }
>>>>
>>>> Map makeValue(String entityName) throws ScriptException {
>>>> return helper.makeValue(entityName);
>>>> }
>>>>
>>>> ...
>>>>
>>>> }
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>> Adrian, thank you for your work.
>>>>>
>>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>
>>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>>
>>>>> Kind regards and again thank you,
>>>>>
>>>>> Jacopo
>>>>>
>>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>>
>>>>>
>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>
>>>>>> Jacopo,
>>>>>>
>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>>
>>>>>>> Please review my notes here:
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>
>>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Hey Adrian,
a quick question before I dig into the details.
I am using the success(..)/error(...) methods to get a result Map (for services) or result String (for Events) and I have noticed that in the new implementation they are saved using the ContextHelper.putResults method.
Who is supposed to call the ContextHelper.getResults() method? It would be nice if this was done automatically by the framework (service/event handlers) rather than the script itself... but I am testing it with a service and I can't get the message back.
If you could show me a code snippet it would help... if not do not worry I will figure it out.
Thanks,
Jacopo
On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>
>>> Jacopo,
>>>
>>> Could you share with the rest of us the limitations caused by the refactoring?
>>>
>> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
>
> Oh. I thought you were talking about the ScriptUtil refactoring.
>
>> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
>> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>>
>>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
>> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>
> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity engine, service engine, logging, etc.
>
>>
>>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
>> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
>
> I was planning on having mini-lang's MethodContext extend ScriptHelper so all scripting languages (including mini-lang) are running on the same code base.
>
> I'm thinking all of this will tie up rather nicely once we have a reduced framework. Scripting can be its own component that runs on top of the new framework. Higher-level applications can then extend the scripting component
>
>
>>
>> Jacopo
>>
>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>> ...
>>>
>>> private final ScriptHelper helper;
>>>
>>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>>> return helper.runService(serviceName, inputMap);
>>> }
>>>
>>> Map makeValue(String entityName) throws ScriptException {
>>> return helper.makeValue(entityName);
>>> }
>>>
>>> ...
>>>
>>> }
>>>
>>> -Adrian
>>>
>>>
>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>> Adrian, thank you for your work.
>>>>
>>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>
>>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>>
>>>> Kind regards and again thank you,
>>>>
>>>> Jacopo
>>>>
>>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>>
>>>>
>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>
>>>>> Jacopo,
>>>>>
>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>>
>>>>>> Please review my notes here:
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>
>>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>> Could you share with the rest of us the limitations caused by the refactoring?
>
One annoying limitation is that, after switching from GroovyEngine to ScriptEngine my IDE (I am using Idea) is no more able to debug my Groovy services; this may be trivial (and I don't know if it happens with other editors as well) but in my opinion it would be alone a good reason for keeping the custom 50 lines of the GroovyEngine class
I will try to see if there is something I can do to fix this, but the problem I am facing is probably this:
http://groovy.329449.n5.nabble.com/breakpoints-in-groovy-script-files-td4264722.html
Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>
>> Jacopo,
>>
>> Could you share with the rest of us the limitations caused by the refactoring?
>>
> Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
Oh. I thought you were talking about the ScriptUtil refactoring.
> One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
> I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
>
>> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
> Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
I agree. Let's keep the API limited to OFBiz-specific artifacts: entity
engine, service engine, logging, etc.
>
>> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
> Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
I was planning on having mini-lang's MethodContext extend ScriptHelper
so all scripting languages (including mini-lang) are running on the same
code base.
I'm thinking all of this will tie up rather nicely once we have a
reduced framework. Scripting can be its own component that runs on top
of the new framework. Higher-level applications can then extend the
scripting component
>
> Jacopo
>
>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>> ...
>>
>> private final ScriptHelper helper;
>>
>> Map runService(String serviceName, Map inputMap) throws ScriptException {
>> return helper.runService(serviceName, inputMap);
>> }
>>
>> Map makeValue(String entityName) throws ScriptException {
>> return helper.makeValue(entityName);
>> }
>>
>> ...
>>
>> }
>>
>> -Adrian
>>
>>
>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>> Adrian, thank you for your work.
>>>
>>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>
>>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>>
>>> Kind regards and again thank you,
>>>
>>> Jacopo
>>>
>>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>>
>>>
>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>
>>>> Jacopo,
>>>>
>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>> Hi all,
>>>>>
>>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>>
>>>>> Please review my notes here:
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>
>>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jacopo
>>>>>
>>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
> Jacopo,
>
> Could you share with the rest of us the limitations caused by the refactoring?
>
Definitely: I will review, study and use the new code and I will provide feedback about the gaps I see.
One thing that I am not sure I like is the fact that now some of the strings in Groovy will be expanded using the FlexibleStringExpander rather than the Groovy GStrings... this could be confusing when you are programming in Groovy.
I was also planning to use closures to manage nicely EntityListIterators... but I can probably still do this in the GroovyBaseScript.
> The work I committed is just a springboard - anyone can modify it/extend it in any way they want.
Ok, this is good... and dangerous if anyone will add what they want without first agreeing/understanding on the purpose of this class. Do we all agree that it should stay clean and light by providing simple access for common operations rather than providing access to all the possible operations? I mean, it should provide a mechanism to perform tasks in the most common ways; for special (less frequent) tasks the calling script should use the features provided natively by the language and the standard API (delegator/dispatcher/etc...).
>
> As I mentioned previously, the GroovyBaseScript class can simply delegate to the helper class:
Yes, I will re-implement it following this design and let you know how it goes; but we will still need the Groovy service engine and Groovy event handlers... in order to keep the architecture clean should we start to think to them as extensions for the applications only? I mean that they could be part of the future release of "OFBiz Applications" and not part of the future release "OFBiz Framework". In this way the dependency and custom Groovy code will all be in the Applications (if they will be reimplemented in Groovy) and the framework will stay clean and light.
Jacopo
>
> abstract class GroovyBaseScript extends Script implements ScriptHelper {
> ...
>
> private final ScriptHelper helper;
>
> Map runService(String serviceName, Map inputMap) throws ScriptException {
> return helper.runService(serviceName, inputMap);
> }
>
> Map makeValue(String entityName) throws ScriptException {
> return helper.makeValue(entityName);
> }
>
> ...
>
> }
>
> -Adrian
>
>
> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>> Adrian, thank you for your work.
>>
>> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
>> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>>
>> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>>
>> Kind regards and again thank you,
>>
>> Jacopo
>>
>> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
>> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>>
>>
>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>
>>> Jacopo,
>>>
>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>
>>> -Adrian
>>>
>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>> Hi all,
>>>>
>>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>>
>>>> Please review my notes here:
>>>>
>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>
>>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>>
>>>> Regards,
>>>>
>>>> Jacopo
>>>>
>>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
Jacopo,
Could you share with the rest of us the limitations caused by the
refactoring?
The work I committed is just a springboard - anyone can modify it/extend
it in any way they want.
As I mentioned previously, the GroovyBaseScript class can simply
delegate to the helper class:
abstract class GroovyBaseScript extends Script implements ScriptHelper {
...
private final ScriptHelper helper;
Map runService(String serviceName, Map inputMap) throws
ScriptException {
return helper.runService(serviceName, inputMap);
}
Map makeValue(String entityName) throws ScriptException {
return helper.makeValue(entityName);
}
...
}
-Adrian
On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
> Adrian, thank you for your work.
>
> What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
> But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
>
> But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
>
> Kind regards and again thank you,
>
> Jacopo
>
> (*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
> I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
>
>
> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>
>> Jacopo,
>>
>> I committed a generic, reusable version of this idea in rev 1299924.
>>
>> -Adrian
>>
>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>> Hi all,
>>>
>>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>>
>>> Please review my notes here:
>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>
>>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Adrian, thank you for your work.
What I was writing was actually an extension to Groovy for making it OFBiz friendly; now we have a "reusable" (? by other languages) version of it... my guess is that you did it because you liked the ideas in it (and I appreciate it) and you thought it was useful for other languages as well; and you may be right about this even if, as I initially mentioned, I would have preferred to complete my work, or at least add a bit more to it, test the DSL with more poc and Minilang-->Groovy conversions before crystallizing it into an interface (one of the advantages in doing it in Groovy was that I could implement it without the need to build/restart the system)... now I have an interface and an implementation of it to take care of.
But I don't want to complain (*) and I will review your work closely and see what I can do to use it properly in Groovy. This refactoring has introduced a series of limitations that I am determined to resolve and it will require some more study around Groovy and ideas to cope with them... I really want that, if we will ever adopt Groovy as our next language for the applications, it will look as perfect and simple and natural and integrated as possible: the natural language for OFBiz (like Minilang is now) rather than OFBiz implemented in Groovy.
But before I proceed: what is the next step in your plan? What should go in the ScriptHelper interface? Am I allowed to enhance it based on my discoveries in my poc work (Minilang-->Groovy) or should I consider it a final interface that doesn't have to be modified? Should I ask before enhancing it? I don't want to hijack your work. And more importantly: can I assume that this helper class will stay light and simple? I really don't want to see it transformed into a huge class containing a big amount of methods from different APIs... the fact that all languages will potentially use it and may wish to extend it with util methods that make sense to them concerns me a little bit (for example, a language with weak support for Map handling may need utils methods to manage Maps that could be useless for Groovy).
Kind regards and again thank you,
Jacopo
(*) even if I find a bit annoying to see my work intercepted and re-routed while I was in the middle of it, I also appreciate the time and effort you spent on it and I really want to accept the fact that working in a community means that I have to blend and negotiate my own ideas and plans with the ones from others: sometimes it means that you get great help, sometimes it means that your own beautiful and perfect ideas are touched and rearranged to fit other's plans and other's beautiful ideas.
I hope that the good attitude and flexibility I am trying to apply here will be also used by you and others when it will be time for you to accept other's proposals/changes
On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
> Jacopo,
>
> I committed a generic, reusable version of this idea in rev 1299924.
>
> -Adrian
>
> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>> Hi all,
>>
>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>
>> Please review my notes here:
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>
>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>
>> Regards,
>>
>> Jacopo
>>
>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Adrian Crum <ad...@sandglass-software.com>.
Jacopo,
I committed a generic, reusable version of this idea in rev 1299924.
-Adrian
On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
> Hi all,
>
> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>
> Please review my notes here:
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>
> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>
> Regards,
>
> Jacopo
>
> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Erwan de FERRIERES <er...@nereide.fr>.
Le 08/03/2012 20:04, Karl Pitrich a écrit :
> Hi Jacopo,
>
> a nice step in the right direction, IMHO. I like it.
>
> Do you think it's possible to hack up a transpiler from Minilang to JacopoLang(tm),
> (i.e. like Coffescript has for Javascript), so that we can get rid of minilang entirely?
Hi Karl,
minilang won't be removed from OFBiz. It is widely used, and very
useful. Look at the other thread Adrian started, there is a will to
improve it !
Cheers,
>
>
> Greetings,
>
> - Karl
>
> On 08.03.2012, at 19:02, Jacopo Cappellato wrote:
>
>> Hi all,
>>
>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>
>> Please review my notes here:
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>
>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>
>> Regards,
>>
>> Jacopo
>>
>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
>
>
--
Erwan de FERRIERES
www.nereide.biz
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Karl Pitrich <ka...@lusini.com>.
Hi Jacopo,
a nice step in the right direction, IMHO. I like it.
Do you think it's possible to hack up a transpiler from Minilang to JacopoLang(tm),
(i.e. like Coffescript has for Javascript), so that we can get rid of minilang entirely?
Greetings,
- Karl
On 08.03.2012, at 19:02, Jacopo Cappellato wrote:
> Hi all,
>
> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>
> Please review my notes here:
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>
> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>
> Regards,
>
> Jacopo
>
> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Thanks Jacques.
I actually don't know the answer but I will be surprised if everyone will agree to switch from Minilang to Groovy (at least not in the short term); by the way I still see a value in the effort of cleaning and making Minilang more consistent (maybe I would not spend much of my time on the effort, because at the moment I see a greater potential in Groovy, but I understand that it makes sense to invest time in that great language); even if at some point in the future we will decide to migrate out of Minilang, having a cleaner set of scripts will greatly help the migration.
Jacopo
On Mar 8, 2012, at 8:29 PM, Jacques Le Roux wrote:
> Hi Jacopo,
>
> Interesting, but then (question to all, and espaically Adrian who began on minilang overhaul ) should we continue the minilang overhaul or rather gather all efforts to completly, step by step, move all minilang scripts to this new possiblity?
>
> Jacques
>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> Hi all,
>>
>> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang.
>>
>> Please review my notes here:
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>
>> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>>
>> Regards,
>>
>> Jacopo
>>
>> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Jacopo,
Interesting, but then (question to all, and espaically Adrian who began on minilang overhaul ) should we continue the minilang
overhaul or rather gather all efforts to completly, step by step, move all minilang scripts to this new possiblity?
Jacques
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> Hi all,
>
> I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy
> services to act like a modern version of Minilang.
>
> Please review my notes here:
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>
> I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and
> mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-)
>
> Regards,
>
> Jacopo
>
> PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 9, 2012, at 8:37 AM, Sascha Rodekamp wrote:
> In the longterm future i would support Adrians approach to create an
> abstract implementation of the DSL.
This would be great even in a shorter term future.
I would suggest that we keep our DSL as simple and as clean possible: I am actually already forcing myself in these terms:
* I do not add a DSL method because I think it may be useful; I have to prove that it is (by reviewing current usage and frequency in Minilang equivalent)
* before adding a new DSL method I write a few services without it and when I identify a good recurring pattern I add it in my todo list of something that could become a method
* when I implement the method, I keep it as simple as possible without adding additional stuff (arguments etc...) that is not proven to be useful
* I expect that the final set of DSL method will be very small (not much bigger that it is now) and with very simple arguments
* we should always use standard API for anything less common more complex: this is an advantage we have in groovy (over Minilang)
In this way this Groovy specific DSL will not grow in complexity (at the end we will have very few lines of code) but it will be extensively tested over real world scenarios (e.g. converting some of the existing services); at that point it will be easy to convert the code to be used by all the scripting languages supporting JSR-223. And even if that would be impossible it would still be easy to create a different class for JSR-223 languages; then in ofbiz we could keep 2 service engines:
* "ofbizgroovy": this is the current "groovy" service engine that makes use of the DSL implemented by the class we have now (GroovyBaseScript)
* "script": this is the engine capable of running a service implemented on any scripting language supporting JSR-223 (including Groovy); this engine could inject a different "generic" version of DSL (e.g. GenericBaseScript or similar)
(of course this would only make sense if a Groovy specific DSL provides some specific advantage to Groovy services over the generic one).
In this way OFBiz will support virtually any language with a nice DSL support or Groovy with a special DSL support; this would still make a lot of sense because the code required to maintain a groovy specific engine (the one right now) is very small (a few lines of code).
Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Sascha Rodekamp <sa...@googlemail.com>.
Hi Jacopo,
great job! Groovy as DSL is very handsome (cause i can use a debugger :-)).
In the longterm future i would support Adrians approach to create an
abstract implementation of the DSL.
Some words to the groovy speed. In (theoretically) benchmarks groovy
is slower than java. Interesting would be a comparison between
mini-lang and groovy. I think the Groovy performance will be
absolutely sufficient because of the easy integration with Java. If
something’s too slow, I do it in Java. More important using the DSL is
the maintainability, developer productivity and the tool support.
Have a good day
Sascha
2012/3/9 Jacopo Cappellato <ja...@hotwaxmedia.com>:
> Thank you Anne,
>
> please see my comments inline:
>
> On Mar 9, 2012, at 1:55 AM, Anne wrote:
>
>> Hi Jacopo
>>
>> That is an excellent start! I used to prefer minilang to java because it
>> was so easy to do common tasks, but 2 things about it were so annoying that
>> I now only use it for the simplest tasks. But with java I have to put up
>> with all that extra code to get simple things done.
>>
>> Your groovy approach takes the best of minilang and the best of java, and
>> combines them. My only concern with it is speed, but I suppose we could use
>> ant to compile the groovy if there is a problem?
>
> It would be really nice to run some serious test on performance and compare the two tools.
> Currently the bytecode generated parsing Groovy is cached by OFBiz; but speed is one aspect and we should also consider the usage of memory.
>
>>
>> A couple of thoughts (probably you have already thought of these):
>>
>> Change runService to runServiceSync, so there can also be a runServiceAsync.
>
> Yes, this is a nice to have; I would prefer a slightly different naming like:
>
> runService: sync calls
> scheduleService or submitService or runServiceAsync: async calls
>
> In this way we still have a very easy name, runService, for the most common usage (calling services synchronously)
>
>>
>> The design effort on this could combine with the current design effort on
>> improving minilang. Adrian's new wiki page (
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference)
>> could be used to guide what functionality the new groovy DSL needs. So
>> there could (almost) be a one-to-one mapping between a minilang tag and a
>> DSL function.
>
> That page (and effort) will be really useful to help this DSL grow in the right direction; but in general Minilang, and most of all the huge amount of Minilang code we have in OFBiz (some good, some bad) is really useful to decide what we need in a Groovy DSL: in fact all the ideas I have tried to implement in this poc are based on a careful review of Minilang (and my experience of Minilang development).
> I like the idea of preparing a page that shows the best practices for implementing Minilang-equivalent code in Groovy: however, rather that implementing a one-to-one method mapping between Minilang and this DSL I would prefer to stay focused on the most common tasks only: all the other operations can still be used using the standard support provided by delegator, dispatcher etc... objects, or the various utils classes we have in OFBiz.
> A natural and good way to decide what we should provide as a DSL and what (probably) not is how frequent the feature is currently used in our Minilang code (but of course feedback from developers using it would help greatly).
> For example:
> the "call-service" operation in Minilang can take an optional attribute "require-new-transaction": if it is set to true the service will be executed in a separate transaction.
> the equivalent Groovy (DSL for OFBiz) is "runService" and doesn't support this option (it runs the service in the same transaction); even if it would be trivial to enhance the DSL to support also a runService method that takes an additional argument (or use a different name), after reviewing the existing code I realized that we won't probably need this feature: in all the OFBiz "applications" the require-new-transaction attribute is set to "true" for only 2 service calls; and for this rare occasions you can achieve the same in Groovy using the dispatcher:
>
> result1 = runService('someService', inputMap); // run the service in the current transaction
> result2 = dispatcher.runSync('someService', inputMap, 36000, true); // run in a new transaction
> if (ServiceUtil.isError(result)) return error(ServiceUtil.getErrorMessage(result));
>
> Of course we will have the flexibility to expand at will our DSL.
> Another nice feature is that it is possible to extend the DSL base class and add additional custom methods: everyone could customize the DSL and possibly implement an industry specific (or company specific or project specific) DSL very easily (something currently rather difficult in Minilang).
>
>>
>> Do you intend for the DSL to work with events, as well as services?
>
> Thanks for asking: yes my next task in my todo list is to enable it for events and data preparation scripts.
>
> Cheers,
>
> Jacopo
>
>>
>> Cheers,
>> Anne.
>>
>> On 9 March 2012 05:02, Jacopo Cappellato
>> <ja...@hotwaxmedia.com>wrote:
>>
>>> Hi all,
>>>
>>> I have just completed my first pass in the implementation of a DSL (Domain
>>> Specific Language) for OFBiz that can be used by Groovy services to act
>>> like a modern version of Minilang.
>>>
>>> Please review my notes here:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>
>>> I look forward to your comments and feedback but please consider that 1)
>>> it is a work in progress, 2) I spent a lot of time and mental energy in the
>>> effort (reaching simplicity is really complex task!)... so please don't be
>>> too picky :-)
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>> PS: if you find it useful, I can commit the Groovy service mentioned in
>>> the page in Confluence
>>
>>
>>
>>
>> --
>> 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/
>
--
Sascha Rodekamp
Visit the new german OFBiz Blog: http://www.ofbiz.biz
Lynx-Consulting GmbH
Johanniskirchplatz 6
D-33615 Bielefeld
http://www.lynx.de
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Thank you Anne,
please see my comments inline:
On Mar 9, 2012, at 1:55 AM, Anne wrote:
> Hi Jacopo
>
> That is an excellent start! I used to prefer minilang to java because it
> was so easy to do common tasks, but 2 things about it were so annoying that
> I now only use it for the simplest tasks. But with java I have to put up
> with all that extra code to get simple things done.
>
> Your groovy approach takes the best of minilang and the best of java, and
> combines them. My only concern with it is speed, but I suppose we could use
> ant to compile the groovy if there is a problem?
It would be really nice to run some serious test on performance and compare the two tools.
Currently the bytecode generated parsing Groovy is cached by OFBiz; but speed is one aspect and we should also consider the usage of memory.
>
> A couple of thoughts (probably you have already thought of these):
>
> Change runService to runServiceSync, so there can also be a runServiceAsync.
Yes, this is a nice to have; I would prefer a slightly different naming like:
runService: sync calls
scheduleService or submitService or runServiceAsync: async calls
In this way we still have a very easy name, runService, for the most common usage (calling services synchronously)
>
> The design effort on this could combine with the current design effort on
> improving minilang. Adrian's new wiki page (
> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference)
> could be used to guide what functionality the new groovy DSL needs. So
> there could (almost) be a one-to-one mapping between a minilang tag and a
> DSL function.
That page (and effort) will be really useful to help this DSL grow in the right direction; but in general Minilang, and most of all the huge amount of Minilang code we have in OFBiz (some good, some bad) is really useful to decide what we need in a Groovy DSL: in fact all the ideas I have tried to implement in this poc are based on a careful review of Minilang (and my experience of Minilang development).
I like the idea of preparing a page that shows the best practices for implementing Minilang-equivalent code in Groovy: however, rather that implementing a one-to-one method mapping between Minilang and this DSL I would prefer to stay focused on the most common tasks only: all the other operations can still be used using the standard support provided by delegator, dispatcher etc... objects, or the various utils classes we have in OFBiz.
A natural and good way to decide what we should provide as a DSL and what (probably) not is how frequent the feature is currently used in our Minilang code (but of course feedback from developers using it would help greatly).
For example:
the "call-service" operation in Minilang can take an optional attribute "require-new-transaction": if it is set to true the service will be executed in a separate transaction.
the equivalent Groovy (DSL for OFBiz) is "runService" and doesn't support this option (it runs the service in the same transaction); even if it would be trivial to enhance the DSL to support also a runService method that takes an additional argument (or use a different name), after reviewing the existing code I realized that we won't probably need this feature: in all the OFBiz "applications" the require-new-transaction attribute is set to "true" for only 2 service calls; and for this rare occasions you can achieve the same in Groovy using the dispatcher:
result1 = runService('someService', inputMap); // run the service in the current transaction
result2 = dispatcher.runSync('someService', inputMap, 36000, true); // run in a new transaction
if (ServiceUtil.isError(result)) return error(ServiceUtil.getErrorMessage(result));
Of course we will have the flexibility to expand at will our DSL.
Another nice feature is that it is possible to extend the DSL base class and add additional custom methods: everyone could customize the DSL and possibly implement an industry specific (or company specific or project specific) DSL very easily (something currently rather difficult in Minilang).
>
> Do you intend for the DSL to work with events, as well as services?
Thanks for asking: yes my next task in my todo list is to enable it for events and data preparation scripts.
Cheers,
Jacopo
>
> Cheers,
> Anne.
>
> On 9 March 2012 05:02, Jacopo Cappellato
> <ja...@hotwaxmedia.com>wrote:
>
>> Hi all,
>>
>> I have just completed my first pass in the implementation of a DSL (Domain
>> Specific Language) for OFBiz that can be used by Groovy services to act
>> like a modern version of Minilang.
>>
>> Please review my notes here:
>>
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>
>> I look forward to your comments and feedback but please consider that 1)
>> it is a work in progress, 2) I spent a lot of time and mental energy in the
>> effort (reaching simplicity is really complex task!)... so please don't be
>> too picky :-)
>>
>> Regards,
>>
>> Jacopo
>>
>> PS: if you find it useful, I can commit the Groovy service mentioned in
>> the page in Confluence
>
>
>
>
> --
> 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: Groovy services and a DSL for OFBiz - a POC
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 9, 2012, at 1:55 AM, Anne wrote:
> Do you intend for the DSL to work with events, as well as services?
Anne, today I have completed my first pass for events; services and events now can use the same methods; I have added more details here:
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+DSL+for+Groovy+Services+and+Events
Thanks,
Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Posted by Anne <an...@cohsoft.com.au>.
Hi Jacopo
That is an excellent start! I used to prefer minilang to java because it
was so easy to do common tasks, but 2 things about it were so annoying that
I now only use it for the simplest tasks. But with java I have to put up
with all that extra code to get simple things done.
Your groovy approach takes the best of minilang and the best of java, and
combines them. My only concern with it is speed, but I suppose we could use
ant to compile the groovy if there is a problem?
A couple of thoughts (probably you have already thought of these):
Change runService to runServiceSync, so there can also be a runServiceAsync.
The design effort on this could combine with the current design effort on
improving minilang. Adrian's new wiki page (
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference)
could be used to guide what functionality the new groovy DSL needs. So
there could (almost) be a one-to-one mapping between a minilang tag and a
DSL function.
Do you intend for the DSL to work with events, as well as services?
Cheers,
Anne.
On 9 March 2012 05:02, Jacopo Cappellato
<ja...@hotwaxmedia.com>wrote:
> Hi all,
>
> I have just completed my first pass in the implementation of a DSL (Domain
> Specific Language) for OFBiz that can be used by Groovy services to act
> like a modern version of Minilang.
>
> Please review my notes here:
>
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>
> I look forward to your comments and feedback but please consider that 1)
> it is a work in progress, 2) I spent a lot of time and mental energy in the
> effort (reaching simplicity is really complex task!)... so please don't be
> too picky :-)
>
> Regards,
>
> Jacopo
>
> PS: if you find it useful, I can commit the Groovy service mentioned in
> the page in Confluence
--
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/