overriding isVisible bad?
Igor posted a comment to this bug saying that overriding isVisible() is evil https://issues.apache.org/jira/browse/WICKET-3171 I was surprised by this and am curious to hear more. D/
Re: overriding isVisible bad?
The recommended way since a few 1.4 releases is to override onConfigure() and call setVisible(true|false) depending on your conditions. On Mon, Nov 29, 2010 at 4:49 PM, Douglas Ferguson doug...@douglasferguson.us wrote: Igor posted a comment to this bug saying that overriding isVisible() is evil https://issues.apache.org/jira/browse/WICKET-3171 I was surprised by this and am curious to hear more. D/
Re: overriding isVisible bad?
Can you explain why? We have done this all over the place. D/ On Nov 29, 2010, at 10:00 AM, Martin Grigorov wrote: The recommended way since a few 1.4 releases is to override onConfigure() and call setVisible(true|false) depending on your conditions. On Mon, Nov 29, 2010 at 4:49 PM, Douglas Ferguson doug...@douglasferguson.us wrote: Igor posted a comment to this bug saying that overriding isVisible() is evil https://issues.apache.org/jira/browse/WICKET-3171 I was surprised by this and am curious to hear more. D/
Re: overriding isVisible bad?
Hi Douglas, WICKET-3171 describes a problematic case, where visibility of a component changes while its form is being processed. In our projects we're overriding isVisible() where appropriate and never encountered a similar problem. I'd say WICKET-3171 is the rare 5% usecase. What's next, is overriding isEnabled() going to be declared evil too? ;) Sven On Mon, 2010-11-29 at 11:22 -0600, Douglas Ferguson wrote: Can you explain why? We have done this all over the place. D/ On Nov 29, 2010, at 10:00 AM, Martin Grigorov wrote: The recommended way since a few 1.4 releases is to override onConfigure() and call setVisible(true|false) depending on your conditions. On Mon, Nov 29, 2010 at 4:49 PM, Douglas Ferguson doug...@douglasferguson.us wrote: Igor posted a comment to this bug saying that overriding isVisible() is evil https://issues.apache.org/jira/browse/WICKET-3171 I was surprised by this and am curious to hear more. D/
Re: overriding isVisible bad?
Niether is evil. It has potential pitfalls, which you should just be aware of. We use such overrides all over the place and never have problems with them either. :-) Avoiding it is safer, but also more verbose (in 1.3.x at least). Eelco On Mon, Nov 29, 2010 at 9:49 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:35 AM, Sven Meier s...@meiers.net wrote: Hi Douglas, WICKET-3171 describes a problematic case, where visibility of a component changes while its form is being processed. In our projects we're overriding isVisible() where appropriate and never encountered a similar problem. I'd say WICKET-3171 is the rare 5% usecase. What's next, is overriding isEnabled() going to be declared evil too? ;) yes -igor Sven On Mon, 2010-11-29 at 11:22 -0600, Douglas Ferguson wrote: Can you explain why? We have done this all over the place. D/ On Nov 29, 2010, at 10:00 AM, Martin Grigorov wrote: The recommended way since a few 1.4 releases is to override onConfigure() and call setVisible(true|false) depending on your conditions. On Mon, Nov 29, 2010 at 4:49 PM, Douglas Ferguson doug...@douglasferguson.us wrote: Igor posted a comment to this bug saying that overriding isVisible() is evil https://issues.apache.org/jira/browse/WICKET-3171 I was surprised by this and am curious to hear more. D/
Re: overriding isVisible bad?
To expand, unless I'm missing something (new?), things are really only problematic when both the mutable value and the override are mixed. In a way, I think that using the override is 'more pure', as it's a simple function that is executed when needed, whereas mutable state can be harder to deal with when trying to figure out how it got to be in that state. So, sorry Igor, but we disagree on this one. Eelco On Mon, Nov 29, 2010 at 10:13 AM, Eelco Hillenius eelco.hillen...@gmail.com wrote: Niether is evil. It has potential pitfalls, which you should just be aware of. We use such overrides all over the place and never have problems with them either. :-) Avoiding it is safer, but also more verbose (in 1.3.x at least). Eelco On Mon, Nov 29, 2010 at 9:49 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:35 AM, Sven Meier s...@meiers.net wrote: Hi Douglas, WICKET-3171 describes a problematic case, where visibility of a component changes while its form is being processed. In our projects we're overriding isVisible() where appropriate and never encountered a similar problem. I'd say WICKET-3171 is the rare 5% usecase. What's next, is overriding isEnabled() going to be declared evil too? ;) yes -igor Sven On Mon, 2010-11-29 at 11:22 -0600, Douglas Ferguson wrote: Can you explain why? We have done this all over the place. D/ On Nov 29, 2010, at 10:00 AM, Martin Grigorov wrote: The recommended way since a few 1.4 releases is to override onConfigure() and call setVisible(true|false) depending on your conditions. On Mon, Nov 29, 2010 at 4:49 PM, Douglas Ferguson doug...@douglasferguson.us wrote: Igor posted a comment to this bug saying that overriding isVisible() is evil https://issues.apache.org/jira/browse/WICKET-3171 I was surprised by this and am curious to hear more. D/
Re: overriding isVisible bad?
ive run into plenty of weird problems with overrides, but maybe because this was in a high concurrency app where data changed frequently. the problems arise from the fact that the value returned from isvisible() can change while we are doing traversals, etc. eg we run a traversal for all visible components and put them in a list. later we iterate over the list and try to render these components. the render function also checks their visibility and if they are no longer visible it throws an exception. if isvisible() override depends on some external factor like the database there is a small window where the value can change and now you can have a weird exception: such as tried to invoke a listener on a component that is not visible or not enabled. these are very intermittent and damn near impossible to reproduce. another problem is performance. isvisible() is called multiple times during the request and if it depends on the database it can be a performance problem. in fact a couple of users have complained about this on the list in the past. at least now we have an easy solution for them - use onconfigure(). so as of right now the developers have two choices: override isvisible() and potentially suffer the consequences. or, override onconfigure() and set visibility there in a more deterministic fashion. -igor On Mon, Nov 29, 2010 at 10:21 AM, Eelco Hillenius eelco.hillen...@gmail.com wrote: To expand, unless I'm missing something (new?), things are really only problematic when both the mutable value and the override are mixed. In a way, I think that using the override is 'more pure', as it's a simple function that is executed when needed, whereas mutable state can be harder to deal with when trying to figure out how it got to be in that state. So, sorry Igor, but we disagree on this one. Eelco On Mon, Nov 29, 2010 at 10:13 AM, Eelco Hillenius eelco.hillen...@gmail.com wrote: Niether is evil. It has potential pitfalls, which you should just be aware of. We use such overrides all over the place and never have problems with them either. :-) Avoiding it is safer, but also more verbose (in 1.3.x at least). Eelco On Mon, Nov 29, 2010 at 9:49 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:35 AM, Sven Meier s...@meiers.net wrote: Hi Douglas, WICKET-3171 describes a problematic case, where visibility of a component changes while its form is being processed. In our projects we're overriding isVisible() where appropriate and never encountered a similar problem. I'd say WICKET-3171 is the rare 5% usecase. What's next, is overriding isEnabled() going to be declared evil too? ;) yes -igor Sven On Mon, 2010-11-29 at 11:22 -0600, Douglas Ferguson wrote: Can you explain why? We have done this all over the place. D/ On Nov 29, 2010, at 10:00 AM, Martin Grigorov wrote: The recommended way since a few 1.4 releases is to override onConfigure() and call setVisible(true|false) depending on your conditions. On Mon, Nov 29, 2010 at 4:49 PM, Douglas Ferguson doug...@douglasferguson.us wrote: Igor posted a comment to this bug saying that overriding isVisible() is evil https://issues.apache.org/jira/browse/WICKET-3171 I was surprised by this and am curious to hear more. D/
Re: overriding isVisible bad?
how so? we added something new that we think will work better. -igor On Mon, Nov 29, 2010 at 12:45 PM, James Carman ja...@carmanconsulting.com wrote: On Mon, Nov 29, 2010 at 1:13 PM, Eelco Hillenius eelco.hillen...@gmail.com wrote: Niether is evil. It has potential pitfalls, which you should just be aware of. We use such overrides all over the place and never have problems with them either. :-) Avoiding it is safer, but also more verbose (in 1.3.x at least). Well, in the past, the canned answer was override isEnabled/isVisible. Changing that paradigm and doing a complete 180 is troubling.
Re: overriding isVisible bad?
I am glad we have something new that's better, but going from do this to this is evil is the troubling part. A lot of us have a lot of code that is based on the previous advice. Now declaring that code is evil is kind of scary, especially in the middle of a major version. If something is evil, then we should probably try to avoid it, so what do we do, go clean up all of our existing code (and re-test it)? On Mon, Nov 29, 2010 at 3:52 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: how so? we added something new that we think will work better. -igor On Mon, Nov 29, 2010 at 12:45 PM, James Carman ja...@carmanconsulting.com wrote: On Mon, Nov 29, 2010 at 1:13 PM, Eelco Hillenius eelco.hillen...@gmail.com wrote: Niether is evil. It has potential pitfalls, which you should just be aware of. We use such overrides all over the place and never have problems with them either. :-) Avoiding it is safer, but also more verbose (in 1.3.x at least). Well, in the past, the canned answer was override isEnabled/isVisible. Changing that paradigm and doing a complete 180 is troubling.
Re: overriding isVisible bad?
if it works for you keep it. all we did was give you a better/safer alternative. -igor On Mon, Nov 29, 2010 at 12:59 PM, James Carman ja...@carmanconsulting.com wrote: I am glad we have something new that's better, but going from do this to this is evil is the troubling part. A lot of us have a lot of code that is based on the previous advice. Now declaring that code is evil is kind of scary, especially in the middle of a major version. If something is evil, then we should probably try to avoid it, so what do we do, go clean up all of our existing code (and re-test it)? On Mon, Nov 29, 2010 at 3:52 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: how so? we added something new that we think will work better. -igor On Mon, Nov 29, 2010 at 12:45 PM, James Carman ja...@carmanconsulting.com wrote: On Mon, Nov 29, 2010 at 1:13 PM, Eelco Hillenius eelco.hillen...@gmail.com wrote: Niether is evil. It has potential pitfalls, which you should just be aware of. We use such overrides all over the place and never have problems with them either. :-) Avoiding it is safer, but also more verbose (in 1.3.x at least). Well, in the past, the canned answer was override isEnabled/isVisible. Changing that paradigm and doing a complete 180 is troubling.
Re: overriding isVisible bad?
Well, in the past, the canned answer was override isEnabled/isVisible. Changing that paradigm and doing a complete 180 is troubling. I don't think that's the case though. We've had many discussions on this list (and in private even), and we've always felt uneasy about supporting two rather than one way of achieving the same thing. Ultimately we decided to support both, but there have been several times where we were near making isVisible final. Eelco
Re: overriding isVisible bad?
If wicket was going to be coded over again, would you make isEnabled and/or isVisible final methods? Might the non-finality of the methods be deprecated in some future release? The majority of the isXXX methods in Component are final. Richard -- Quis custodiet ipsos custodes
Re: overriding isVisible bad?
it has nothing to do with requiring a function to be set. the problem is that the function is free to change its mind at any moment, but we rely on it returning the same value during some fixed periods of time. if we truly want to support isvisible() we would need to cache/memoize the value for the period we assume it to be constant. Yes, that's what I'm saying. but, defining these caching regions is very difficult, and maintaining them as we work on core we be even more difficult still. I don't think it would be that difficult, but certainly not something worth doing at this stage. Eelco
Re: overriding isVisible bad?
On Mon, Nov 29, 2010 at 7:45 PM, richard emberson richard.ember...@gmail.com wrote: If wicket was going to be coded over again, would you make isEnabled and/or isVisible final methods? If *I* would do it, I'd probably write it for Scala and lean more heavily on functions rather than mutable state. I'd also steal a few ideas from other frameworks like SiteBricks and JaxRS, have better 'native' JavaScript support (but definitively not going the GWT route), make choosing between stateful and stateless more explicit and up-front, support client-side state (but not like JSF or ASP.NET do it), etc. I gathered plenty of ideas of how I'd do a new framework, but I'm not even going to attempt that anyway :-) After having done a few projects with alternatives (GWT, pure JS/ JaxRS), I'm totally sold on Wicket again. It's not a perfect framework, but sure beats the hell out of most other frameworks when it comes to productivity and maintainability. :-) Eelco
Re: overriding isVisible bad?
I'm curious. Which ideas would you steal from SiteBricks and JaxRS? Juergen On Tue, Nov 30, 2010 at 5:51 AM, Eelco Hillenius eelco.hillen...@gmail.com wrote: On Mon, Nov 29, 2010 at 7:45 PM, richard emberson richard.ember...@gmail.com wrote: If wicket was going to be coded over again, would you make isEnabled and/or isVisible final methods? If *I* would do it, I'd probably write it for Scala and lean more heavily on functions rather than mutable state. I'd also steal a few ideas from other frameworks like SiteBricks and JaxRS, have better 'native' JavaScript support (but definitively not going the GWT route), make choosing between stateful and stateless more explicit and up-front, support client-side state (but not like JSF or ASP.NET do it), etc. I gathered plenty of ideas of how I'd do a new framework, but I'm not even going to attempt that anyway :-) After having done a few projects with alternatives (GWT, pure JS/ JaxRS), I'm totally sold on Wicket again. It's not a perfect framework, but sure beats the hell out of most other frameworks when it comes to productivity and maintainability. :-) Eelco
