This is now fixed in rev. 1300202
By the way: we will need to carefully review the way ScriptHelper/ContextHelper
are built (and especially how the context is passed) in order to make sure the
code is thread safe.
Jacopo
On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
> Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN
> instead of SERVICE... I am debugging it now.
>
> Jacopo
>
> On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
>
>> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>>
>> -Adrian
>>
>> On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
>>> Hey Adrian,
>>>
>>> a quick question before I dig into the details.
>>> I am using the success(..)/error(...) methods to get a result Map (for
>>> services) or result String (for Events) and I have noticed that in the new
>>> implementation they are saved using the ContextHelper.putResults method.
>>> Who is supposed to call the ContextHelper.getResults() method? It would be
>>> nice if this was done automatically by the framework (service/event
>>> handlers) rather than the script itself... but I am testing it with a
>>> service and I can't get the message back.
>>> If you could show me a code snippet it would help... if not do not worry I
>>> will figure it out.
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>> On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>>
>>>> On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
>>>>> On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
>>>>>
>>>>>> Jacopo,
>>>>>>
>>>>>> Could you share with the rest of us the limitations caused by the
>>>>>> refactoring?
>>>>>>
>>>>> Definitely: I will review, study and use the new code and I will provide
>>>>> feedback about the gaps I see.
>>>> Oh. I thought you were talking about the ScriptUtil refactoring.
>>>>
>>>>> One thing that I am not sure I like is the fact that now some of the
>>>>> strings in Groovy will be expanded using the FlexibleStringExpander
>>>>> rather than the Groovy GStrings... this could be confusing when you are
>>>>> programming in Groovy.
>>>>> I was also planning to use closures to manage nicely
>>>>> EntityListIterators... but I can probably still do this in the
>>>>> GroovyBaseScript.
>>>>>
>>>>>> The work I committed is just a springboard - anyone can modify it/extend
>>>>>> it in any way they want.
>>>>> Ok, this is good... and dangerous if anyone will add what they want
>>>>> without first agreeing/understanding on the purpose of this class. Do we
>>>>> all agree that it should stay clean and light by providing simple access
>>>>> for common operations rather than providing access to all the possible
>>>>> operations? I mean, it should provide a mechanism to perform tasks in the
>>>>> most common ways; for special (less frequent) tasks the calling script
>>>>> should use the features provided natively by the language and the
>>>>> standard API (delegator/dispatcher/etc...).
>>>> I agree. Let's keep the API limited to OFBiz-specific artifacts: entity
>>>> engine, service engine, logging, etc.
>>>>
>>>>>> As I mentioned previously, the GroovyBaseScript class can simply
>>>>>> delegate to the helper class:
>>>>> Yes, I will re-implement it following this design and let you know how it
>>>>> goes; but we will still need the Groovy service engine and Groovy event
>>>>> handlers... in order to keep the architecture clean should we start to
>>>>> think to them as extensions for the applications only? I mean that they
>>>>> could be part of the future release of "OFBiz Applications" and not part
>>>>> of the future release "OFBiz Framework". In this way the dependency and
>>>>> custom Groovy code will all be in the Applications (if they will be
>>>>> reimplemented in Groovy) and the framework will stay clean and light.
>>>> I was planning on having mini-lang's MethodContext extend ScriptHelper so
>>>> all scripting languages (including mini-lang) are running on the same code
>>>> base.
>>>>
>>>> I'm thinking all of this will tie up rather nicely once we have a reduced
>>>> framework. Scripting can be its own component that runs on top of the new
>>>> framework. Higher-level applications can then extend the scripting
>>>> component
>>>>
>>>>
>>>>> Jacopo
>>>>>
>>>>>> abstract class GroovyBaseScript extends Script implements ScriptHelper {
>>>>>> ...
>>>>>>
>>>>>> private final ScriptHelper helper;
>>>>>>
>>>>>> Map runService(String serviceName, Map inputMap) throws
>>>>>> ScriptException {
>>>>>> return helper.runService(serviceName, inputMap);
>>>>>> }
>>>>>>
>>>>>> Map makeValue(String entityName) throws ScriptException {
>>>>>> return helper.makeValue(entityName);
>>>>>> }
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> }
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 3/13/2012 5:49 AM, Jacopo Cappellato wrote:
>>>>>>> Adrian, thank you for your work.
>>>>>>>
>>>>>>> What I was writing was actually an extension to Groovy for making it
>>>>>>> OFBiz friendly; now we have a "reusable" (? by other languages) version
>>>>>>> of it... my guess is that you did it because you liked the ideas in it
>>>>>>> (and I appreciate it) and you thought it was useful for other languages
>>>>>>> as well; and you may be right about this even if, as I initially
>>>>>>> mentioned, I would have preferred to complete my work, or at least add
>>>>>>> a bit more to it, test the DSL with more poc and Minilang-->Groovy
>>>>>>> conversions before crystallizing it into an interface (one of the
>>>>>>> advantages in doing it in Groovy was that I could implement it without
>>>>>>> the need to build/restart the system)... now I have an interface and an
>>>>>>> implementation of it to take care of.
>>>>>>> But I don't want to complain (*) and I will review your work closely
>>>>>>> and see what I can do to use it properly in Groovy. This refactoring
>>>>>>> has introduced a series of limitations that I am determined to resolve
>>>>>>> and it will require some more study around Groovy and ideas to cope
>>>>>>> with them... I really want that, if we will ever adopt Groovy as our
>>>>>>> next language for the applications, it will look as perfect and simple
>>>>>>> and natural and integrated as possible: the natural language for OFBiz
>>>>>>> (like Minilang is now) rather than OFBiz implemented in Groovy.
>>>>>>>
>>>>>>> But before I proceed: what is the next step in your plan? What should
>>>>>>> go in the ScriptHelper interface? Am I allowed to enhance it based on
>>>>>>> my discoveries in my poc work (Minilang-->Groovy) or should I consider
>>>>>>> it a final interface that doesn't have to be modified? Should I ask
>>>>>>> before enhancing it? I don't want to hijack your work. And more
>>>>>>> importantly: can I assume that this helper class will stay light and
>>>>>>> simple? I really don't want to see it transformed into a huge class
>>>>>>> containing a big amount of methods from different APIs... the fact that
>>>>>>> all languages will potentially use it and may wish to extend it with
>>>>>>> util methods that make sense to them concerns me a little bit (for
>>>>>>> example, a language with weak support for Map handling may need utils
>>>>>>> methods to manage Maps that could be useless for Groovy).
>>>>>>>
>>>>>>> Kind regards and again thank you,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> (*) even if I find a bit annoying to see my work intercepted and
>>>>>>> re-routed while I was in the middle of it, I also appreciate the time
>>>>>>> and effort you spent on it and I really want to accept the fact that
>>>>>>> working in a community means that I have to blend and negotiate my own
>>>>>>> ideas and plans with the ones from others: sometimes it means that you
>>>>>>> get great help, sometimes it means that your own beautiful and perfect
>>>>>>> ideas are touched and rearranged to fit other's plans and other's
>>>>>>> beautiful ideas.
>>>>>>> I hope that the good attitude and flexibility I am trying to apply here
>>>>>>> will be also used by you and others when it will be time for you to
>>>>>>> accept other's proposals/changes
>>>>>>>
>>>>>>>
>>>>>>> On Mar 13, 2012, at 12:35 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Jacopo,
>>>>>>>>
>>>>>>>> I committed a generic, reusable version of this idea in rev 1299924.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 3/8/2012 6:02 PM, Jacopo Cappellato wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I have just completed my first pass in the implementation of a DSL
>>>>>>>>> (Domain Specific Language) for OFBiz that can be used by Groovy
>>>>>>>>> services to act like a modern version of Minilang.
>>>>>>>>>
>>>>>>>>> Please review my notes here:
>>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
>>>>>>>>>
>>>>>>>>> I look forward to your comments and feedback but please consider that
>>>>>>>>> 1) it is a work in progress, 2) I spent a lot of time and mental
>>>>>>>>> energy in the effort (reaching simplicity is really complex task!)...
>>>>>>>>> so please don't be too picky :-)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> PS: if you find it useful, I can commit the Groovy service mentioned
>>>>>>>>> in the page in Confluence
>
