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