I'm not sure I follow what you're saying. I'm sure a java based script helper
class in the context could be useful but I don't think it should preclude the
ability to include classes in the context that assist with language specific
features.
I don't really see how giving users the ability to write their own helper
classes and make them available via configuration (similar to Freemarker
Transforms) would be anything other than a huge bonus, regardless of your
scripting language of choice. I would argue that attempting to constrain users
to a single generic set of methods that we have deemed useful would not be what
most people would consider accommodating.
Rather than try to consider what everyone might want, I would rather see us
give users the power to do whatever they need.
Regards
Scott
On 7/03/2012, at 12:33 PM, Adrian Crum wrote:
> The EntityConditionBuilder class is a good example of how we can make
> scripting more convenient.
>
> Different scripting languages will have varying support for Java classes. It
> was my hope that we could come up with a Java-based script helper class that
> can be used by a variety of scripting languages that can access Java objects.
>
> I understand that there is an interest in Groovy in this community, but other
> communities might prefer a different language. For example, Jython and Ruby
> have sizable communities.
>
> My motivation in in implementing JSR-223 is the same as my motivation to
> implement internationalization/globalization years ago - to open up the
> project to more users.
>
> So, let's try to keep the big picture in mind. If we come up with a scripting
> convenience, let's try to accommodate the most users with it.
>
> -Adrian
>
>
> On 3/6/2012 10:23 AM, Scott Gray wrote:
>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
