Igor Vaynberg wrote:
also what to do about session.newrequestcycle vs
application.newdefaultrequestcycle. can we get rid of the session one? i
understand the "concept" of a cascade: application creates session, session
creates request cycle. but how practical is that? when do you want
different
+1
one class to implement and then one class to create most things needed..
johan
On 6/24/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 6/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> IRequestCycleFactory and ISessionFactory annoy the hell out of me. We
> simplified how they are use
https://issues.apache.org/jira/browse/WICKET-689 is very related to this.
Yep, that and working on Wicket In Action, triggered sending this email.
I can't see if there will be any unwanted consequences by doing this
Don't think so. If people for whatever reason want more indirection
they can
On 6/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
IRequestCycleFactory and ISessionFactory annoy the hell out of me. We
simplified how they are used a bit in 1.3, but imho, I think we should
just ditch them all together in favor of simply two factory methods in
application. Factory method n
On 6/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
IRequestCycleFactory and ISessionFactory annoy the hell out of me. We
simplified how they are used a bit in 1.3, but imho, I think we should
just ditch them all together in favor of simply two factory methods in
application. Factory method n
IRequestCycleFactory and ISessionFactory annoy the hell out of me. We
simplified how they are used a bit in 1.3, but imho, I think we should
just ditch them all together in favor of simply two factory methods in
application. Factory method newSession already exists in
WebApplication (as that class