Re: NoSuchMethodError after upgrading to 6.9.0

[Maxim Solodovnik]

Thanks, will double-check!


On Tue, Jul 2, 2013 at 1:51 PM, Martin Grigorov wrote:

> Hi Maxim,
>
> Wicket depends on Joda Time 2.0.
> I see this method in 2.0 and in 2.2 (
>
> http://joda-time.sourceforge.net/apidocs/src-html/org/joda/time/LocalDate.html#line.998
> ).
>
> Check your dependencies. Maybe you have an older version of Joda Time in
> your app.
>
>
> On Tue, Jul 2, 2013 at 9:17 AM, Maxim Solodovnik  >wrote:
>
> > same time DateTextField works as expected :(
> >
> > after switching org.apache.wicket:wicket-datetime to rev=6.8.0 everything
> > works as expected
> >
> >
> > On Tue, Jul 2, 2013 at 12:12 PM, Maxim Solodovnik  > >wrote:
> >
> > > Hello All,
> > >
> > > Just have upgraded to 6.9.0 and start getting:
> > >
> > > Caused by: java.lang.NoSuchMethodError:
> > > org.joda.time.LocalDate.toDate()Ljava/util/Date;
> > > at
> > >
> >
> org.apache.wicket.extensions.yui.calendar.DateTimeField.onBeforeRender(DateTimeField.java:446)
> > > ~[wicket-datetime-jar-6.9.0.jar:6.9.0]
> > >
> > > 6.8.0 works as expected ...
> > > Am I doing something wrong of maybe is there any workaround/missing
> > > library for this?
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>



-- 
WBR
Maxim aka solomax

Re: [ANNOUNCE] Apache Wicket 6.9.0 released

[Cedric Gatay]

The JQuery bump can cause errors in custom JavaScript relying on an older
version (deprecated methods removed).

Maybe we should add to the release page a special note in the "Upgrading
from earlier version" part ?

__
Cedric Gatay (@Cedric_Gatay )
http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr


On Tue, Jul 2, 2013 at 8:25 AM, Martin Grigorov wrote:

> On Tue, Jul 2, 2013 at 2:54 AM, Joachim Schrod  wrote:
>
> > Martijn Dashorst wrote:
> > > The Apache Wicket PMC is proud to announce Apache Wicket 6.9.0!
> >
> > Thanks a lot for providing these updates. :-) :-)
> >
> > > New and noteworthy
> > > --
> > >
> > > Switch between jQuery 1.x and 2.x depending on the user agent. For IE
> > > 6/7/8 jQuery ver. 1.x will be used, for any other browser - ver. 2.x.
> > > To use this resource reference do in your application's init method:
> > >
> > > protected void init() {
> > > getJavaScriptLibrarySettings()
> > >
> .setJQueryReference(DynamicJQueryResourceReference.INSTANCE);
> > > }
> > >
> >
> > Is this mandatory?
> > What happens if I don't set that jQuery reference, resp. don't
> > include that code?
> > Will IE8 users getting served jQuery 2.x?
> >
> > For me, that's important, we need to support IE8.
> >
>
> By default Wicket uses jQuery 1.10.0, so IE is supported.
>
>
> >
> > Joachim
> >
> > --
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > Joachim Schrod, Roedermark, Germany
> > Email: jsch...@acm.org
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>

Re: NoSuchMethodError after upgrading to 6.9.0

[Martin Grigorov]

Hi Maxim,

Wicket depends on Joda Time 2.0.
I see this method in 2.0 and in 2.2 (
http://joda-time.sourceforge.net/apidocs/src-html/org/joda/time/LocalDate.html#line.998
).

Check your dependencies. Maybe you have an older version of Joda Time in
your app.


On Tue, Jul 2, 2013 at 9:17 AM, Maxim Solodovnik wrote:

> same time DateTextField works as expected :(
>
> after switching org.apache.wicket:wicket-datetime to rev=6.8.0 everything
> works as expected
>
>
> On Tue, Jul 2, 2013 at 12:12 PM, Maxim Solodovnik  >wrote:
>
> > Hello All,
> >
> > Just have upgraded to 6.9.0 and start getting:
> >
> > Caused by: java.lang.NoSuchMethodError:
> > org.joda.time.LocalDate.toDate()Ljava/util/Date;
> > at
> >
> org.apache.wicket.extensions.yui.calendar.DateTimeField.onBeforeRender(DateTimeField.java:446)
> > ~[wicket-datetime-jar-6.9.0.jar:6.9.0]
> >
> > 6.8.0 works as expected ...
> > Am I doing something wrong of maybe is there any workaround/missing
> > library for this?
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: Alternatives for Page.componentChanged(Component, MarkupContainer) - Wicket 6.5.0

[Rakesh A]

Hi,

Thank you for the solution ; Yes, I fixed it by using
IComponentInitializationListener & IDetachListener.

Regards,
Rakesh.A



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Alternatives-for-Page-componentChanged-Component-MarkupContainer-Wicket-6-5-0-tp4659644p4659957.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [ANNOUNCE] Apache Wicket 6.9.0 released

[Martin Grigorov]

On Tue, Jul 2, 2013 at 2:54 AM, Joachim Schrod  wrote:

> Martijn Dashorst wrote:
> > The Apache Wicket PMC is proud to announce Apache Wicket 6.9.0!
>
> Thanks a lot for providing these updates. :-) :-)
>
> > New and noteworthy
> > --
> >
> > Switch between jQuery 1.x and 2.x depending on the user agent. For IE
> > 6/7/8 jQuery ver. 1.x will be used, for any other browser - ver. 2.x.
> > To use this resource reference do in your application's init method:
> >
> > protected void init() {
> > getJavaScriptLibrarySettings()
> > .setJQueryReference(DynamicJQueryResourceReference.INSTANCE);
> > }
> >
>
> Is this mandatory?
> What happens if I don't set that jQuery reference, resp. don't
> include that code?
> Will IE8 users getting served jQuery 2.x?
>
> For me, that's important, we need to support IE8.
>

By default Wicket uses jQuery 1.10.0, so IE is supported.


>
> Joachim
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Joachim Schrod, Roedermark, Germany
> Email: jsch...@acm.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: NoSuchMethodError after upgrading to 6.9.0

[Maxim Solodovnik]

same time DateTextField works as expected :(

after switching org.apache.wicket:wicket-datetime to rev=6.8.0 everything
works as expected


On Tue, Jul 2, 2013 at 12:12 PM, Maxim Solodovnik wrote:

> Hello All,
>
> Just have upgraded to 6.9.0 and start getting:
>
> Caused by: java.lang.NoSuchMethodError:
> org.joda.time.LocalDate.toDate()Ljava/util/Date;
> at
> org.apache.wicket.extensions.yui.calendar.DateTimeField.onBeforeRender(DateTimeField.java:446)
> ~[wicket-datetime-jar-6.9.0.jar:6.9.0]
>
> 6.8.0 works as expected ...
> Am I doing something wrong of maybe is there any workaround/missing
> library for this?
>
> --
> WBR
> Maxim aka solomax
>



-- 
WBR
Maxim aka solomax

NoSuchMethodError after upgrading to 6.9.0

[Maxim Solodovnik]

Hello All,

Just have upgraded to 6.9.0 and start getting:

Caused by: java.lang.NoSuchMethodError:
org.joda.time.LocalDate.toDate()Ljava/util/Date;
at
org.apache.wicket.extensions.yui.calendar.DateTimeField.onBeforeRender(DateTimeField.java:446)
~[wicket-datetime-jar-6.9.0.jar:6.9.0]

6.8.0 works as expected ...
Am I doing something wrong of maybe is there any workaround/missing library
for this?

-- 
WBR
Maxim aka solomax

Re: [ANNOUNCE] Apache Wicket 6.9.0 released

[Joachim Schrod]

Martijn Dashorst wrote:
> The Apache Wicket PMC is proud to announce Apache Wicket 6.9.0!

Thanks a lot for providing these updates. :-) :-)

> New and noteworthy
> --
> 
> Switch between jQuery 1.x and 2.x depending on the user agent. For IE
> 6/7/8 jQuery ver. 1.x will be used, for any other browser - ver. 2.x.
> To use this resource reference do in your application's init method:
> 
> protected void init() {
> getJavaScriptLibrarySettings()
> .setJQueryReference(DynamicJQueryResourceReference.INSTANCE);
> }
> 

Is this mandatory?
What happens if I don't set that jQuery reference, resp. don't
include that code?
Will IE8 users getting served jQuery 2.x?

For me, that's important, we need to support IE8.

Joachim

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jsch...@acm.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

[ANNOUNCE] Apache Wicket 6.9.0 released

[Martijn Dashorst]

The Apache Wicket PMC is proud to announce Apache Wicket 6.9.0!

This release marks the ninth minor release of Wicket 6. Starting with
Wicket 6 we use semantic versioning for the future development of
Wicket, and as such no API breaks are present in this release
compared to 6.0.0.

New and noteworthy
--

Switch between jQuery 1.x and 2.x depending on the user agent. For IE
6/7/8 jQuery ver. 1.x will be used, for any other browser - ver. 2.x.
To use this resource reference do in your application's init method:

protected void init() {
getJavaScriptLibrarySettings()
.setJQueryReference(DynamicJQueryResourceReference.INSTANCE);
}

Upgraded Atmoshpere (1.0.13) and Bootstrap (2.3.2) resources.

Using this release
--

With Apache Maven update your dependency to (and don't forget to
update any other dependencies on Wicket projects to the same version):


org.apache.wicket
wicket-core
6.9.0


Or download and build the distribution yourself, or use our
convenience binary package

 * Source: http://www.apache.org/dyn/closer.cgi/wicket/6.9.0
 * Binary: http://www.apache.org/dyn/closer.cgi/wicket/6.9.0/binaries

Upgrading from earlier versions
---

If you upgrade from 6.y.z this release is a drop in replacement. If
you come from a version prior to 6.0.0, please read our Wicket 6
migration guide found at

 * https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+6.0

Have fun!

— The Wicket team

Release Notes - Wicket - Version 6.9.0

** Bug

* [WICKET-4827] - Modal panel mouse pointer in resize style for
MSIE8 and MSIE9
* [WICKET-5056] - Page mount with an optional named parameter
overtakes a mount with more specific path
* [WICKET-5071] - 404 Error on Nested ModalWindows in IE7 and IE8
* [WICKET-5165] - Session should be bound when adding messages to it
* [WICKET-5194] - Adding AjaxFormValidatingBehavior to the form
prevents form from being filled
* [WICKET-5200] - Upgrade atmosphere-runtime to 1.0.13
* [WICKET-5202] - Page redirects can fail when using url encoding
* [WICKET-5203] - Base url is incorrect for error dispatched pages
* [WICKET-5204] - The DateTimeField.onBeforeRender() method does
not format the fields correctly.
* [WICKET-5205] - AbstractAjaxBehavior.unbind does not clean
stored reference to host component
* [WICKET-5209] - NPE when using ComponentRenderer.renderComponent
on a panel with 
* [WICKET-5218] - EnclosureContainer calls child#configure() way
before rendering
* [WICKET-5220] - AjaxEditableLabel not working well in form
* [WICKET-5222] - Direct iframe removal not supported by Firefox:
tab title stays as "Connecting"
* [WICKET-5223] - AjaxEditableLabel doesn't provide a way to
configure Ajax attributes for its Ajax behaviors
* [WICKET-5226] - CDI integration fails in Glassfish 4.0 with WELD-70
* [WICKET-5230] - AjaxFormChoiceComponentUpdatingBehavior fails
for choices containing other invalid FormComponents
* [WICKET-5234] - OnEventHeaderItem can't be applied via AJAX
* [WICKET-5237] - Wicket generates invalid HTML by expanding col tags
* [WICKET-5247] - Broken Link in Tomcat because of Page Mount

** Improvement

* [WICKET-5199] - Component.getBehaviors(Class type)
documentation is obsolete
* [WICKET-5207] - Use documented jQuery APIs for triggering the
special event 'inputchange'
* [WICKET-5208] - Contribute jQuery 1.x or 2.x depending on the user agent
* [WICKET-5210] - JQuery problem because component appears twice
in DOM while Ajax refresh
* [WICKET-5211] - Make CryptoMapper extendable
* [WICKET-5215] - Better exception message when Page instantiation
fails in DefaultPageFactory
* [WICKET-5219] - ServletWebResponse should call #setHeader() to
set Ajax-Location for redirect
* [WICKET-5228] - Add method getFirstDayOfWeek to DatePicker class
* [WICKET-5232] - ComponentRenderer.renderComponent could accept
components with any markupId, not just "compId"
* [WICKET-5233] - Component.getBehaviors() can be implemented
slightly more efficiently
* [WICKET-5238] - Upgrade bootstrap from 2.3.1 to 2.3.2

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DI Through Constructors w/Wicket

[William Speirs]

There are a few of these libraries to make running Guice in JUnit easier,
Onami is another: http://onami.apache.org/test/

However, if you have to add all of this extra stuff to your unit test, is
it really worth it?

Still struggling with all of this... but starting to hone in on my
project's best practices.

Bill-


On Mon, Jul 1, 2013 at 12:44 PM, uwe schaefer  wrote:

> On 06/29/2013 03:13 PM, William Speirs wrote:
>
>  I'm strongly leaning towards the best practice of: If you're having to
>> create an injector in your unit test, then you're doing it wrong.
>>
>
> maybe it makes it worse in your perspective, but yuo might want to have a
> look at jukito.
>
> https://code.google.com/p/**jukito/ 
>
> at least it makes it easy to combine mockito&guice
>
> cu uwe
>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: DI Through Constructors w/Wicket

[uwe schaefer]

On 06/29/2013 03:13 PM, William Speirs wrote:


I'm strongly leaning towards the best practice of: If you're having to
create an injector in your unit test, then you're doing it wrong.


maybe it makes it worse in your perspective, but yuo might want to have 
a look at jukito.


https://code.google.com/p/jukito/

at least it makes it easy to combine mockito&guice

cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Static image

[arronlee]

> Here is the source of
> org.apache.wicket.markup.html.image.Image#getStatelessHint()
> {
> return (getImageResource() == null || getImageResource() ==
> localizedImageResource.getResource()) &&
>  localizedImageResource.isStateless();
> }
>
> I.e. if the image uses a IResource then it is stateful because the url to
> the IResource is dependent on the component (e.g.
> ?2-IResourceListener-container~image).
> If you use ResourceReference then the url to reach it doesn't depend on
> the
> page/component (e.g. wicket/resource/).
>
> As Andrea mentioned you can use ContextImage which also doesn't use
> IResource and the generated url doesn't depend on the page/component.
> 


I think this is the most helpful reply. A static image will be linked
successfully this way.
Thanks for the nice sharing. It helps a lot.



-
Best Regards,
Arron



| Image Processing SDK  |


Next Tomorrow is Another Day.
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Static-image-tp4655192p4659931.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: wicket and flow

[Martin Grigorov]

Hi,

You can do all this with a custom root request mapper.


On Sat, Jun 29, 2013 at 2:50 PM, Piratenvisier
wrote:

> Hello Martin,
> a  central class in Webflow is  PageFlowRequestCycleProcessor:
>
>
> public class PageFlowRequestCycleProcessor extends WebRequestCycleProcessor
> {
>
> /** {@inheritDoc} */
> @Override
> public IRequestTarget_*resolve*_(**RequestCycle requestCycle,
> RequestParameters requestParameters)
> {
> //If Key in URL use it
> if(requestParameters.**getParameters().containsKey(**
> PageFlowConstants.FLOW_**EXECUTION_KEY))
> {
> String[] flowExecutionKeyParms = (String[])requestParameters.*
> *getParameters().get(**PageFlowConstants.FLOW_**EXECUTION_KEY);
> if(flowExecutionKeyParms.**length > 0){
> return 
> RequestTargetFactory.**buildFromState(**flowExecutionKeyParms[0],
> requestCycle, requestParameters);
> }
> }
>
> IRequestTarget target = super.resolve(requestCycle,
> requestParameters);
>
> // If the target is bookmarkable but mounted it needs to go back
> and check pageflow
> if (target instanceof BookmarkablePageRequestTarget)
> {
> //BookmarkablePageRequestTarget bookmarkableTarget = (**
> BookmarkablePageRequestTarget)**target;
>
> //if (PAGE_FLOW_PAGE_CLASS.**isAssignableFrom(**
> bookmarkableTarget.**getPageClass()) ||
> //PANEL_FLOW_PAGE_CLASS.**isAssignableFrom(**
> bookmarkableTarget.**getPageClass()))
> //{
> String currentStateFromSession = PageFlowSession.get().**
> getFlowState().**getCurrentViewState();
> return 
> RequestTargetFactory.**buildFromState(**currentStateFromSession,
> requestCycle, requestParameters);
> //}
> }
>
> return target;
> }
>
> /** {@inheritDoc} */
> @Override
> protected IRequestTarget _*resolveHomePageTarget*_(**RequestCycle
> requestCycle, RequestParameters requestParameters)
> {
>
> //Grab the target as Wicket would normally calculate it
> BookmarkablePageRequestTarget classicTarget 
> =(**BookmarkablePageRequestTarget)
> super.resolveHomePageTarget(**requestCycle, requestParameters);
> BookmarkablePageRequestTarget newTarget =  resolvePageFlowTargets(
> **classicTarget,requestCycle,**requestParameters);
>
> //If the target that PageFlow is returning isn't the real home
> page we need to redirect to it.
> if(!classicTarget.**getPageClass().equals(**
> newTarget.getPageClass())){
>
> //Redirect to the homepage if session is trying to go to the
> end of the flow since we are restarting it
> String currentStateFromSession = PageFlowSession.get().**
> getFlowState().**getCurrentViewState();
> if(PageFlowConstants.PAGE_**FLOW_FINAL_STATE_DONE.equals(**
> currentStateFromSession)){
> //Reset the whole flow state in preparation for a new flow
> PageFlowSession.get().**resetFlowState();
>
> // This line is to reset the target because the flowstate
> was just reset so the url needs to be regenerated
> classicTarget =(**BookmarkablePageRequestTarget)
> super.resolveHomePageTarget(**requestCycle, requestParameters);
>
> return classicTarget;
> }
>
> throw new RestartResponseException(**newTarget.getPageClass(),
> newTarget.getPageParameters())**;
> }
>
> return resolvePageFlowTargets(**classicTarget,requestCycle,**
> requestParameters);
> }
>
> /** {@inheritDoc} */
> @Override
> protected IRequestTarget _*resolveBookmarkablePage*_(**RequestCycle
> requestCycle, RequestParameters requestParameters)
> {
> //Grab the target as Wicket would normally calculate it
> BookmarkablePageRequestTarget classicTarget 
> =(**BookmarkablePageRequestTarget)
> super.resolveBookmarkablePage( requestCycle,  requestParameters);
>
> return resolvePageFlowTargets(**classicTarget,requestCycle,**
> requestParameters);
> }
>
> /**
>  * resolvePageFlowTargets.
>  *
>  * @param classicTarget a {@link org.apache.wicket.request.**
> target.component.**BookmarkablePageRequestTarget} object.
>  * @param requestCycle a {@link org.apache.wicket.**RequestCycle}
> object.
>  * @param requestParameters a {@link 
> org.apache.wicket.request.**RequestParameters}
> object.
>  * @return a {@link 
> org.apache.wicket.request.**target.component.**BookmarkablePageRequestTarget}
> object.
>  */
> protected BookmarkablePageRequestTarget 
> _resolvePageFlowTargets_(**BookmarkablePageRequestTarget
> classicTarget, RequestCycle requestCycle, RequestParameters
> requestParameters)
> {
> BookmarkablePageRequestTarget target = null;
>
> String currentStateFromSession = PageFlowSession.get().**
> getFlowState().**getCurrentViewState();
> /

Re: clustering and failover

[Martin Grigorov]

Hi Uwe,

There are no pagemaps since 1.5.0.
Only the last used stateful page instance is kept in the memory (as an
attribute in the http session).
The Memcached Session Manager for Tomcat is just an internal of how Tomcat
will manage its http sessions.
For the application there is no change at all. Wicket still will use the
Servlet APIs and Tomcat will do something different than what it does by
default without exposing this to you.

On the other hand if you provide your own implementation of Wicket's
ISessionStore (I know the code in 1.5/6.x better than 1.4.x but I guess it
is similar in 1.4.x too) then you can store Wicket's Session and the last
stateful page instance in something else than the Http Session, e.g. in
Memcached/Hazelcast/Redis/

In all cases your app should be able to work without sticky sessions
because if a Tomcat node goes down for any reason then your clients will be
directed to other node(s).



On Sun, Jun 30, 2013 at 2:09 PM, uwe schaefer  wrote:

> On 06/29/2013 03:49 PM, William Speirs wrote:
>
>> Another consideration is if you're using any authentication
>> Been there, still have the bite marks from that :-)
>>
>
> *g* thanks Bill, i planned to do session clustering, but have the pagemap
> seperate, so that i hopefully would not run into this.
>
> cu uwe
>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: DI Through Constructors w/Wicket

[Martin Grigorov]

Hi,


On Sat, Jun 29, 2013 at 4:13 PM, William Speirs  wrote:

> I'm just getting to this now... weekend coder.
>
> @MartinGrigorov - this looks exactly like what I want, or parts of it
> at least... I'll certainly check it out. And you're right, I shouldn't
> be so skeptical, you Wicket folks seem to always come through with
> some library when I ask a question :-)
>
> @DanielWatrous - your blog is helpful, except that you instantiate a
> Guice instance in your unit test. I'm still wrestling with what I
> consider "best practices" with respect to Guice/DI and Unit Tests, but
> I'm strongly leaning towards the best practice of: If you're having to
> create an injector in your unit test, then you're doing it wrong.
>

I cannot say that.
WicketTester tests are not exactly unit tests.

I use DI in my tests all the time. I just try to create as minimal
applicationContent (Spring) as possible for a given test. There is no need
to bind all services when just one or two are used in the tests.

For me it is more wrong to the testing to drive the architecture of the
main functionality.
When developing the main functionality you should think how to make it
reusable. The first time when you reuse some functionality is in the tests.
When you have a second use case where you need to use this
component/service/... then you will see how good you made it before. If you
need to refactor it then the tests will protect you from regressions for
your first use case, and you'll have to add tests for the second.
If it is easy to add your second use case and second test then your design
is good enough. If it is not then you should think harder.


>
> Dependencies should come in through the constructor and constructor
> only. In the unit test, mocked instances of those dependencies should
> be passed in through the constructor after you've called new to create
> the object itself. This ensures you're ONLY testing the object, and
> none of its dependencies in that unit test. If you cannot pass your
> dependencies through the constructor, it's most likely because you're
> not letting the framework create the instance for you, and this
> exposes a deficiency in your implementation. This is the problem with
> Wicket, it creates the pages for you (unless you implement your own
> IPageFactory like in the library Martin linked), which forces you to
> use field injection like you did in your blog example.
>
> Draconian "best practice"? Maybe, but when working with a number of
> developers on a project, I find it best to keep strict but simple
> rules; even better when they can be enforced with things like
> Checkstyle.
>
> Am I totally wrong here? Am I missing something? I'd love people's
> feedback on this!
>
> Bill-
>
> On Tue, Jun 25, 2013 at 10:38 PM, Daniel Watrous 
> wrote:
> > I worked out this process:
> > http://software.danielwatrous.com/wicket-guice-including-unittests/
> >
> > It enables unittests and may help you toward your goal.
> >
> > Daniel
> >
> >
> > On Tue, Jun 25, 2013 at 7:14 PM, William Speirs 
> wrote:
> >
> >> I think I know the answer before I ask, but is there any way to do
> >> constructor injection with Wicket? Say I have a web page and an email
> >> service. I need the email service in the web page. Now everyone is
> >> going to say, "Simply use field injection." That will work, but makes
> >> unit testing a real pain because now I have to setup injection for my
> >> unit test (or add additional methods to all of my pages so I can
> >> manually set these field, or additional constructors that set these
> >> fields). I should be able to unit test a class without needing
> >> injection, but instead passing mocks through the constructor.
> >>
> >> I feel like this is impossible in Wicket currently because the
> >> DefaultPageFactory is using reflection to create the page instances
> >> instead of the injector (Guice in my case). It would be easy enough to
> >> get the injector and call getInstance() to obtain a page instance. The
> >> problem is when you need to pass in parameters. There is no concept of
> >> parameters for a page other than what is passed via the constructor,
> >> so you cannot call something like setPageParameters because it doesn't
> >> exist. If using Guice, you could create an @Assisted injection, and
> >> have a factory.
> >>
> >> Has anyone tried creating this type of IPageFactory -- a
> >> GuicePageFactory? What kind of pitfalls would exist if I attempted
> >> such a thing? Am I being stupid and missing something? Thoughts?
> >>
> >> Thanks...
> >>
> >> Bill-
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Alternatives for Page.componentChanged(Component, MarkupContainer) - Wicket 6.5.0

[Martin Grigorov]

Hi,

You can use org.apache.wicket.application.IComponentInitializationListener.
See org.apache.wicket.Application#getComponentInitializationListeners().add(..)


On Mon, Jul 1, 2013 at 8:04 AM, Rakesh A  wrote:

> Hi,
>
> In 1.4.x implementation, we were overriding this method [int our base Page
> implementation] and were doing bit of initialization for the components of
> the page which is [I mean initialization part - UI related] specific to our
> implementation.
>
> This was one central location to do this for any component change on the
> page with v1.4.x, as we upgraded Wicket libarary to 6.5.0 recently, we're
> looking for alternatives for this method.
>
> Regards,
> Rakesh.A
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Alternatives-for-Page-componentChanged-Component-MarkupContainer-Wicket-6-5-0-tp4659644p4659932.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>