Community
Participate
Working Groups
Problem: Property values are cached at development time if a set method is present in the source code. In the Visual Editor if we click on a visual component and look at the property list, the property value there does not come from executing the getFoo method, but from cache if setFoo is present in the source code. Concrete example: Assume we have a bean containing property foo with the methods: public String getFoo(){ logThisCall(); //execute some method to log this call somewhere return foo; } public void setFoo(String s){ foo = s ; } The problem is that once the setFoo method is present in the source code, the getFoo method is NEVER called again at development time to obtain the property value, but rather that value is obtained from some cache. The problem is that even at development time, the developer might count on the getFoo being called at all times (in our case to continue the logging). This is bad enough in the example above, but I could think of much worse cases in which the returned value from the get is something like 'foo + " " + new java.util.Date()' in which case getting the value from the cache completely throws the value off and "freezes" it. Long and short of it, whereas caching the value is nice, it ends up creating major problems for beans that are not straigt POJOs, and that could pose major consistency problems with developers. My suggestion: please eliminate this caching behavior COMPLETELY and allow the getFoo method to always execute. Thanks, David Pociu
Sorry, but that isn't the way the VE works. What it shows is the value that was "set". This is the value that was set in the initialize method, which is what the VE is trying to do, to show what it looks like right after it is initialized. It isn't meant to simulate a running program which changes over time. It is a snapshot of the initial state.
OK, I understand that is how it works, but can I please have you reconsider? Should the property sheet not show the actual value of the getFoo() call? VE should not just sit there and assume it knows what's best for the bean and completely discard any internal formatting that the getFoo() method does. My point is simply that after each setFoo, a getFoo should be called to obtain the value to display in the property sheet. I would also like to point out that all other visual IDEs in the market (JBuilder, Netbeans, etc.) respect the bean's code when it comes to displaying values in the property sheets, and actually call the getFoo method of the bean each time the property is refreshed in the sheet (even when it simply gets focus at development time and the property sheet is refreshed). VE only does that for beans that did not have the set method called in the source code yet. I sincerely hope that you would reconsider your decision on this issue (as visual plugins will probably depend on this behavior - our certainly does (http://www.insitechinc.com). Thank you, David Pociu
David, We took the decision that a JavaBeans property is a read and write attribute where the set method is the same as the get method. What you are describing is a scenario where the set method isn't the same as the result of the get method. One thing you could do is add another property that you set, and had the unset one return the computed value because the two were unknown to be related by the VE (there'd be two pairs of getters and setters). As Rich describes though, for the current property sheet for any set property (which is indicated by a > symbol beside it) the value that is explicitly set is the one displayed. All unset values are fetched (because the VE knows nothing about them).
Right, Joe. Thanks for your answer. I actually ended up putting this workaround in our product a few days ago, but as you can imagine it results in a "bogus" property whose only purpose in life is to not be set by anyone, just so it can be "gotten". And since this will show up in all other IDEs as a property, it's not the most professional thing to do <g>. The rub comes for us in the property editor where we're interested in the actual get method being executed and having that "processed" value, not what was set. As long as there is hope that you guys will address this at some point, I have no problem documenting the problem with a link to this post, and explaining that the workaround will at some point go away. Thanks for seriously considering this issue David
This is being marked as "won't fix" as part of a bugzilla clean up, to remove very old enhancement requests .... since if it hasn't been done by now, there's near zero chance it every will be. If I have mistakenly closed a bug that is still very much a current issue, please accept my apologies and re-open and clarify what the current issue it.
Moving to VE.
