[jira] Created: (OFBIZ-2831) Allow fields to be set directly from a bsh scriptlet

[Nicolas Malin (Jira)]

Allow fields to be set directly from a bsh scriptlet
----------------------------------------------------

                 Key: OFBIZ-2831
                 URL: https://issues.apache.org/jira/browse/OFBIZ-2831
             Project: OFBiz
          Issue Type: Improvement
          Components: framework
    Affects Versions: SVN trunk
            Reporter: Bob Morley


We have made an improvement to the SetField class in Screen, Field, Menu, and Tree.  You used to do something like this --

<set field="name" value="${bsh:org.ofbiz.Foo.Bar()}" type="Integer" />

A disadvantage of this technique is that the value is handled by a FlexibleStringExpander (which will always return a string).  Implementation of this expander will notice the "bsh" and parse out the scriptlet, interpret and get an Object back, then convert the Object to a String.  The caller (say ModelScreenAction) will then take this Object and do a simple type conversion (on ObjectType) to the desired type for the user.  This works fine if the function can return something that can convert to a String and then back to the desired type.  When the return result can not (say a List) then you are pooched.

My proposed solution is make the grammar more clear in the xml for the Model Action by explicitly stating that we will be providing a bsh scriptlet.  Moreover, since we directly call for the Object we can directly convert to the desired object which will work properly for non-string serializable objects like lists and maps.

<set field="name" from-bsh="org.ofbiz.Foo.Bar()" type="Integer" />

The implementation does treat the scriptlet as a FlexibleString so it will convert inside for labels resolution and the like.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Nicolas Malin (Jira)]

     [ https://issues.apache.org/jira/browse/OFBIZ-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bob Morley updated OFBIZ-2831:
------------------------------

    Attachment: OFBIZ-2831.patch

Contains change to Model Action classes - Screen, Form, Tree, Menu along with xsd to allow "from-bsh".

*NOTE* the tree xsd was not updated because (although the code in the ModalTreeAction supports it) set field is not currently part of the grammar.

*NOTE 2* also contains logic to verify that only one of the "attributes that can set value" are specified -- either value, from-field, or from-bsh.

*NOTE 3* you can quickly test this out; in our workspace we are using this in our hot-deploy screen but I did not have a spot in Ofbiz where it made sense to plug this in.

> Allow fields to be set directly from a bsh scriptlet
> ----------------------------------------------------
>
>                 Key: OFBIZ-2831
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2831
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Bob Morley
>         Attachments: OFBIZ-2831.patch
>
>
> We have made an improvement to the SetField class in Screen, Field, Menu, and Tree.  You used to do something like this --
> <set field="name" value="${bsh:org.ofbiz.Foo.Bar()}" type="Integer" />
> A disadvantage of this technique is that the value is handled by a FlexibleStringExpander (which will always return a string).  Implementation of this expander will notice the "bsh" and parse out the scriptlet, interpret and get an Object back, then convert the Object to a String.  The caller (say ModelScreenAction) will then take this Object and do a simple type conversion (on ObjectType) to the desired type for the user.  This works fine if the function can return something that can convert to a String and then back to the desired type.  When the return result can not (say a List) then you are pooched.
> My proposed solution is make the grammar more clear in the xml for the Model Action by explicitly stating that we will be providing a bsh scriptlet.  Moreover, since we directly call for the Object we can directly convert to the desired object which will work properly for non-string serializable objects like lists and maps.
> <set field="name" from-bsh="org.ofbiz.Foo.Bar()" type="Integer" />
> The implementation does treat the scriptlet as a FlexibleString so it will convert inside for labels resolution and the like.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743216#action_12743216 ]

Jacques Le Roux commented on OFBIZ-2831:
----------------------------------------

Hi Bob,

Quick answer : why not using [UEL|http://docs.ofbiz.org/x/Hhk] ?

> Allow fields to be set directly from a bsh scriptlet
> ----------------------------------------------------
>
>                 Key: OFBIZ-2831
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2831
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Bob Morley
>         Attachments: OFBIZ-2831.patch
>
>
> We have made an improvement to the SetField class in Screen, Field, Menu, and Tree.  You used to do something like this --
> <set field="name" value="${bsh:org.ofbiz.Foo.Bar()}" type="Integer" />
> A disadvantage of this technique is that the value is handled by a FlexibleStringExpander (which will always return a string).  Implementation of this expander will notice the "bsh" and parse out the scriptlet, interpret and get an Object back, then convert the Object to a String.  The caller (say ModelScreenAction) will then take this Object and do a simple type conversion (on ObjectType) to the desired type for the user.  This works fine if the function can return something that can convert to a String and then back to the desired type.  When the return result can not (say a List) then you are pooched.
> My proposed solution is make the grammar more clear in the xml for the Model Action by explicitly stating that we will be providing a bsh scriptlet.  Moreover, since we directly call for the Object we can directly convert to the desired object which will work properly for non-string serializable objects like lists and maps.
> <set field="name" from-bsh="org.ofbiz.Foo.Bar()" type="Integer" />
> The implementation does treat the scriptlet as a FlexibleString so it will convert inside for labels resolution and the like.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743223#action_12743223 ]

Adrian Crum commented on OFBIZ-2831:
------------------------------------

Have you tried using from-field= instead of value=? The from-field attribute always returns an object.

I like the proposal. One thing I would prefer though, instead of

{code}<set field="name" from-bsh="org.ofbiz.Foo.Bar()" type="Integer" />{code}

make it

{code}<set field="name" from-scriptlet="org.ofbiz.Foo.Bar()" type="Integer" />{code}

that makes it more generic.

Also, as Jacques mentioned, you can leverage UEL. If one of the existing built-in functions doesn't meet your need, then you can always add your own. The UelFunctions.java class is fairly well documented, and it has been set up so it is extensible.

> Allow fields to be set directly from a bsh scriptlet
> ----------------------------------------------------
>
>                 Key: OFBIZ-2831
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2831
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Bob Morley
>         Attachments: OFBIZ-2831.patch
>
>
> We have made an improvement to the SetField class in Screen, Field, Menu, and Tree.  You used to do something like this --
> <set field="name" value="${bsh:org.ofbiz.Foo.Bar()}" type="Integer" />
> A disadvantage of this technique is that the value is handled by a FlexibleStringExpander (which will always return a string).  Implementation of this expander will notice the "bsh" and parse out the scriptlet, interpret and get an Object back, then convert the Object to a String.  The caller (say ModelScreenAction) will then take this Object and do a simple type conversion (on ObjectType) to the desired type for the user.  This works fine if the function can return something that can convert to a String and then back to the desired type.  When the return result can not (say a List) then you are pooched.
> My proposed solution is make the grammar more clear in the xml for the Model Action by explicitly stating that we will be providing a bsh scriptlet.  Moreover, since we directly call for the Object we can directly convert to the desired object which will work properly for non-string serializable objects like lists and maps.
> <set field="name" from-bsh="org.ofbiz.Foo.Bar()" type="Integer" />
> The implementation does treat the scriptlet as a FlexibleString so it will convert inside for labels resolution and the like.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743239#action_12743239 ]

Bob Morley commented on OFBIZ-2831:
-----------------------------------

Yes what I did not realize was that using UEL I could extend it's set of functions.  What we often do is decide to create presentation helper methods in Java (instead of groovy).  So it is reasonable frequent for us to have business (and presentment) specific methods to invoke.  

For something that is screen/business specific extending the Uel function set seems to be fairly heavy handed.  Having said that it is very cool that you can do that, I did not know that was possible and I would certainly do that for any functions that are global in nature.

Unless we think that Uel is the absolute best approach for these tasks, I would like to get this change in and I can certainly change it to use a more generic grammar (like from-scriptlet).

> Allow fields to be set directly from a bsh scriptlet
> ----------------------------------------------------
>
>                 Key: OFBIZ-2831
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2831
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Bob Morley
>         Attachments: OFBIZ-2831.patch
>
>
> We have made an improvement to the SetField class in Screen, Field, Menu, and Tree.  You used to do something like this --
> <set field="name" value="${bsh:org.ofbiz.Foo.Bar()}" type="Integer" />
> A disadvantage of this technique is that the value is handled by a FlexibleStringExpander (which will always return a string).  Implementation of this expander will notice the "bsh" and parse out the scriptlet, interpret and get an Object back, then convert the Object to a String.  The caller (say ModelScreenAction) will then take this Object and do a simple type conversion (on ObjectType) to the desired type for the user.  This works fine if the function can return something that can convert to a String and then back to the desired type.  When the return result can not (say a List) then you are pooched.
> My proposed solution is make the grammar more clear in the xml for the Model Action by explicitly stating that we will be providing a bsh scriptlet.  Moreover, since we directly call for the Object we can directly convert to the desired object which will work properly for non-string serializable objects like lists and maps.
> <set field="name" from-bsh="org.ofbiz.Foo.Bar()" type="Integer" />
> The implementation does treat the scriptlet as a FlexibleString so it will convert inside for labels resolution and the like.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Nicolas Malin (Jira)]

     [ https://issues.apache.org/jira/browse/OFBIZ-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bob Morley updated OFBIZ-2831:
------------------------------

    Attachment: OFBIZ-2831.patch

Modification from "from-bsh" to "from-scriptlet" and related changes in the code (member variable is fromScriptletExdr, retrieval method is getFromScriptletValue).

> Allow fields to be set directly from a bsh scriptlet
> ----------------------------------------------------
>
>                 Key: OFBIZ-2831
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2831
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Bob Morley
>         Attachments: OFBIZ-2831.patch, OFBIZ-2831.patch
>
>
> We have made an improvement to the SetField class in Screen, Field, Menu, and Tree.  You used to do something like this --
> <set field="name" value="${bsh:org.ofbiz.Foo.Bar()}" type="Integer" />
> A disadvantage of this technique is that the value is handled by a FlexibleStringExpander (which will always return a string).  Implementation of this expander will notice the "bsh" and parse out the scriptlet, interpret and get an Object back, then convert the Object to a String.  The caller (say ModelScreenAction) will then take this Object and do a simple type conversion (on ObjectType) to the desired type for the user.  This works fine if the function can return something that can convert to a String and then back to the desired type.  When the return result can not (say a List) then you are pooched.
> My proposed solution is make the grammar more clear in the xml for the Model Action by explicitly stating that we will be providing a bsh scriptlet.  Moreover, since we directly call for the Object we can directly convert to the desired object which will work properly for non-string serializable objects like lists and maps.
> <set field="name" from-bsh="org.ofbiz.Foo.Bar()" type="Integer" />
> The implementation does treat the scriptlet as a FlexibleString so it will convert inside for labels resolution and the like.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.