Home » Archived » Visual Editor (VE) » Beans.isDesignTime() bug?
| Beans.isDesignTime() bug? [message #47313] |
Tue, 06 July 2004 05:52  |
Eclipse User |
|
|
|
Originally posted by: mb.thomas-daily.de
I am using:
VE S20040628 (and the required/recommended versions of Eclipse, EMF,
GEF) on Windows XP.
Today I discovered this strange bevaviour:
The first version of that method paints the background red,
the second does not so -- although they should be equivalent:
/*
* works as expected in design time
*/
private JTextField getJTextField ( )
{
if (jTextField == null)
{
jTextField = new JTextField ( );
jTextField.setText ("blah");
if (java.beans.Beans.isDesignTime ( ))
{
}
else
{
jTextField.setBackground (java.awt.Color.RED);
}
}
return jTextField;
}
/*
* does not work as expected in design time
*/
private JTextField getJTextField ( )
{
if (jTextField == null)
{
jTextField = new JTextField ( );
jTextField.setText ("blah");
if (!java.beans.Beans.isDesignTime ( ))
{
jTextField.setBackground (java.awt.Color.RED);
}
}
return jTextField;
}
Is this a bug? I can't find a bugzilla entry.
|
|
| | |
| Re: false equals true ?! [message #47774 is a reply to message #47490] |
Tue, 06 July 2004 10:40  |
| Eclipse User |
|
|
|
Hi Marcus,
I agree that once you look at the piece of code, it looks
like VE is not doing the right thing. But, if you think about it,
VE is a design-time tool, which makes no interpretation of runtime
behavior. As far as VE goes, the JTextField has its text set to
"SHOULD NOT BE DISPLAYED!", and that is what it tries to reflect
in the UI. In this case the if(false) is pretty straight forward,
but then, VE would have to understand cases like if(Boolean.FALSE),
if(new Boolean("True").booleanValue()) etc. - basically it would
have to evaluate the contents of the if() - something which should
be done by the runtime. And if the contents of the if() is some
non-final content (method calls etc.), then the result is
undeterministic at design-time. Because of all this complexity, it
was decided to atleast model the source, irrespective of the
runtime behaviour. I hope this has provided some explanation as to
why VE is behaving so... I was wondering if you think this problem
is a defect or an enahancement?
Regards,
Sri.
Marcus Beyer wrote:
>
>> Even worse for VE false seems to be equal to true:
>>
>> if (false)
>> {
>> jTextField.setText ("SHOULD NOT BE DISPLAYED!");
>> }
>>
>> Yes, the text is displayed in design time :-(
>
>
> I just posted this bug report:
>
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=69357>
>
> Marcus
|
|
|
| Re: false equals true ?! [message #47924 is a reply to message #47774] |
Tue, 06 July 2004 12:26 |
| Eclipse User |
|
|
|
Originally posted by: mb.thomas-daily.de
Sri Gunturi schrieb:
> Hi Marcus,
> I agree that once you look at the piece of code, it looks
> like VE is not doing the right thing. But, if you think about it,
> VE is a design-time tool, which makes no interpretation of runtime
> behavior. As far as VE goes, the JTextField has its text set to
> "SHOULD NOT BE DISPLAYED!", and that is what it tries to reflect
> in the UI. In this case the if(false) is pretty straight forward,
> but then, VE would have to understand cases like if(Boolean.FALSE),
> if(new Boolean("True").booleanValue()) etc. - basically it would
> have to evaluate the contents of the if() - something which should
> be done by the runtime. And if the contents of the if() is some
> non-final content (method calls etc.), then the result is
> undeterministic at design-time. Because of all this complexity, it
> was decided to atleast model the source, irrespective of the
> runtime behaviour.
Why is undeterministic behaviour a problem? The developer must
use "if (Beans.isDesignTime)" anyway, e.g. in custom methods called
by initialize ( ), so that calls to databases are not made, etc.
On the other hand, the only expressions of interest are:
1. if (Beans.isDesignTime)
2. if (!Beans.isDesignTime)
Example: some elements in my GUI are invisible by default.
I want to see them in VE nevertheless. Hmm, as I think about it,
the solution is quite easy: I just inherit e.g. from JTextField
and override a set-method:
public void setVisible (boolean b)
{
if (Beans.isDesignTime ( ))
{
if (!b)
{
/*
* spooky look: cyan border and gray text
*/
setBorder (BorderFactory.createLineBorder (Color.cyan));
setEnabled (false);
}
}
else
{
super.setVisible (b);
}
}
Hmm, and the (calling) application code is shorter :-)
Maybe there is really no need to evaluate conditionals.
> I was wondering if you think this problem
> is a defect or an enahancement?
A defect, as I still don't understand why this behaves as wanted:
if (java.beans.Beans.isDesignTime ( ))
{
}
else
{
jTextField.setBackground (java.awt.Color.RED);
}
and this not:
if (!java.beans.Beans.isDesignTime ( ))
{
jTextField.setBackground (java.awt.Color.RED);
}
Does VE ignore everything in "else"? Doesn't make sense, does it?
Maybe VE should generate a warning (in the problem view),
if there is the String "Beans.isDesignTime" inside of such
a get-method. What do you think?
Thank you for your thoughts!
Marcus
BTW: I love VE. Please don't get a different impression :-)
|
|
|
| Re: false equals true ?! [message #48043 is a reply to message #47924] |
Tue, 06 July 2004 14:48 |
| Eclipse User |
|
|
|
Hi Marcus,
Thanks for taking time to explain about the problem. The way VE works
by default as of now is that only the statements in the 'then' section
are evaluated, and everything in the 'else' section is ignored. So, it
doesnt matter what is inside the if() - the 'then' section will be
modelled. This behaviour however is customizeable through a rule (see
org.eclipse.ve.internal.java.codegen.java.rules.IfStatementR ule). Now,
one can change the rule so that you can either process statements in the
'then' or the 'else' sections.
I can understand the rule being more intelligent in simple cases like:
if(false), if(true), if(Beans.isDesignTime()), if(!Beans.isDesignTime())
- but how is one to determine the boolean outcome of more complex
expressions - like if(getRandomBoolean())?
In this case:
if(getRandomBoolean()){
jTextField.setBackground (java.awt.Color.RED);
}else{
jTextField.setBackground (java.awt.Color.BLUE);
}
should VE set the jTextField background color to RED or BLUE? Because
there was no easy way of figuring this out, we adopted a simple approach
and processed only statements in the 'then' section. If you feel having
the intelligence in the rule (for the simple cases mentioned only) is a
must, please mention that in the defect. Actually, come to think of it,
it would be a very good excercise to fix this defect and contribute to
VE :). Hope this explanation has shed some light on the problem.
Regards,
Sri.
Marcus Beyer wrote:
> Sri Gunturi schrieb:
>
>> Hi Marcus,
>> I agree that once you look at the piece of code, it looks
>> like VE is not doing the right thing. But, if you think about it,
>> VE is a design-time tool, which makes no interpretation of runtime
>> behavior. As far as VE goes, the JTextField has its text set to
>> "SHOULD NOT BE DISPLAYED!", and that is what it tries to reflect
>> in the UI. In this case the if(false) is pretty straight forward,
>> but then, VE would have to understand cases like if(Boolean.FALSE),
>> if(new Boolean("True").booleanValue()) etc. - basically it would
>> have to evaluate the contents of the if() - something which should
>> be done by the runtime. And if the contents of the if() is some
>> non-final content (method calls etc.), then the result is
>> undeterministic at design-time. Because of all this complexity, it
>> was decided to atleast model the source, irrespective of the
>> runtime behaviour.
>
>
> Why is undeterministic behaviour a problem? The developer must
> use "if (Beans.isDesignTime)" anyway, e.g. in custom methods called
> by initialize ( ), so that calls to databases are not made, etc.
>
> On the other hand, the only expressions of interest are:
> 1. if (Beans.isDesignTime)
> 2. if (!Beans.isDesignTime)
>
> Example: some elements in my GUI are invisible by default.
> I want to see them in VE nevertheless. Hmm, as I think about it,
> the solution is quite easy: I just inherit e.g. from JTextField
> and override a set-method:
>
> public void setVisible (boolean b)
> {
> if (Beans.isDesignTime ( ))
> {
> if (!b)
> {
> /*
> * spooky look: cyan border and gray text
> */
> setBorder (BorderFactory.createLineBorder (Color.cyan));
> setEnabled (false);
> }
> }
> else
> {
> super.setVisible (b);
> }
> }
>
> Hmm, and the (calling) application code is shorter :-)
> Maybe there is really no need to evaluate conditionals.
>
> > I was wondering if you think this problem
> > is a defect or an enahancement?
>
> A defect, as I still don't understand why this behaves as wanted:
>
> if (java.beans.Beans.isDesignTime ( ))
> {
> }
> else
> {
> jTextField.setBackground (java.awt.Color.RED);
> }
>
> and this not:
>
> if (!java.beans.Beans.isDesignTime ( ))
> {
> jTextField.setBackground (java.awt.Color.RED);
> }
>
> Does VE ignore everything in "else"? Doesn't make sense, does it?
>
> Maybe VE should generate a warning (in the problem view),
> if there is the String "Beans.isDesignTime" inside of such
> a get-method. What do you think?
>
> Thank you for your thoughts!
>
> Marcus
>
> BTW: I love VE. Please don't get a different impression :-)
|
|
|
| Re: false equals true ?! [message #48104 is a reply to message #48043] |
Tue, 06 July 2004 15:06 |
| Eclipse User |
|
|
|
Originally posted by: mb.thomas-daily.de
Sri Gunturi schrieb:
> Hi Marcus,
> Thanks for taking time to explain about the problem. The way VE
> works by default as of now is that only the statements in the 'then'
> section are evaluated, and everything in the 'else' section is ignored.
> So, it doesnt matter what is inside the if() - the 'then' section will
> be modelled. This behaviour however is customizeable through a rule (see
> org.eclipse.ve.internal.java.codegen.java.rules.IfStatementR ule). Now,
> one can change the rule so that you can either process statements in the
> 'then' or the 'else' sections.
> I can understand the rule being more intelligent in simple cases
> like: if(false), if(true), if(Beans.isDesignTime()),
> if(!Beans.isDesignTime()) - but how is one to determine the boolean
> outcome of more complex expressions - like if(getRandomBoolean())?
> In this case:
> if(getRandomBoolean()){
> jTextField.setBackground (java.awt.Color.RED);
> }else{
> jTextField.setBackground (java.awt.Color.BLUE);
> }
>
> should VE set the jTextField background color to RED or BLUE? Because
> there was no easy way of figuring this out,
The thing I do not yet understand is why the code isn't simply executed.
There might be good reasons.
> we adopted a simple approach
> and processed only statements in the 'then' section. If you feel having
> the intelligence in the rule (for the simple cases mentioned only) is a
> must, please mention that in the defect. Actually, come to think of it,
> it would be a very good excercise to fix this defect and contribute to
> VE :). Hope this explanation has shed some light on the problem.
As I said:
>> Maybe there is really no need to evaluate conditionals.
My thread "seeing the invisible" perhaps makes it more clear.
It could be discussed, if "setVisible(false)" should be
interpreted by VE (more or less, perhaps dashed) like I do it
manually. Don't know ...
Thank you for explaining!
Marcus
|
|
|
| Re: false equals true ?! [message #49787 is a reply to message #48104] |
Tue, 13 July 2004 11:44 |
| Eclipse User |
|
|
|
Marcus Beyer wrote:
> Sri Gunturi schrieb:
>
>> Hi Marcus,
>> Thanks for taking time to explain about the problem. The way VE
>> works by default as of now is that only the statements in the 'then'
>> section are evaluated, and everything in the 'else' section is
>> ignored. So, it doesnt matter what is inside the if() - the 'then'
>> section will be modelled. This behaviour however is customizeable
>> through a rule (see
>> org.eclipse.ve.internal.java.codegen.java.rules.IfStatementR ule). Now,
>> one can change the rule so that you can either process statements in
>> the 'then' or the 'else' sections.
>> I can understand the rule being more intelligent in simple cases
>> like: if(false), if(true), if(Beans.isDesignTime()),
>> if(!Beans.isDesignTime()) - but how is one to determine the boolean
>> outcome of more complex expressions - like if(getRandomBoolean())?
>> In this case:
>> if(getRandomBoolean()){
>> jTextField.setBackground (java.awt.Color.RED);
>> }else{
>> jTextField.setBackground (java.awt.Color.BLUE);
>> }
>>
>> should VE set the jTextField background color to RED or BLUE? Because
>> there was no easy way of figuring this out,
>
>
> The thing I do not yet understand is why the code isn't simply executed.
> There might be good reasons.
I didn't write this part of VE, but in the old SWTworkbench GUI builder,
we don't just execute client code because of the Halting Problem. If
you're unfamiliar with this problem, Google can help... On the other
hand, we do have a minimal Java interpeter that we use to evaluate basic
expressions.
Sri, if you think that code might be helpful, I can forward it to you.
>> we adopted a simple approach and processed only statements in the
>> 'then' section. If you feel having the intelligence in the rule (for
>> the simple cases mentioned only) is a must, please mention that in the
>> defect. Actually, come to think of it, it would be a very good
>> excercise to fix this defect and contribute to VE :). Hope this
>> explanation has shed some light on the problem.
>
>
> As I said:
>
>>> Maybe there is really no need to evaluate conditionals.
>
>
> My thread "seeing the invisible" perhaps makes it more clear.
> It could be discussed, if "setVisible(false)" should be
> interpreted by VE (more or less, perhaps dashed) like I do it
> manually. Don't know ...
>
> Thank you for explaining!
Regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com
|
|
|
| Re: false equals true ?! [message #49910 is a reply to message #49787] |
Tue, 13 July 2004 15:50 |
| Eclipse User |
|
|
|
The Halting problem is solvable...
See http://www.netfunny.com/rhf/jokes/new89/halting.760.html
Seriously, though, why not just run the code with a timeout guard thread
(user-adjustable timeout)? You're penalizing all of the well-behaved
beans for the very very few that might have a loop. I don't see how an
interpreter can really be appropriate...
My 2c...
-- Scott
In article <cd0vuu$2e2$1@eclipse.org>, daveo@asc-iseries.com says...
> Marcus Beyer wrote:
> > Sri Gunturi schrieb:
> >
> >> Hi Marcus,
> >> Thanks for taking time to explain about the problem. The way VE
> >> works by default as of now is that only the statements in the 'then'
> >> section are evaluated, and everything in the 'else' section is
> >> ignored. So, it doesnt matter what is inside the if() - the 'then'
> >> section will be modelled. This behaviour however is customizeable
> >> through a rule (see
> >> org.eclipse.ve.internal.java.codegen.java.rules.IfStatementR ule). Now,
> >> one can change the rule so that you can either process statements in
> >> the 'then' or the 'else' sections.
> >> I can understand the rule being more intelligent in simple cases
> >> like: if(false), if(true), if(Beans.isDesignTime()),
> >> if(!Beans.isDesignTime()) - but how is one to determine the boolean
> >> outcome of more complex expressions - like if(getRandomBoolean())?
> >> In this case:
> >> if(getRandomBoolean()){
> >> jTextField.setBackground (java.awt.Color.RED);
> >> }else{
> >> jTextField.setBackground (java.awt.Color.BLUE);
> >> }
> >>
> >> should VE set the jTextField background color to RED or BLUE? Because
> >> there was no easy way of figuring this out,
> >
> >
> > The thing I do not yet understand is why the code isn't simply executed.
> > There might be good reasons.
>
> I didn't write this part of VE, but in the old SWTworkbench GUI builder,
> we don't just execute client code because of the Halting Problem. If
> you're unfamiliar with this problem, Google can help... On the other
> hand, we do have a minimal Java interpeter that we use to evaluate basic
> expressions.
>
> Sri, if you think that code might be helpful, I can forward it to you.
>
> >> we adopted a simple approach and processed only statements in the
> >> 'then' section. If you feel having the intelligence in the rule (for
> >> the simple cases mentioned only) is a must, please mention that in the
> >> defect. Actually, come to think of it, it would be a very good
> >> excercise to fix this defect and contribute to VE :). Hope this
> >> explanation has shed some light on the problem.
> >
> >
> > As I said:
> >
> >>> Maybe there is really no need to evaluate conditionals.
> >
> >
> > My thread "seeing the invisible" perhaps makes it more clear.
> > It could be discussed, if "setVisible(false)" should be
> > interpreted by VE (more or less, perhaps dashed) like I do it
> > manually. Don't know ...
> >
> > Thank you for explaining!
>
>
> Regards,
>
> Dave
>
>
|
|
| |
| Re: false equals true ?! [message #50126 is a reply to message #49940] |
Wed, 14 July 2004 06:46 |
| Eclipse User |
|
|
|
In article <cd1hf1$1u3$3@eclipse.org>, daveo@asc-iseries.com says...
> Scott Stanchfield wrote:
>
> > The Halting problem is solvable...
> >
> > See http://www.netfunny.com/rhf/jokes/new89/halting.760.html
> >
> >
> > Seriously, though, why not just run the code with a timeout guard thread
> > (user-adjustable timeout)? You're penalizing all of the well-behaved
> > beans for the very very few that might have a loop. I don't see how an
> > interpreter can really be appropriate...
> At least in SWTworkbench Builder, you can't just run the code because
> SWTworkbench Builder inserts invisible Composites into the layout in
> order to do various things. So the result of running the code is
> different from the result of building the layout from the code inside
> the builder.
ahhhh
> (SWTworkbench Builder is *not* GEF-based; it doesn't create a layout,
> then screen-scrape it like all the GEF-based builders have to do, but
> rather SWTworkbench Builder edits live SWT widgets using a technique you
> first described on Eclipse.tools in the pre-1.0 days. ;-)
<blush>
That's what I get for laying my cards on the table, heh heh...
> Of course this is all moot since I'm now working toward VE being
> Eclipse's GUI builder and a foundation on which value-added GUI builder
> features for Eclipse can be built (those of us that get paid to do this
> have to pay the bills too, you know).
<g>
> I'm just trying to leverage some of that experience here to help this
> project. :-)
Cool -- hopefully it can become a little more flexible somehow, over
time. Otherwise it's more of a WYSIKOWYG (What you see is kind of what
you get) than WYSIWYG ;)
Later,
-- Scott
|
|
| |
| Re: false equals true ?! [message #50411 is a reply to message #50179] |
Thu, 15 July 2004 10:17 |
| Eclipse User |
|
|
|
Originally posted by: mb.thomas-daily.de
Gili Mendel schrieb:
>
>>
>> The thing I do not yet understand is why the code isn't simply executed.
>> There might be good reasons.
>>
>
> Besides the fact that VE may (at some point) be extended to searlize and
> work from none-Java source, Executing code is a slippery slope :-(
> It opens up many issues like, what areas of the code will you execute
> (most of the time when you update/develop code, the CU is not compilable)?
Eclipse knows when the code is compilable, right?
So don't execute if it is not compilable -- it isn't possible anyway.
> From your example above:
>
> if(getRandomBoolean()){
> jTextField.setBackground (java.awt.Color.RED);
> }else{
> jTextField.setBackground (java.awt.Color.BLUE);
> }
>
>
> What if getRandomBoolean() requires main() to set up some context, or
> what if getRandomBoolean uses the network to check IBM's stock to make a
> decision (in this case it should be BLUE and veryBLUE ;-) ... will you
> require network connection, or a DB connection or .... to figure out
> what color to set in the PropertySheet for jTextField? And let say,
> that you want to use VE to set the jTextField's color to Red. What kind
> of code should VE generate?... should it change the getRandomBoolean to
> check a MS symbol instead??? ... just trying to make a point ;-) Red
> is a great color.
Ha, very funny.
Lets say I put my redOrBlue code or your veryBlueStock code into my own
Bean class, in the constructor, in setVisible, whatever. If I know use
that bean in VE ("Choose Bean") that code *is* executed: the net is
contacted, IBM's stock is checked, the code may not halt, etc.
So what is the difference? Why is it executed in the bean code but not
in the code using that bean? Are people using the beans supposed to
be more stupid than those writing the beans?
thanx!
Marcus
|
|
|
| Re: false equals true ?! [message #50495 is a reply to message #50411] |
Fri, 16 July 2004 09:56 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
>
> Eclipse knows when the code is compilable, right?
> So don't execute if it is not compilable -- it isn't possible anyway.
>
Yes it is, but there is much that is left to be done.
The Java Editor will reconcile() and annotate the editor in a background
thread, but it will not update the .classes involved nor will it
generate bite code for the various impacted CUs.
To keep on running without kicking off frequent slow (disk bound)
builds, we will have to use hot swaps (similar to a debugger), something
that is not bullet proof.
>> From your example above:
>>
>> if(getRandomBoolean()){
>> jTextField.setBackground (java.awt.Color.RED);
>> }else{
>> jTextField.setBackground (java.awt.Color.BLUE);
>> }
>>
>>
>> What if getRandomBoolean() requires main() to set up some context, or
>> what if getRandomBoolean uses the network to check IBM's stock to make
>> a decision (in this case it should be BLUE and veryBLUE ;-) ... will
>> you require network connection, or a DB connection or .... to figure
>> out what color to set in the PropertySheet for jTextField? And let
>> say, that you want to use VE to set the jTextField's color to Red.
>> What kind of code should VE generate?... should it change the
>> getRandomBoolean to check a MS symbol instead??? ... just trying to
>> make a point ;-) Red is a great color.
>
>
> Ha, very funny.
>
> Lets say I put my redOrBlue code or your veryBlueStock code into my own
> Bean class, in the constructor, in setVisible, whatever. If I know use
> that bean in VE ("Choose Bean") that code *is* executed: the net is
> contacted, IBM's stock is checked, the code may not halt, etc.
>
Yes... this is the reason for Beans.isDesign() ... it is up for the bean
provider to provide design vs. run time instantiation.
> So what is the difference? Why is it executed in the bean code but not
> in the code using that bean? Are people using the beans supposed to
> be more stupid than those writing the beans?
>
Ultimately, the bean is to be used in run time, and the code that is
generated is generated in design time (where the environment is not
suitable to fully drive the bean) for run time consumption.
Hence the complexity. It would not always be obvious where/what to
generate. For the background color above... if you use the Property
Sheet to change the color to Red; where should we generate it ? On both
sides of the if(), update the getRandomBoolean() semantics? ... it can
get hairy quite quickly.
The Design/RunTime approach is to keep things simple and predictable.
It has its flaws... but merits as well.
|
|
|
| false equals true ?! [message #594303 is a reply to message #47313] |
Tue, 06 July 2004 06:05 |
| Eclipse User |
|
|
|
Marcus Beyer schrieb:
> /*
> * does not work as expected in design time
> */
> private JTextField getJTextField ( )
> {
> if (jTextField == null)
> {
> jTextField = new JTextField ( );
> jTextField.setText ("blah");
> if (!java.beans.Beans.isDesignTime ( ))
> {
> jTextField.setBackground (java.awt.Color.RED);
> }
> }
> return jTextField;
> }
Even worse for VE false seems to be equal to true:
if (false)
{
jTextField.setText ("SHOULD NOT BE DISPLAYED!");
}
Yes, the text is displayed in design time :-(
Cheers!
Marcus
|
|
| |
| Re: false equals true ?! [message #594459 is a reply to message #47490] |
Tue, 06 July 2004 10:40 |
| Eclipse User |
|
|
|
Hi Marcus,
I agree that once you look at the piece of code, it looks
like VE is not doing the right thing. But, if you think about it,
VE is a design-time tool, which makes no interpretation of runtime
behavior. As far as VE goes, the JTextField has its text set to
"SHOULD NOT BE DISPLAYED!", and that is what it tries to reflect
in the UI. In this case the if(false) is pretty straight forward,
but then, VE would have to understand cases like if(Boolean.FALSE),
if(new Boolean("True").booleanValue()) etc. - basically it would
have to evaluate the contents of the if() - something which should
be done by the runtime. And if the contents of the if() is some
non-final content (method calls etc.), then the result is
undeterministic at design-time. Because of all this complexity, it
was decided to atleast model the source, irrespective of the
runtime behaviour. I hope this has provided some explanation as to
why VE is behaving so... I was wondering if you think this problem
is a defect or an enahancement?
Regards,
Sri.
Marcus Beyer wrote:
>
>> Even worse for VE false seems to be equal to true:
>>
>> if (false)
>> {
>> jTextField.setText ("SHOULD NOT BE DISPLAYED!");
>> }
>>
>> Yes, the text is displayed in design time :-(
>
>
> I just posted this bug report:
>
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=69357>
>
> Marcus
|
|
|
| Re: false equals true ?! [message #594496 is a reply to message #47774] |
Tue, 06 July 2004 12:26 |
| Eclipse User |
|
|
|
Sri Gunturi schrieb:
> Hi Marcus,
> I agree that once you look at the piece of code, it looks
> like VE is not doing the right thing. But, if you think about it,
> VE is a design-time tool, which makes no interpretation of runtime
> behavior. As far as VE goes, the JTextField has its text set to
> "SHOULD NOT BE DISPLAYED!", and that is what it tries to reflect
> in the UI. In this case the if(false) is pretty straight forward,
> but then, VE would have to understand cases like if(Boolean.FALSE),
> if(new Boolean("True").booleanValue()) etc. - basically it would
> have to evaluate the contents of the if() - something which should
> be done by the runtime. And if the contents of the if() is some
> non-final content (method calls etc.), then the result is
> undeterministic at design-time. Because of all this complexity, it
> was decided to atleast model the source, irrespective of the
> runtime behaviour.
Why is undeterministic behaviour a problem? The developer must
use "if (Beans.isDesignTime)" anyway, e.g. in custom methods called
by initialize ( ), so that calls to databases are not made, etc.
On the other hand, the only expressions of interest are:
1. if (Beans.isDesignTime)
2. if (!Beans.isDesignTime)
Example: some elements in my GUI are invisible by default.
I want to see them in VE nevertheless. Hmm, as I think about it,
the solution is quite easy: I just inherit e.g. from JTextField
and override a set-method:
public void setVisible (boolean b)
{
if (Beans.isDesignTime ( ))
{
if (!b)
{
/*
* spooky look: cyan border and gray text
*/
setBorder (BorderFactory.createLineBorder (Color.cyan));
setEnabled (false);
}
}
else
{
super.setVisible (b);
}
}
Hmm, and the (calling) application code is shorter :-)
Maybe there is really no need to evaluate conditionals.
> I was wondering if you think this problem
> is a defect or an enahancement?
A defect, as I still don't understand why this behaves as wanted:
if (java.beans.Beans.isDesignTime ( ))
{
}
else
{
jTextField.setBackground (java.awt.Color.RED);
}
and this not:
if (!java.beans.Beans.isDesignTime ( ))
{
jTextField.setBackground (java.awt.Color.RED);
}
Does VE ignore everything in "else"? Doesn't make sense, does it?
Maybe VE should generate a warning (in the problem view),
if there is the String "Beans.isDesignTime" inside of such
a get-method. What do you think?
Thank you for your thoughts!
Marcus
BTW: I love VE. Please don't get a different impression :-)
|
|
|
| Re: false equals true ?! [message #594526 is a reply to message #47924] |
Tue, 06 July 2004 14:48 |
| Eclipse User |
|
|
|
Hi Marcus,
Thanks for taking time to explain about the problem. The way VE works
by default as of now is that only the statements in the 'then' section
are evaluated, and everything in the 'else' section is ignored. So, it
doesnt matter what is inside the if() - the 'then' section will be
modelled. This behaviour however is customizeable through a rule (see
org.eclipse.ve.internal.java.codegen.java.rules.IfStatementR ule). Now,
one can change the rule so that you can either process statements in the
'then' or the 'else' sections.
I can understand the rule being more intelligent in simple cases like:
if(false), if(true), if(Beans.isDesignTime()), if(!Beans.isDesignTime())
- but how is one to determine the boolean outcome of more complex
expressions - like if(getRandomBoolean())?
In this case:
if(getRandomBoolean()){
jTextField.setBackground (java.awt.Color.RED);
}else{
jTextField.setBackground (java.awt.Color.BLUE);
}
should VE set the jTextField background color to RED or BLUE? Because
there was no easy way of figuring this out, we adopted a simple approach
and processed only statements in the 'then' section. If you feel having
the intelligence in the rule (for the simple cases mentioned only) is a
must, please mention that in the defect. Actually, come to think of it,
it would be a very good excercise to fix this defect and contribute to
VE :). Hope this explanation has shed some light on the problem.
Regards,
Sri.
Marcus Beyer wrote:
> Sri Gunturi schrieb:
>
>> Hi Marcus,
>> I agree that once you look at the piece of code, it looks
>> like VE is not doing the right thing. But, if you think about it,
>> VE is a design-time tool, which makes no interpretation of runtime
>> behavior. As far as VE goes, the JTextField has its text set to
>> "SHOULD NOT BE DISPLAYED!", and that is what it tries to reflect
>> in the UI. In this case the if(false) is pretty straight forward,
>> but then, VE would have to understand cases like if(Boolean.FALSE),
>> if(new Boolean("True").booleanValue()) etc. - basically it would
>> have to evaluate the contents of the if() - something which should
>> be done by the runtime. And if the contents of the if() is some
>> non-final content (method calls etc.), then the result is
>> undeterministic at design-time. Because of all this complexity, it
>> was decided to atleast model the source, irrespective of the
>> runtime behaviour.
>
>
> Why is undeterministic behaviour a problem? The developer must
> use "if (Beans.isDesignTime)" anyway, e.g. in custom methods called
> by initialize ( ), so that calls to databases are not made, etc.
>
> On the other hand, the only expressions of interest are:
> 1. if (Beans.isDesignTime)
> 2. if (!Beans.isDesignTime)
>
> Example: some elements in my GUI are invisible by default.
> I want to see them in VE nevertheless. Hmm, as I think about it,
> the solution is quite easy: I just inherit e.g. from JTextField
> and override a set-method:
>
> public void setVisible (boolean b)
> {
> if (Beans.isDesignTime ( ))
> {
> if (!b)
> {
> /*
> * spooky look: cyan border and gray text
> */
> setBorder (BorderFactory.createLineBorder (Color.cyan));
> setEnabled (false);
> }
> }
> else
> {
> super.setVisible (b);
> }
> }
>
> Hmm, and the (calling) application code is shorter :-)
> Maybe there is really no need to evaluate conditionals.
>
> > I was wondering if you think this problem
> > is a defect or an enahancement?
>
> A defect, as I still don't understand why this behaves as wanted:
>
> if (java.beans.Beans.isDesignTime ( ))
> {
> }
> else
> {
> jTextField.setBackground (java.awt.Color.RED);
> }
>
> and this not:
>
> if (!java.beans.Beans.isDesignTime ( ))
> {
> jTextField.setBackground (java.awt.Color.RED);
> }
>
> Does VE ignore everything in "else"? Doesn't make sense, does it?
>
> Maybe VE should generate a warning (in the problem view),
> if there is the String "Beans.isDesignTime" inside of such
> a get-method. What do you think?
>
> Thank you for your thoughts!
>
> Marcus
>
> BTW: I love VE. Please don't get a different impression :-)
|
|
|
| Re: false equals true ?! [message #594542 is a reply to message #48043] |
Tue, 06 July 2004 15:06 |
| Eclipse User |
|
|
|
Sri Gunturi schrieb:
> Hi Marcus,
> Thanks for taking time to explain about the problem. The way VE
> works by default as of now is that only the statements in the 'then'
> section are evaluated, and everything in the 'else' section is ignored.
> So, it doesnt matter what is inside the if() - the 'then' section will
> be modelled. This behaviour however is customizeable through a rule (see
> org.eclipse.ve.internal.java.codegen.java.rules.IfStatementR ule). Now,
> one can change the rule so that you can either process statements in the
> 'then' or the 'else' sections.
> I can understand the rule being more intelligent in simple cases
> like: if(false), if(true), if(Beans.isDesignTime()),
> if(!Beans.isDesignTime()) - but how is one to determine the boolean
> outcome of more complex expressions - like if(getRandomBoolean())?
> In this case:
> if(getRandomBoolean()){
> jTextField.setBackground (java.awt.Color.RED);
> }else{
> jTextField.setBackground (java.awt.Color.BLUE);
> }
>
> should VE set the jTextField background color to RED or BLUE? Because
> there was no easy way of figuring this out,
The thing I do not yet understand is why the code isn't simply executed.
There might be good reasons.
> we adopted a simple approach
> and processed only statements in the 'then' section. If you feel having
> the intelligence in the rule (for the simple cases mentioned only) is a
> must, please mention that in the defect. Actually, come to think of it,
> it would be a very good excercise to fix this defect and contribute to
> VE :). Hope this explanation has shed some light on the problem.
As I said:
>> Maybe there is really no need to evaluate conditionals.
My thread "seeing the invisible" perhaps makes it more clear.
It could be discussed, if "setVisible(false)" should be
interpreted by VE (more or less, perhaps dashed) like I do it
manually. Don't know ...
Thank you for explaining!
Marcus
|
|
|
| Re: false equals true ?! [message #595086 is a reply to message #48104] |
Tue, 13 July 2004 11:44 |
| Eclipse User |
|
|
|
Marcus Beyer wrote:
> Sri Gunturi schrieb:
>
>> Hi Marcus,
>> Thanks for taking time to explain about the problem. The way VE
>> works by default as of now is that only the statements in the 'then'
>> section are evaluated, and everything in the 'else' section is
>> ignored. So, it doesnt matter what is inside the if() - the 'then'
>> section will be modelled. This behaviour however is customizeable
>> through a rule (see
>> org.eclipse.ve.internal.java.codegen.java.rules.IfStatementR ule). Now,
>> one can change the rule so that you can either process statements in
>> the 'then' or the 'else' sections.
>> I can understand the rule being more intelligent in simple cases
>> like: if(false), if(true), if(Beans.isDesignTime()),
>> if(!Beans.isDesignTime()) - but how is one to determine the boolean
>> outcome of more complex expressions - like if(getRandomBoolean())?
>> In this case:
>> if(getRandomBoolean()){
>> jTextField.setBackground (java.awt.Color.RED);
>> }else{
>> jTextField.setBackground (java.awt.Color.BLUE);
>> }
>>
>> should VE set the jTextField background color to RED or BLUE? Because
>> there was no easy way of figuring this out,
>
>
> The thing I do not yet understand is why the code isn't simply executed.
> There might be good reasons.
I didn't write this part of VE, but in the old SWTworkbench GUI builder,
we don't just execute client code because of the Halting Problem. If
you're unfamiliar with this problem, Google can help... On the other
hand, we do have a minimal Java interpeter that we use to evaluate basic
expressions.
Sri, if you think that code might be helpful, I can forward it to you.
>> we adopted a simple approach and processed only statements in the
>> 'then' section. If you feel having the intelligence in the rule (for
>> the simple cases mentioned only) is a must, please mention that in the
>> defect. Actually, come to think of it, it would be a very good
>> excercise to fix this defect and contribute to VE :). Hope this
>> explanation has shed some light on the problem.
>
>
> As I said:
>
>>> Maybe there is really no need to evaluate conditionals.
>
>
> My thread "seeing the invisible" perhaps makes it more clear.
> It could be discussed, if "setVisible(false)" should be
> interpreted by VE (more or less, perhaps dashed) like I do it
> manually. Don't know ...
>
> Thank you for explaining!
Regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com
|
|
|
| Re: false equals true ?! [message #595122 is a reply to message #49787] |
Tue, 13 July 2004 15:50 |
| Eclipse User |
|
|
|
The Halting problem is solvable...
See http://www.netfunny.com/rhf/jokes/new89/halting.760.html
Seriously, though, why not just run the code with a timeout guard thread
(user-adjustable timeout)? You're penalizing all of the well-behaved
beans for the very very few that might have a loop. I don't see how an
interpreter can really be appropriate...
My 2c...
-- Scott
In article <cd0vuu$2e2$1@eclipse.org>, daveo@asc-iseries.com says...
> Marcus Beyer wrote:
> > Sri Gunturi schrieb:
> >
> >> Hi Marcus,
> >> Thanks for taking time to explain about the problem. The way VE
> >> works by default as of now is that only the statements in the 'then'
> >> section are evaluated, and everything in the 'else' section is
> >> ignored. So, it doesnt matter what is inside the if() - the 'then'
> >> section will be modelled. This behaviour however is customizeable
> >> through a rule (see
> >> org.eclipse.ve.internal.java.codegen.java.rules.IfStatementR ule). Now,
> >> one can change the rule so that you can either process statements in
> >> the 'then' or the 'else' sections.
> >> I can understand the rule being more intelligent in simple cases
> >> like: if(false), if(true), if(Beans.isDesignTime()),
> >> if(!Beans.isDesignTime()) - but how is one to determine the boolean
> >> outcome of more complex expressions - like if(getRandomBoolean())?
> >> In this case:
> >> if(getRandomBoolean()){
> >> jTextField.setBackground (java.awt.Color.RED);
> >> }else{
> >> jTextField.setBackground (java.awt.Color.BLUE);
> >> }
> >>
> >> should VE set the jTextField background color to RED or BLUE? Because
> >> there was no easy way of figuring this out,
> >
> >
> > The thing I do not yet understand is why the code isn't simply executed.
> > There might be good reasons.
>
> I didn't write this part of VE, but in the old SWTworkbench GUI builder,
> we don't just execute client code because of the Halting Problem. If
> you're unfamiliar with this problem, Google can help... On the other
> hand, we do have a minimal Java interpeter that we use to evaluate basic
> expressions.
>
> Sri, if you think that code might be helpful, I can forward it to you.
>
> >> we adopted a simple approach and processed only statements in the
> >> 'then' section. If you feel having the intelligence in the rule (for
> >> the simple cases mentioned only) is a must, please mention that in the
> >> defect. Actually, come to think of it, it would be a very good
> >> excercise to fix this defect and contribute to VE :). Hope this
> >> explanation has shed some light on the problem.
> >
> >
> > As I said:
> >
> >>> Maybe there is really no need to evaluate conditionals.
> >
> >
> > My thread "seeing the invisible" perhaps makes it more clear.
> > It could be discussed, if "setVisible(false)" should be
> > interpreted by VE (more or less, perhaps dashed) like I do it
> > manually. Don't know ...
> >
> > Thank you for explaining!
>
>
> Regards,
>
> Dave
>
>
|
|
|
| Re: false equals true ?! [message #595128 is a reply to message #49910] |
Tue, 13 July 2004 16:43 |
| Eclipse User |
|
|
|
Scott Stanchfield wrote:
> The Halting problem is solvable...
>
> See http://www.netfunny.com/rhf/jokes/new89/halting.760.html
>
>
> Seriously, though, why not just run the code with a timeout guard thread
> (user-adjustable timeout)? You're penalizing all of the well-behaved
> beans for the very very few that might have a loop. I don't see how an
> interpreter can really be appropriate...
At least in SWTworkbench Builder, you can't just run the code because
SWTworkbench Builder inserts invisible Composites into the layout in
order to do various things. So the result of running the code is
different from the result of building the layout from the code inside
the builder.
(SWTworkbench Builder is *not* GEF-based; it doesn't create a layout,
then screen-scrape it like all the GEF-based builders have to do, but
rather SWTworkbench Builder edits live SWT widgets using a technique you
first described on Eclipse.tools in the pre-1.0 days. ;-)
Of course this is all moot since I'm now working toward VE being
Eclipse's GUI builder and a foundation on which value-added GUI builder
features for Eclipse can be built (those of us that get paid to do this
have to pay the bills too, you know).
I'm just trying to leverage some of that experience here to help this
project. :-)
Regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com
|
|
|
| Re: false equals true ?! [message #595184 is a reply to message #49940] |
Wed, 14 July 2004 06:46 |
| Eclipse User |
|
|
|
In article <cd1hf1$1u3$3@eclipse.org>, daveo@asc-iseries.com says...
> Scott Stanchfield wrote:
>
> > The Halting problem is solvable...
> >
> > See http://www.netfunny.com/rhf/jokes/new89/halting.760.html
> >
> >
> > Seriously, though, why not just run the code with a timeout guard thread
> > (user-adjustable timeout)? You're penalizing all of the well-behaved
> > beans for the very very few that might have a loop. I don't see how an
> > interpreter can really be appropriate...
> At least in SWTworkbench Builder, you can't just run the code because
> SWTworkbench Builder inserts invisible Composites into the layout in
> order to do various things. So the result of running the code is
> different from the result of building the layout from the code inside
> the builder.
ahhhh
> (SWTworkbench Builder is *not* GEF-based; it doesn't create a layout,
> then screen-scrape it like all the GEF-based builders have to do, but
> rather SWTworkbench Builder edits live SWT widgets using a technique you
> first described on Eclipse.tools in the pre-1.0 days. ;-)
<blush>
That's what I get for laying my cards on the table, heh heh...
> Of course this is all moot since I'm now working toward VE being
> Eclipse's GUI builder and a foundation on which value-added GUI builder
> features for Eclipse can be built (those of us that get paid to do this
> have to pay the bills too, you know).
<g>
> I'm just trying to leverage some of that experience here to help this
> project. :-)
Cool -- hopefully it can become a little more flexible somehow, over
time. Otherwise it's more of a WYSIKOWYG (What you see is kind of what
you get) than WYSIWYG ;)
Later,
-- Scott
|
|
|
| Re: false equals true ?! [message #595204 is a reply to message #48104] |
Wed, 14 July 2004 09:52 |
| Eclipse User |
|
|
|
>
> The thing I do not yet understand is why the code isn't simply executed.
> There might be good reasons.
>
Besides the fact that VE may (at some point) be extended to searlize and
work from none-Java source, Executing code is a slippery slope :-(
It opens up many issues like, what areas of the code will you execute
(most of the time when you update/develop code, the CU is not compilable)?
From your example above:
if(getRandomBoolean()){
jTextField.setBackground (java.awt.Color.RED);
}else{
jTextField.setBackground (java.awt.Color.BLUE);
}
What if getRandomBoolean() requires main() to set up some context, or
what if getRandomBoolean uses the network to check IBM's stock to make a
decision (in this case it should be BLUE and veryBLUE ;-) ... will you
require network connection, or a DB connection or .... to figure out
what color to set in the PropertySheet for jTextField? And let say,
that you want to use VE to set the jTextField's color to Red. What kind
of code should VE generate?... should it change the getRandomBoolean to
check a MS symbol instead??? ... just trying to make a point ;-) Red
is a great color.
The way VE works today is by modeling the source (Java src. for now)
Editor and views work with the model.
The model reflects design time WYSIWYG. VE has a set of configurable
rules that drives its parsing....
|
|
|
| Re: false equals true ?! [message #595298 is a reply to message #50179] |
Thu, 15 July 2004 10:17 |
| Eclipse User |
|
|
|
Gili Mendel schrieb:
>
>>
>> The thing I do not yet understand is why the code isn't simply executed.
>> There might be good reasons.
>>
>
> Besides the fact that VE may (at some point) be extended to searlize and
> work from none-Java source, Executing code is a slippery slope :-(
> It opens up many issues like, what areas of the code will you execute
> (most of the time when you update/develop code, the CU is not compilable)?
Eclipse knows when the code is compilable, right?
So don't execute if it is not compilable -- it isn't possible anyway.
> From your example above:
>
> if(getRandomBoolean()){
> jTextField.setBackground (java.awt.Color.RED);
> }else{
> jTextField.setBackground (java.awt.Color.BLUE);
> }
>
>
> What if getRandomBoolean() requires main() to set up some context, or
> what if getRandomBoolean uses the network to check IBM's stock to make a
> decision (in this case it should be BLUE and veryBLUE ;-) ... will you
> require network connection, or a DB connection or .... to figure out
> what color to set in the PropertySheet for jTextField? And let say,
> that you want to use VE to set the jTextField's color to Red. What kind
> of code should VE generate?... should it change the getRandomBoolean to
> check a MS symbol instead??? ... just trying to make a point ;-) Red
> is a great color.
Ha, very funny.
Lets say I put my redOrBlue code or your veryBlueStock code into my own
Bean class, in the constructor, in setVisible, whatever. If I know use
that bean in VE ("Choose Bean") that code *is* executed: the net is
contacted, IBM's stock is checked, the code may not halt, etc.
So what is the difference? Why is it executed in the bean code but not
in the code using that bean? Are people using the beans supposed to
be more stupid than those writing the beans?
thanx!
Marcus
|
|
|
| Re: false equals true ?! [message #595341 is a reply to message #50411] |
Fri, 16 July 2004 09:56 |
| Eclipse User |
|
|
|
>
> Eclipse knows when the code is compilable, right?
> So don't execute if it is not compilable -- it isn't possible anyway.
>
Yes it is, but there is much that is left to be done.
The Java Editor will reconcile() and annotate the editor in a background
thread, but it will not update the .classes involved nor will it
generate bite code for the various impacted CUs.
To keep on running without kicking off frequent slow (disk bound)
builds, we will have to use hot swaps (similar to a debugger), something
that is not bullet proof.
>> From your example above:
>>
>> if(getRandomBoolean()){
>> jTextField.setBackground (java.awt.Color.RED);
>> }else{
>> jTextField.setBackground (java.awt.Color.BLUE);
>> }
>>
>>
>> What if getRandomBoolean() requires main() to set up some context, or
>> what if getRandomBoolean uses the network to check IBM's stock to make
>> a decision (in this case it should be BLUE and veryBLUE ;-) ... will
>> you require network connection, or a DB connection or .... to figure
>> out what color to set in the PropertySheet for jTextField? And let
>> say, that you want to use VE to set the jTextField's color to Red.
>> What kind of code should VE generate?... should it change the
>> getRandomBoolean to check a MS symbol instead??? ... just trying to
>> make a point ;-) Red is a great color.
>
>
> Ha, very funny.
>
> Lets say I put my redOrBlue code or your veryBlueStock code into my own
> Bean class, in the constructor, in setVisible, whatever. If I know use
> that bean in VE ("Choose Bean") that code *is* executed: the net is
> contacted, IBM's stock is checked, the code may not halt, etc.
>
Yes... this is the reason for Beans.isDesign() ... it is up for the bean
provider to provide design vs. run time instantiation.
> So what is the difference? Why is it executed in the bean code but not
> in the code using that bean? Are people using the beans supposed to
> be more stupid than those writing the beans?
>
Ultimately, the bean is to be used in run time, and the code that is
generated is generated in design time (where the environment is not
suitable to fully drive the bean) for run time consumption.
Hence the complexity. It would not always be obvious where/what to
generate. For the background color above... if you use the Property
Sheet to change the color to Red; where should we generate it ? On both
sides of the if(), update the getRandomBoolean() semantics? ... it can
get hairy quite quickly.
The Design/RunTime approach is to keep things simple and predictable.
It has its flaws... but merits as well.
|
|
|
Goto Forum:
Current Time: Thu May 08 16:33:33 EDT 2025
Powered by FUDForum. Page generated in 0.14210 seconds |
Home