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 the
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
wrote:
> Igor,
>
> I agree that there are places that using onConfigure / setVisible may be
> better
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 a
> 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
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
wrote:
> That's actually also an example of why I prefer overriding isVisib
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 contr
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
On Thu, Dec 2, 2010 at 9:36 PM, Clint Checketts 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 expense isn't the
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. A
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.
Initializi
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 wrote:
> I have a different point of view, the HTTP imposes us some limitations
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, 20
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 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 wrote:
> currently we only invoke configure before
On Tue, Nov 30, 2010 at 12:55 AM, Eelco Hillenius
wrote:
> On Mon, Nov 29, 2010 at 11:51 PM, Juergen Donnerstag
> wrote:
>> I'm curious. Which ideas would you steal from SiteBricks and JaxRS?
There are also many interesting ideas in Apache Sling. How it uses
OSGi for modularization, comes with a
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 wrot
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
(ev
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
Com
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 link.
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(re
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);
}
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 wrote:
> I understand the concern about possible isVisible implementations like
>
> isVisible(return currentlyTime < 10:00:00;) //imagine this co
I understand the concern about possible isVisible implementations like
isVisible(return currentlyTime < 10:00:00;) //imagine this component being
rendered at 09:59:59
isVisible(return dao.list().size() > 0);// performance issues
But maybe we can have the best from both approaches. This is an copy
On Mon, Nov 29, 2010 at 11:51 PM, Juergen Donnerstag
wrote:
> I'm curious. Which ideas would you steal from SiteBricks and JaxRS?
I think SiteBricks strikes a nice balance between Wicket's and
Tapestry's (or JSF's/ ASP.NET's) programming models. I like that it
allows *some* logic in the templates
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
I'm curious. Which ideas would you steal from SiteBricks and JaxRS?
Juergen
On Tue, Nov 30, 2010 at 5:51 AM, Eelco Hillenius
wrote:
> On Mon, Nov 29, 2010 at 7:45 PM, richard emberson
> wrote:
>> If wicket was going to be coded over again, would you make
>> isEnabled and/or isVisible final meth
On Mon, Nov 29, 2010 at 7:45 PM, richard emberson
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
> 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 val
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 for the
> 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.
Hmmm, yeah, I can see how that
> 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 rat
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
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
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
how so? we added something new that we think will work better.
-igor
On Mon, Nov 29, 2010 at 12:45 PM, James Carman
wrote:
> On Mon, Nov 29, 2010 at 1:13 PM, Eelco Hillenius
> wrote:
>> Niether is evil. It has potential pitfalls, which you should just be
>> aware of. We use such overrides all o
On Mon, Nov 29, 2010 at 1:13 PM, Eelco Hillenius
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).
>
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 c
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 wi
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 wrote:
> On
On Mon, Nov 29, 2010 at 9:35 AM, Sven Meier 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.
>
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 over
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, Dou
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
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/
44 matches
Mail list logo