Groovy services and a DSL for OFBiz - a POC

[Jacopo Cappellato-4]

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

[Adrian Crum-3]

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

[Adrian Crum-3]

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
>>

[Jacopo Cappellato-4]

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

[Scott Gray-2]

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

[Adrian Crum-3]

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

[Jacopo Cappellato-4]

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

[Adrian Crum-3]

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

[Jacopo Cappellato-4]

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

[Adrian Crum-3]

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

[Jacopo Cappellato-4]

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

[Adrian Crum-3]

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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

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
>

[Jacopo Cappellato-4]

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
>>
>

[Adrian Crum-3]

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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

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
>>
>

[Jacopo Cappellato-4]

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
>>>
>>
>