Home » Archived » Visual Editor (VE) » Expressions too complicated to be evaluated
| Expressions too complicated to be evaluated [message #13922] |
Thu, 08 January 2004 08:05  |
Eclipse User |
|
|
|
Originally posted by: migueli72.yahoo.com
Hello everyone,
I'm migrating VisualCafe apps to Visual Editor.
After finding some workarounds in order to make the apps work in the new
environment, I have found one serious problem that I would like to discuss
with you:
I have a component (say myButton) that has an action (setAction), but with
two parameters:
myButton.setAction(this,"myText");
myButton is an object that inherits from JButton and "this" is a reference
to the Component that it belongs to.
Unfourtunately, Visual Editor doesn
|
|
|
| Re: Expressions too complicated to be evaluated [message #13931 is a reply to message #13922] |
Thu, 08 January 2004 10:13  |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
Miguel Tato wrote:
> Hello everyone,
>
> I'm migrating VisualCafe apps to Visual Editor.
> After finding some workarounds in order to make the apps work in the new
> environment, I have found one serious problem that I would like to discuss
> with you:
>
> I have a component (say myButton) that has an action (setAction), but with
> two parameters:
>
> myButton.setAction(this,"myText");
>
> myButton is an object that inherits from JButton and "this" is a reference
> to the Component that it belongs to.
>
> Unfourtunately, Visual Editor doesn´t like this, so it says:
> ..."this","myText" is too complicated to be evaluated.
>
> I have found that there is a method "createBeanProxy" from the class
> REMStandardBeanProxyFactory) that throws a few exceptions like the one I
> get.
>
> How should I proceed? disable this, make VE to understand when I pass the
> reference this?, and how do you think should be done?
>
> Thanks in advance,
>
> Miguel Tato
>
>
>
>
This is interesting. Action is a property of AbstractButton. But the
signature of the setAction property of AbstractButton has a single
argument; VE should not attempt to parse the 2 argument setAction method.
Do you use BeanInfo to override properties on this bean?
If you post a sample (class) code that produces this problem, it will
make it easier to get to the button of it.
|
|
|
| Re: Expressions too complicated to be evaluated [message #13942 is a reply to message #13922] |
Mon, 12 January 2004 06:25 |
| Eclipse User |
|
|
|
Hi Miguel,
> I have a component (say myButton) that has an action (setAction), but with
> two parameters:
> myButton.setAction(this,"myText");
> Unfourtunately, Visual Editor doesn´t like this, so it says:
> ..."this","myText" is too complicated to be evaluated.
As Gili mentions, there is a potential problem because we should never have
evaluated this expression as it has two arguments. If you post a complete code
sample (i.e.with your Button subclass source as well as the visual class using
it) then we can hopefully debug it here and figure out why this happens.
However - here's a bit of background on why the message is being shown in the
first place.
What we do when the .java file is opened is analyze the method calls to find
the ones that are set methods of Bean properties, and these themselves as per
the spec can only be single argument. We then create an object model from
this, and the argument string is then parsed and evaluated into an object, e.g.
myButton.setBackground(java.awt.Color.red);
so in this case we take the string "java.awt.Color.red" and parse it into an
expression that we then evaluate into the actual red object.
The code that evaluates the expression figures out there's a field access on
the class java.awt.Color and goes and uses reflection to locate the Color class
and get the field value. There is "System.eval(String codeSnippit)" API in
Java, so we have to do this grunt work ourselves. Some expressions can get
pretty complex with nested expressions and arrays and stuff (such as those
created by Swing borders for example) but for most experessions we handle them
OK. However if the expression contains fields that are scoped to the class
itself, such as
myButton.setSomething(Class.callMethod(this));
or
myButton.setSomething(aField.callMethod());
then we have problems because we have no "this" object or "aField" to evaluate
against. This is one of the main items we are working on however as it's
important for non JavaBeans based GUI toolkits, and also other ad-hoc
expressions that people write that aren't standard single argument setters that
it'd be nice if we evaluated so they were previewed in the GUI.
Best regards,
Joe Winchesterb
|
|
| |
| Re: Expressions too complicated to be evaluated [message #14391 is a reply to message #14365] |
Mon, 12 January 2004 19:38 |
| Eclipse User |
|
|
|
Hi Miguel,
Thanks for the code - I understand what's going on now.
You have a class MyButton where you have a property called methodPostValidation
that is typed to java.lang.String
There is a getMethod that returns a String, and a set method that accepts it.
This makes it a valid JavaBeans property.
In the BeanInfo class associate a property editor with this, and you have a
specific property editor. The property editor for this has the following method
public String getJavaInitializationString() {
return "this,\"" + (String) getValue() + "\"";
}
When you edit the property value on MyButton the property editor is asked by the
Visual Editor for the argument to the set method. You return a String that has
a comma in it
this,"Fred"
(assuming I typed the value "Fred" in the property editor)
Normally this would cause a straightforward compilation error, however you also
have a two argument method with the same name on MyButton
public void setMethodPostValidation(java.awt.Component father, String pmMethod)
The compiler sees this method so your code is OK Java wise.
The problem is that the the getJavaInitializationString() method from the
property editor must return a single expression that when evaluated will return
the property value. This must be a String because the property is typed to
String. Page 94 of the JavaBeans specification states:
"This method is intended for use when generating Java code to set the value of
the property. It should return a fragment of Java code that can be used to
initialize a variable with the current property value"
So if the property editor returns a String from its getValue() metohd (which
yours does because it inherits from PropertyEditorSupport) then this is the
value. It's created by the property editor in isolation from the object being
edited, i.e. it can't rely on anything about object that has the MyButton
instance. The getJavaInitializationString() is placed in the code so that the
getValue() object (the String in your case) can be archived in the source code.
To do what you are trying however you could just change the implementation of
your single argument method so
public void setMethodPostValidation(String pmMethod){
setMethodPostValidation(this,pmMethod)
}
Return the String from the property editor's getJavaInitializationString()
(without any , so the compiler knows its a call to the single arg method) and
you should be OK
Best regards,
Joe
|
|
| |
| Re: Expressions too complicated to be evaluated [message #577110 is a reply to message #13922] |
Thu, 08 January 2004 10:13 |
| Eclipse User |
|
|
|
Miguel Tato wrote:
> Hello everyone,
>
> I'm migrating VisualCafe apps to Visual Editor.
> After finding some workarounds in order to make the apps work in the new
> environment, I have found one serious problem that I would like to discuss
> with you:
>
> I have a component (say myButton) that has an action (setAction), but with
> two parameters:
>
> myButton.setAction(this,"myText");
>
> myButton is an object that inherits from JButton and "this" is a reference
> to the Component that it belongs to.
>
> Unfourtunately, Visual Editor doesn´t like this, so it says:
> ..."this","myText" is too complicated to be evaluated.
>
> I have found that there is a method "createBeanProxy" from the class
> REMStandardBeanProxyFactory) that throws a few exceptions like the one I
> get.
>
> How should I proceed? disable this, make VE to understand when I pass the
> reference this?, and how do you think should be done?
>
> Thanks in advance,
>
> Miguel Tato
>
>
>
>
This is interesting. Action is a property of AbstractButton. But the
signature of the setAction property of AbstractButton has a single
argument; VE should not attempt to parse the 2 argument setAction method.
Do you use BeanInfo to override properties on this bean?
If you post a sample (class) code that produces this problem, it will
make it easier to get to the button of it.
|
|
|
| Re: Expressions too complicated to be evaluated [message #577251 is a reply to message #13922] |
Mon, 12 January 2004 06:25 |
| Eclipse User |
|
|
|
Hi Miguel,
> I have a component (say myButton) that has an action (setAction), but with
> two parameters:
> myButton.setAction(this,"myText");
> Unfourtunately, Visual Editor doesn´t like this, so it says:
> ..."this","myText" is too complicated to be evaluated.
As Gili mentions, there is a potential problem because we should never have
evaluated this expression as it has two arguments. If you post a complete code
sample (i.e.with your Button subclass source as well as the visual class using
it) then we can hopefully debug it here and figure out why this happens.
However - here's a bit of background on why the message is being shown in the
first place.
What we do when the .java file is opened is analyze the method calls to find
the ones that are set methods of Bean properties, and these themselves as per
the spec can only be single argument. We then create an object model from
this, and the argument string is then parsed and evaluated into an object, e.g.
myButton.setBackground(java.awt.Color.red);
so in this case we take the string "java.awt.Color.red" and parse it into an
expression that we then evaluate into the actual red object.
The code that evaluates the expression figures out there's a field access on
the class java.awt.Color and goes and uses reflection to locate the Color class
and get the field value. There is "System.eval(String codeSnippit)" API in
Java, so we have to do this grunt work ourselves. Some expressions can get
pretty complex with nested expressions and arrays and stuff (such as those
created by Swing borders for example) but for most experessions we handle them
OK. However if the expression contains fields that are scoped to the class
itself, such as
myButton.setSomething(Class.callMethod(this));
or
myButton.setSomething(aField.callMethod());
then we have problems because we have no "this" object or "aField" to evaluate
against. This is one of the main items we are working on however as it's
important for non JavaBeans based GUI toolkits, and also other ad-hoc
expressions that people write that aren't standard single argument setters that
it'd be nice if we evaluated so they were previewed in the GUI.
Best regards,
Joe Winchesterb
|
|
|
| Re: Expressions too complicated to be evaluated [message #577334 is a reply to message #13942] |
Mon, 12 January 2004 11:39 |
| Eclipse User |
|
|
|
Hi Joe,
Thanks for your reply.
From the Wizzo Widgets example, I have modified the code in order to include
the MyButton example.
Within the zip file attached you can find the proyecto1 project, which
contains the following:
MyButton.java - a simple button that inherits from JButton
MyButtonBeanInfo.java - the corresponding beanInfo
MyButtonPropertyEditor.java - the class that adds the this reference to the
method
plugin.xml -
wizzopallete.xmi
wizzowidgets.jar
wizzowidgets_dt.jar
Best Regards,
Miguel Tato
"Joe Winchester" <winchest@uk.ibm.com> escribi
|
|
|
| Re: Expressions too complicated to be evaluated [message #577353 is a reply to message #14365] |
Mon, 12 January 2004 19:38 |
| Eclipse User |
|
|
|
Hi Miguel,
Thanks for the code - I understand what's going on now.
You have a class MyButton where you have a property called methodPostValidation
that is typed to java.lang.String
There is a getMethod that returns a String, and a set method that accepts it.
This makes it a valid JavaBeans property.
In the BeanInfo class associate a property editor with this, and you have a
specific property editor. The property editor for this has the following method
public String getJavaInitializationString() {
return "this,\"" + (String) getValue() + "\"";
}
When you edit the property value on MyButton the property editor is asked by the
Visual Editor for the argument to the set method. You return a String that has
a comma in it
this,"Fred"
(assuming I typed the value "Fred" in the property editor)
Normally this would cause a straightforward compilation error, however you also
have a two argument method with the same name on MyButton
public void setMethodPostValidation(java.awt.Component father, String pmMethod)
The compiler sees this method so your code is OK Java wise.
The problem is that the the getJavaInitializationString() method from the
property editor must return a single expression that when evaluated will return
the property value. This must be a String because the property is typed to
String. Page 94 of the JavaBeans specification states:
"This method is intended for use when generating Java code to set the value of
the property. It should return a fragment of Java code that can be used to
initialize a variable with the current property value"
So if the property editor returns a String from its getValue() metohd (which
yours does because it inherits from PropertyEditorSupport) then this is the
value. It's created by the property editor in isolation from the object being
edited, i.e. it can't rely on anything about object that has the MyButton
instance. The getJavaInitializationString() is placed in the code so that the
getValue() object (the String in your case) can be archived in the source code.
To do what you are trying however you could just change the implementation of
your single argument method so
public void setMethodPostValidation(String pmMethod){
setMethodPostValidation(this,pmMethod)
}
Return the String from the property editor's getJavaInitializationString()
(without any , so the compiler knows its a call to the single arg method) and
you should be OK
Best regards,
Joe
|
|
| |
Goto Forum:
Current Time: Fri May 09 13:57:16 EDT 2025
Powered by FUDForum. Page generated in 0.51042 seconds |
Home