Component can continue having the public isVisible/Enabled method always
returning its correct state avaliable to use. Just the core request code
will use an safe version that can be: isVisible/EnabledOnRequest. I really
value an request cycle protected against volatile component states.
I like
Igor,
I agree that there are places that using onConfigure / setVisible may be
better than overriding isVisible. However, I often have the following type
of scenario, and wonder how you would suggest doing it without overriding
isVisible:
Situation: one component depends on the visibility of
afair this is already explained in the javadoc of onconfigure
label { onconfigure() { link.onconfigure(); setvisible(link.isvisible()); }}
-igor
On Mon, Dec 6, 2010 at 7:35 AM, Jeremy Thomerson
jer...@wickettraining.com wrote:
Igor,
I agree that there are places that using onConfigure /
ldm also doesnt always work nicely. suppose you have a delete button
that is only visible if the record exists. the page renders, the user
clicks the button. the onclick handler invoked, and isvisible is
checked - at which point it is true. the record is deleted in the
onclick handler, the page is
That's actually also an example of why I prefer overriding isVisible:
I can have that button and other widgets (maybe completely unrelated)
widgets that depend on a particular state (like whether a record
exists), and a function (override of isVisible) will always yield the
correct result. In
huh? that doesnt make any sense. the callbacks like onconfigure simply
give you checkpoints for calculating and caching visibility rather
then calculating every time.
-igor
On Fri, Dec 3, 2010 at 5:12 PM, Eelco Hillenius
eelco.hillen...@gmail.com wrote:
That's actually also an example of why I
huh? that doesnt make any sense. the callbacks like onconfigure simply
give you checkpoints for calculating and caching visibility rather
then calculating every time.
I wasn't arguing against onConfigure (which is a fine trade-off) but
saw an example of where relying on just setVisible would
What about using onconfigure to replace loadabledetachablemodel ? We
have had some trouble with loadabledetachablemodels when their state
is frozen before a dependent model has been initialized (for example)
and we need to call model.detach() from within our code, which seems
bit hacky.
Yesterday a friend following this thread pointed out that we should rethink
our overriding of onVisible and use onConfigure. I've used
LoadabledDetachableModels to cache the value used in my isVisible/isEnabled
overriding so changing values mid request aren't a problem. That is its
whole purpose.
On Thu, Dec 2, 2010 at 9:36 PM, Clint Checketts checke...@gmail.com wrote:
While I appreciate having onConfigure as an option it seems like overriding
isVisible is still the cleaner and clearer way. Folks just need to follow
the rule that expensive calls should be contained in an LDM.
The
On of the main problems I see with onConfigure() is that is a general
'configuration' method. In our code, we ofter create an anonymous inner-class,
overriding the isVisible() method. These methods often look like 'return
super.isVisible() someOtherCondition;'. This is a lot more difficult to
so how is it different if they can still override something that needs
to be checked all the time?
-igor
On Tue, Nov 30, 2010 at 8:02 AM, Pedro Santos pedros...@gmail.com wrote:
I understand the concern about possible isVisible implementations like
isVisible(return currentlyTime 10:00:00;)
An implementation idea:
Component {
public final void configure()
{
if (!getFlag(FLAG_CONFIGURED))
{
setVisible_NoClientCode(isVisible()); //we only check the user
isVisible in here
onConfigure();
setFlag(FLAG_CONFIGURED, true);
Jus to get it right ... is the following statement correct?
isVisible() will work as expected when the criteria for visibility does not
change during render
Am 30.11.2010 um 17:02 schrieb Pedro Santos:
I understand the concern about possible isVisible implementations like
isVisible(return
there are other places that should be checked though. for example
before we invoke a listener on the component we should check again to
make sure that visibility hasnt changed. eg if visibility depends on
some property of the user clicking the link that changed between
render and clicking the
Yes, for instance if an component contribute to the HTML header with an CSS
resource, and if this component return false to the isVisible test when the
HtmlHeaderContainer is traversing the component hierarchy requesting visible
components to contribute to header, and later return true when the
If user click an link, it will change the value of some property at the
process_event request cycle step. Then the processor will go to the respond
step, will invoke every component before render method which will end up
invoking the Component#configure and updating the visibility/enabled state
currently we only invoke configure before the render. this would mean
we would have to invoke it before processing a listener, clearing the
cache, and then invoking it again before render. i wonder if that is
enough places to invoke it
-igor
On Tue, Nov 30, 2010 at 9:15 AM, Pedro Santos
On Tue, Nov 30, 2010 at 12:55 AM, Eelco Hillenius
eelco.hillen...@gmail.com wrote:
On Mon, Nov 29, 2010 at 11:51 PM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
I'm curious. Which ideas would you steal from SiteBricks and JaxRS?
There are also many interesting ideas in Apache Sling.
I need to look better on which core components are relying on an updated
visibility/enabled state at the process event time, and why the last
rendered state wouldn't be enough to them to work nicely.
On Tue, Nov 30, 2010 at 3:19 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
currently we only
an easy example is security.
a user views a page that allows them to delete another user
meanwhile their permissions are tweaked and they can no longer delete
other users
half an hour later the user clicks the delete button - this should
fail, but wont if we are using last-rendered state.
-igor
I have a different point of view, the HTTP imposes us some limitations, we
will hardly have an good synchronization between the component state on
browser and server using only HTTP conversation. So it is mandatory the
service layer to respect the described security restriction.
On Tue, Nov 30,
i would be happy if that was good enough. in the past it hasnt been,
thats why we have the current solution. maybe we can try it again in
1.5 and see what happens.
-igor
On Tue, Nov 30, 2010 at 11:44 AM, Pedro Santos pedros...@gmail.com wrote:
I have a different point of view, the HTTP imposes
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
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,
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
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
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
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
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
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,
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
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
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
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
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
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
37 matches
Mail list logo
