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
