The EntityConditionBuilder class I wrote a while back is a good example of a
groovy specific utility class, it takes advantage of groovy's language syntax
features and couldn't be used in any other scripting language (well, not in the
intended manner anyway).
A possible solution could be to have some sort of configuration file per
scripting language where classes to be instantiated could be assigned to
specific context variables:
conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
Or maybe xml if we needed greater configuration control such as passing
specific context variables into the utility class's constructor, perhaps
similar in structure to minilang's call-class-method tag.
Regards
Scott
On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
> This could work but I was thinking to something more like having some "core"
> packages (like entity and service) always imported in groovy
> scripts/services; or having the "delegator" and "dispatcher" objects properly
> casted to their interfaces (to take advantage of IDE autocompletion
> features); etc...
> But I don't have a clear list at the moment so please do not consider my
> notes a blocker.
> I am working at a POC for a "best practice" Groovy service implementation and
> this should end up with a "wish list" of features I would like to have. Then
> we can discuss the best way to achieve this.
>
> Jacopo
>
> On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
>
>> If you don't mind, I would like to get all of the issues resolved during the
>> design phase.
>>
>> I will wait for the private email to understand what you mean by a "secure"
>> scripting package.
>>
>> What I was suggesting is a script utility object that can be put in the
>> context so that all scripting languages can use it. Whatever methods you
>> have in mind could be implemented in a generic way and reused. Personally, I
>> would like to use something like:
>>
>> // Groovy, JavaScript
>> partyValue = script.entityOne("Party");
>> if (partyValue)...
>>
>> In other words, have an object in the context that gives us the convenience
>> of mini-language.
>>
>> -Adrian
>>
>> On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
>>> On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
>>>
>>>> It seems to me if there is a security issue using Groovy, then there would
>>>> be an issue using any scripting language.
>>> Yes, but what we would bundle ootb would be a secured packaged ready to run
>>> Groovy scripts in a "secure" way and already packaged with hundreds of
>>> scripts.
>>> If the user will add a new jar to support a different script (and the user
>>> will also have to implement the custom scripts) then this will be less
>>> secure but there isn't much we could do as we delegate to JSR-223 the
>>> implementation of security.
>>>
>>>> Why can't we put the "friendly methods" in the context, so all scripting
>>>> languages can use them?
>>>>
>>> I am not sure I understand what you are proposing (the method would be
>>> language specific) but for now we can postpone this discussion at when (if
>>> it will ever happen) we will discuss about this approach.
>>>
>>> Jacopo
>>>
>>>> -Adrian
>>>>
>>>> On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
>>>>> On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
>>>>>
>>>>>> The code changes tested fine.
>>>>>>
>>>>>> I noticed in your code comments that Groovy should be handled
>>>>>> independently from other scripting languages. Why do you think that?
>>>>> First of all, I apologize for having added my personal opinion to those
>>>>> comments :-) but I thought that in this way it was easier to exchange
>>>>> design ideas; the comments can actually be removed.
>>>>>
>>>>> The reasons I think we could treat Groovy in a special way (but I don't
>>>>> have a strong opinion on this) are:
>>>>>
>>>>> * ootb OFBiz will still be packaged with Groovy jars (they are required
>>>>> by all the existing scripts and by some other code like the
>>>>> implementation of "Groovy service engine" and "Groovy event handler") and
>>>>> so the dependency on Groovy will still be there even if we run it with
>>>>> JSR-223
>>>>> * the code to run Groovy in the special way is now all contained in the
>>>>> ScriptUtil class and there are actually a few lines of code to maintain
>>>>> for it
>>>>> * keeping a custom way for Groovy has two main advantages that are not
>>>>> currently used but I would like to consider in the short term (and I
>>>>> don't think they are supported thru JSR-223... but I am not sure):
>>>>> ** security: I would like to restrict the JVM security settings for
>>>>> dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this
>>>>> area that I will address in a separate email soon; in this way we will
>>>>> "secure" the ootb system (packaged with several groovy scripts and the
>>>>> groovy jars) but of course if the user will add to it jars files for a
>>>>> new scripting language (executed using JSR-223) then the security issue
>>>>> will still be there, but at least the user will know about it
>>>>> ** I would like to inject some OFBiz friendly methods to all Groovy
>>>>> scripts, so that they can be used by Groovy scripts to run services, use
>>>>> the delegator etc...
>>>>>
>>>>> We should also consider the impact on performance, even if the best way
>>>>> to go is probably to run some performance tests on the system running
>>>>> Groovy with current code and with the system running Groovy using a
>>>>> custom method and then compare the results.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
>>>>>>> My changes are in commit 1296762
>>>>>>>
>>>>>>> Help with reviews and tests will be very much appreciated.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
>>>>>>>
>>>>>>>> On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> As far as I know, most scripting engines have some sort of embedded
>>>>>>>>> cache. The problem will be that we can't clear the embedded cache
>>>>>>>>> like we can with our own cache implementation. I don't see that as a
>>>>>>>>> show stopper - it's mostly inconvenient.
>>>>>>>>>
>>>>>>>>> I can help out with the conversion. I don't think the task will be
>>>>>>>>> that hard.
>>>>>>>> Adrian, FYI I am enhancing some of the existing framework code that
>>>>>>>> uses the GroovyUtil class to simplify this task.
>>>>>>>> I will commit my code changes today.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
