Yes, I agree with the general strategy: OFBiz will be (or it is) flexible and
ready to be used with alternative tools; our effort as a community will be that
of "opening it up" and slimming it down instead of trying to include all the
possible alternative tools in our package; and the work that Adrian is doing to
enable OFBiz to JSR-223 is a good example in this direction because it provides
a flexible mechanism to plug in different scripting languages by just dropping
the (JSR-223 compliant) jar files of the language of preference in the
classpath; of course this will be a generic/basic support (i.e. the
generic/basic one provided by JSR-223) and if the user will want to implement a
library of custom objects to better structure the work in the new script then
it will be fine, but these classes will not find a way to OFBiz because they
will be custom and because they will be useless if you don't plan to use that
specific language.
In a similar way the community has chosen for the OFBiz applications a
scripting language of choice (currently Groovy) and this is the reason we have
some Groovy friendly classes (shipped ootb) that are used by our Groovy scripts.
Jacopo
On Mar 7, 2012, at 12:58 AM, Adrian Crum wrote:
> Fair enough. Users of other scripting languages can adapt the code to suit
> their language.
>
> -Adrian
>
> On 3/6/2012 11:49 PM, Scott Gray wrote:
>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
