On Wed, Nov 24, 2010 at 4:22 AM, Jeremy Thomerson wrote:
> This vote is to release wicket 1.4.14. This is a bugfix release on the
> 1.4.x (stable) branch.
>
> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.14/
> Artifacts: http://people.apache.org/~jrthomerson/wicket-1.4.14/di
which method name?
I currently only have a tagging interface that tags this behavior...
On Wed, Nov 24, 2010 at 03:00, Igor Vaynberg wrote:
> i just fixed it in trunk. in 1.4 we dont really have a choice but to
> add the mixin interface, but can you at least make the method name
> match?
>
> che
Ok, I need sleep. Back to our regularly-scheduled programming.
On Tue, Nov 23, 2010 at 10:36 PM, Jeremy Thomerson
wrote:
> On Tue, Nov 23, 2010 at 10:28 PM, James Carman
> wrote:
>> If you're going to make it an abstract class, why not change the name,
>> too? The "I" presumably means "interfa
[WICKET-3166] - isVisibleInHierarchy() possibly unnecessarily checks
children whose parents are invisible?
I'm +1 to revert the change at this ticket because we start to make
unnecessary visibility checks due an recursion that always stack calls to
every component parent. I know it is important to
> [WICKET-3166] - isVisibleInHierarchy() possibly unnecessarily checks
> children whose parents are invisible?
> I'm +1 to revert the change at this ticket because we start to make
> unnecessary visibility checks due an recursion that always stack calls to
> every component parent. I know it is imp
Hi Martin, I know your concern, but is the visitor responsibility to don't
go deeper in not visible components if your logic require such restriction.
I attached on the ticket an test case demonstrating how it can be done.
Basically you provide an implementation to the IFormVisitorParticipant
inter
Hi!
> Hi Martin, I know your concern, but is the visitor responsibility to don't
> go deeper in not visible components if your logic require such restriction.
> I attached on the ticket an test case demonstrating how it can be done.
> Basically you provide an implementation to the IFormVisitorPart
Yes, would make more sense if the Form#inputChanged invoke an
visitVisibleAndEnabledFormComponentsPostOrder method.
Is ok to provide and use such API in the 1.4?
But even without this visitor change in the 1.4, you can use the
IFormVisitorParticipant interface to stop it from going deeper.
On Wed,
> Yes, would make more sense if the Form#inputChanged invoke an
> visitVisibleAndEnabledFormComponentsPostOrder method.
> Is ok to provide and use such API in the 1.4?
> But even without this visitor change in the 1.4, you can use the
> IFormVisitorParticipant interface to stop it from going deeper
+1 for release.
I can confirm that memory leak bug is solved.
bye!
This vote is to release wicket 1.4.14. This is a bugfix release on the
1.4.x (stable) branch.
Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.14/
Artifacts: http://people.apache.org/~jrthomerson/wicket-1.4.14
+1
cheers,
Steve
On 24/11/2010, at 2:22 PM, Jeremy Thomerson wrote:
> This vote is to release wicket 1.4.14. This is a bugfix release on the
> 1.4.x (stable) branch.
>
> Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.14/
> Artifacts: http://people.apache.org/~jrthomerson/wic
+1
On Wed, Nov 24, 2010 at 03:22, Igor Vaynberg wrote:
> the ibehavior interface has become somewhat cluttered and a lot of
> methods in it can have a nice default implementation that works for
> 99% of the usecases. there is no longer a point to having it as an
> interface. this vote is to
>
> -
i added boolean canCallListenerInterface(Component component) to ibehavior
-igor
On Wed, Nov 24, 2010 at 12:54 AM, Johan Compagner wrote:
> which method name?
>
> I currently only have a tagging interface that tags this behavior...
>
> On Wed, Nov 24, 2010 at 03:00, Igor Vaynberg wrote:
>> i ju
yes that i did see in 1.5
but in 1.4 i guess the only thing we can do is just introduce that
IIgnoreDisabledComponentBehavior interface (that doesnt have any
method)
(or something the same with a different name, any recomendations?)
johan
On Wed, Nov 24, 2010 at 16:57, Igor Vaynberg wrote:
> i
IWontDoAnythingWhenTheComponentIsDisabledBehavior
IMASlackerBehavior
Martijn
On Wed, Nov 24, 2010 at 5:12 PM, Johan Compagner wrote:
> yes that i did see in 1.5
> but in 1.4 i guess the only thing we can do is just introduce that
> IIgnoreDisabledComponentBehavior interface (that doesnt have any
Why don't simple change the AbstractBehavior default isEnabled
implementation to respect the component state, like:
public boolean isEnabled(Component component)
{
return component.isEnabled();
}
It would solve the problem at the ticket. IMO the proposed interface is
prolix be
that first one is a perfect name, except that the intent is that it
works just the opposite!
:)
On Wed, Nov 24, 2010 at 17:20, Martijn Dashorst
wrote:
> IWontDoAnythingWhenTheComponentIsDisabledBehavior
> IMASlackerBehavior
>
> Martijn
>
> On Wed, Nov 24, 2010 at 5:12 PM, Johan Compagner wrote:
i dont think the name of the mixin matters much because 1.5 is out
soonish. IListenerInterfaceTarget { canCallListenerInterface()} is not
so bad.
-igor
On Wed, Nov 24, 2010 at 8:12 AM, Johan Compagner wrote:
> yes that i did see in 1.5
> but in 1.4 i guess the only thing we can do is just introd
And then completely remove the check if the component is disabled i guess?
That would work for me but then if users dont really call super() when
they have there own enable logic that would mean it would always be
called..
(because now it just returns true so people could think i dont need to
call
ok then i check my changes in for 1.4
So that at least people that use 1.4 (like us) can use that one for now.
I can add a note in the doc that this will be replaced by 1.5 completely..
On Wed, Nov 24, 2010 at 17:15, Igor Vaynberg wrote:
> i dont think the name of the mixin matters much becaus
On Wed, Nov 24, 2010 at 2:24 PM, Johan Compagner wrote:
> And then completely remove the check if the component is disabled i guess?
>
exactly
> That would work for me but then if users dont really call super() when
> they have there own enable logic that would mean it would always be
> called.
no need to commit into 1.4.14 branch. the release has already been
cut. if we have to recut it we would do it from 1.4.x branch.
-igor
On Wed, Nov 24, 2010 at 10:27 AM, wrote:
> Author: pedro
> Date: Wed Nov 24 18:27:33 2010
> New Revision: 1038752
>
> URL: http://svn.apache.org/viewvc?rev=1038
is it just me were several tests on trunk are failing?
Juergen
Hi,
I just updated my app to latest 1.5 and the following exception happened:
org.apache.wicket.WicketRuntimeException: No Page found for component
[ShortcutsPanel [Component id = componentItem]]
at org.apache.wicket.Component.getPage(Component.java:1787)
at org.apache.wicket.MarkupContainer.getM
Hi,
for me this is the build output:
Failed tests:
testLicenseHeaders(org.apache.wicket.util.license.ApacheLicenceHeaderTest)
Tests in error:
testDisabledBehaviorRequest(org.apache.wicket.BehaviorRequestTest)
testDisabled(org.apache.wicket.DisabledComponentTest)
testSubmitDisabledOuterForm(org.
Same here.
It's the new logic for disabled behaviors.
Too late for me to take a look today...
On Wed, Nov 24, 2010 at 10:00 PM, Juergen Donnerstag <
juergen.donners...@gmail.com> wrote:
> is it just me were several tests on trunk are failing?
>
> Juergen
>
Excepted is:
- if a component provides its own markup either via subclassing
getMarkup() or is expected to have associated markup (e.g. Panel) =>
markup available in ctor
- Component.onMarkupAttached() is invoked as soon as the markup is
available. E.g. a child to a Panel. child.onMarkupAttached()
27 matches
Mail list logo
