Discussion: The Form Widget use-when attribute

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Discussion: The Form Widget use-when attribute

Adrian Crum-2

Now that the UEL supports logical operator substitution (http://docs.ofbiz.org/display/OFBTECH/Unified+Expression+Language+(JSR-245)+in+OFBiz#UnifiedExpressionLanguage%28JSR-245%29inOFBiz-OperatorSubstitutions) we have the ability to eliminate the clumsy XML escaping in the form widget use-when attribute. The problem is, the form widget evaluates the use-when attribute with BeanShell, not UEL.

I would like to change the form widget to use UEL in use-when expression evaluations. The use-when attribute must evaluate to a boolean, and UEL is perfect for that. Plus, expression evaluation using UEL should execute faster than BeanShell.

The potential downside is the chance there is a peculiar use-when expression that BeanShell can evaluate, but UEL can't. Those should be easy to find though.

What do you think?

-Adrian




     
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: The Form Widget use-when attribute

Ashish Vijaywargiya-5
+1

--
Ashish Vijaywargiya

Adrian Crum wrote:

> Now that the UEL supports logical operator substitution (http://docs.ofbiz.org/display/OFBTECH/Unified+Expression+Language+(JSR-245)+in+OFBiz#UnifiedExpressionLanguage%28JSR-245%29inOFBiz-OperatorSubstitutions) we have the ability to eliminate the clumsy XML escaping in the form widget use-when attribute. The problem is, the form widget evaluates the use-when attribute with BeanShell, not UEL.
>
> I would like to change the form widget to use UEL in use-when expression evaluations. The use-when attribute must evaluate to a boolean, and UEL is perfect for that. Plus, expression evaluation using UEL should execute faster than BeanShell.
>
> The potential downside is the chance there is a peculiar use-when expression that BeanShell can evaluate, but UEL can't. Those should be easy to find though.
>
> What do you think?
>
> -Adrian
>
>
>
>
>      
>  

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: The Form Widget use-when attribute

Scott Gray-2
In reply to this post by Adrian Crum-2
I don't mind either way, only one question, how does UEL handle  
undefined values e.g. (partyIdFrom == void) would we just do  
(partyIdFrom == null)?

It's also worth mentioning that we never needed to use XML escaping  
for beanshell it was the one that supported the method I suggested for  
UEL.

Regards
Scott

On 5/05/2009, at 4:33 PM, Adrian Crum wrote:

>
> Now that the UEL supports logical operator substitution (http://docs.ofbiz.org/display/OFBTECH/Unified+Expression+Language+(JSR-245)+in+OFBiz#UnifiedExpressionLanguage%28JSR-245%29inOFBiz-OperatorSubstitutions 
> ) we have the ability to eliminate the clumsy XML escaping in the  
> form widget use-when attribute. The problem is, the form widget  
> evaluates the use-when attribute with BeanShell, not UEL.
>
> I would like to change the form widget to use UEL in use-when  
> expression evaluations. The use-when attribute must evaluate to a  
> boolean, and UEL is perfect for that. Plus, expression evaluation  
> using UEL should execute faster than BeanShell.
>
> The potential downside is the chance there is a peculiar use-when  
> expression that BeanShell can evaluate, but UEL can't. Those should  
> be easy to find though.
>
> What do you think?
>
> -Adrian
>
>
>
>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: The Form Widget use-when attribute

Adrian Crum-2

The UEL throws an exception if an undefined value is used in an expression. I added an extension that allows you to specify a default value if one isn't found. So, it would look like this: ${partyIdfrom$string == ''}.

I tried to use the operator overload in BeanShell, but it threw a parse exception. I don't know what that is about.

-Adrian


--- On Mon, 5/4/09, Scott Gray <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Re: Discussion: The Form Widget use-when attribute
> To: [hidden email]
> Date: Monday, May 4, 2009, 9:51 PM
> I don't mind either way, only one question, how does UEL
> handle undefined values e.g. (partyIdFrom == void) would we
> just do (partyIdFrom == null)?
>
> It's also worth mentioning that we never needed to use
> XML escaping for beanshell it was the one that supported the
> method I suggested for UEL.
>
> Regards
> Scott
>
> On 5/05/2009, at 4:33 PM, Adrian Crum wrote:
>
> >
> > Now that the UEL supports logical operator
> substitution
> (http://docs.ofbiz.org/display/OFBTECH/Unified+Expression+Language+(JSR-245)+in+OFBiz#UnifiedExpressionLanguage%28JSR-245%29inOFBiz-OperatorSubstitutions)
> we have the ability to eliminate the clumsy XML escaping in
> the form widget use-when attribute. The problem is, the form
> widget evaluates the use-when attribute with BeanShell, not
> UEL.
> >
> > I would like to change the form widget to use UEL in
> use-when expression evaluations. The use-when attribute must
> evaluate to a boolean, and UEL is perfect for that. Plus,
> expression evaluation using UEL should execute faster than
> BeanShell.
> >
> > The potential downside is the chance there is a
> peculiar use-when expression that BeanShell can evaluate,
> but UEL can't. Those should be easy to find though.
> >
> > What do you think?
> >
> > -Adrian
> >
> >
> >
> >
> >


     
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: The Form Widget use-when attribute

Scott Gray-2
The more I think about it the less I like void values anyway, it just  
increases the likely hood of unintended behavior.  I say we go for it  
and let the exceptions be thrown and then fix them by actually  
initializing the values.

Regards
Scott

On 5/05/2009, at 5:53 PM, Adrian Crum wrote:

>
> The UEL throws an exception if an undefined value is used in an  
> expression. I added an extension that allows you to specify a  
> default value if one isn't found. So, it would look like this: $
> {partyIdfrom$string == ''}.
>
> I tried to use the operator overload in BeanShell, but it threw a  
> parse exception. I don't know what that is about.
>
> -Adrian
>
>
> --- On Mon, 5/4/09, Scott Gray <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Re: Discussion: The Form Widget use-when attribute
>> To: [hidden email]
>> Date: Monday, May 4, 2009, 9:51 PM
>> I don't mind either way, only one question, how does UEL
>> handle undefined values e.g. (partyIdFrom == void) would we
>> just do (partyIdFrom == null)?
>>
>> It's also worth mentioning that we never needed to use
>> XML escaping for beanshell it was the one that supported the
>> method I suggested for UEL.
>>
>> Regards
>> Scott
>>
>> On 5/05/2009, at 4:33 PM, Adrian Crum wrote:
>>
>>>
>>> Now that the UEL supports logical operator
>> substitution
>> (http://docs.ofbiz.org/display/OFBTECH/Unified+Expression+Language+(JSR-245)+in+OFBiz#UnifiedExpressionLanguage%28JSR-245%29inOFBiz-OperatorSubstitutions 
>> )
>> we have the ability to eliminate the clumsy XML escaping in
>> the form widget use-when attribute. The problem is, the form
>> widget evaluates the use-when attribute with BeanShell, not
>> UEL.
>>>
>>> I would like to change the form widget to use UEL in
>> use-when expression evaluations. The use-when attribute must
>> evaluate to a boolean, and UEL is perfect for that. Plus,
>> expression evaluation using UEL should execute faster than
>> BeanShell.
>>>
>>> The potential downside is the chance there is a
>> peculiar use-when expression that BeanShell can evaluate,
>> but UEL can't. Those should be easy to find though.
>>>
>>> What do you think?
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>>>
>
>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: The Form Widget use-when attribute

Adrian Crum
The BeanShell operator overload works after all. I don't know why I was
having a problem with it earlier.

Now that it appears to be working correctly, I have decided against
making this change.

-Adrian

Scott Gray wrote:

> The more I think about it the less I like void values anyway, it just
> increases the likely hood of unintended behavior.  I say we go for it
> and let the exceptions be thrown and then fix them by actually
> initializing the values.
>
> Regards
> Scott
>
> On 5/05/2009, at 5:53 PM, Adrian Crum wrote:
>
>>
>> The UEL throws an exception if an undefined value is used in an
>> expression. I added an extension that allows you to specify a default
>> value if one isn't found. So, it would look like this:
>> ${partyIdfrom$string == ''}.
>>
>> I tried to use the operator overload in BeanShell, but it threw a
>> parse exception. I don't know what that is about.
>>
>> -Adrian
>>
>>
>> --- On Mon, 5/4/09, Scott Gray <[hidden email]> wrote:
>>
>>> From: Scott Gray <[hidden email]>
>>> Subject: Re: Discussion: The Form Widget use-when attribute
>>> To: [hidden email]
>>> Date: Monday, May 4, 2009, 9:51 PM
>>> I don't mind either way, only one question, how does UEL
>>> handle undefined values e.g. (partyIdFrom == void) would we
>>> just do (partyIdFrom == null)?
>>>
>>> It's also worth mentioning that we never needed to use
>>> XML escaping for beanshell it was the one that supported the
>>> method I suggested for UEL.
>>>
>>> Regards
>>> Scott
>>>
>>> On 5/05/2009, at 4:33 PM, Adrian Crum wrote:
>>>
>>>>
>>>> Now that the UEL supports logical operator
>>> substitution
>>> (http://docs.ofbiz.org/display/OFBTECH/Unified+Expression+Language+(JSR-245)+in+OFBiz#UnifiedExpressionLanguage%28JSR-245%29inOFBiz-OperatorSubstitutions)
>>>
>>> we have the ability to eliminate the clumsy XML escaping in
>>> the form widget use-when attribute. The problem is, the form
>>> widget evaluates the use-when attribute with BeanShell, not
>>> UEL.
>>>>
>>>> I would like to change the form widget to use UEL in
>>> use-when expression evaluations. The use-when attribute must
>>> evaluate to a boolean, and UEL is perfect for that. Plus,
>>> expression evaluation using UEL should execute faster than
>>> BeanShell.
>>>>
>>>> The potential downside is the chance there is a
>>> peculiar use-when expression that BeanShell can evaluate,
>>> but UEL can't. Those should be easy to find though.
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>