[jira] Resolved: (WICKET-3291) Refactoring of RequestCycle has reintroduced WICKET-689

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-3291.
-----------------------------------

    Resolution: Invalid
      Assignee: Igor Vaynberg

the indirection was necessary because there are usecases where an applicaiton subclass is not possible. for example, wicket tester in 1.5 needs to decorate the request cycle used by the application - it cannot do this if there was simply a newRequestCycle() method, but it can by decorating the provider. see BaseWicketTester$TestRequestCycleProvider class in trunk.

further, while the factory methods are simpler the providers are necessary because class hieararchy is not flexible. since there is no multiple inheritance people cannot mix two application base classes that provide functionality. by switching to providers and letting code push changes into the application instead of pulling from factory methods we allow much more flexibility for wicket libraries. for example a spring library can push a component instantiation listener while a security library can push an authorization strategy by using providers instead of factory methods.

> Refactoring of RequestCycle has reintroduced WICKET-689
> -------------------------------------------------------
>
>                 Key: WICKET-3291
>                 URL: https://issues.apache.org/jira/browse/WICKET-3291
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5-M3
>            Reporter: Willis Blackburn
>            Assignee: Igor Vaynberg
>
> Three years ago I requested a newRequestCycle method in Application to make it as easy to integrate custom RequestCycle implementations as it is to integrate custom Session implementations.  The Wicket team added the method and also removed the IRequestCycleFactory interface.
> But in the 1.5-M3 code base I see the exact same situation:  IRequestCycleFactory has returned, only now it's called IRequestCycleProvider, and again there is no non-final Application method that I can override to instantiate my own RequestCycle.
> I think as a general principle, we should look skeptically at interfaces have one method and that only exist as a member of one class and are only called from that class;  it seems like a complicated way of overriding a method.  Possibly there's a Wicket application out there somewhere that would benefit from the interface.  But for most of us, who are creating our own Application subclasses anyway, it's much easier to just override newRequestCycle, in the same way that we override newSession.
> See also WICKET-689.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.