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