Hi,
Does anyone remember why the original design has been
not to pass parent to constructor and use add ? I'm a little worried
that there is some kind of idea behind the original approach and
after doing huge amount of work (in wicket and applications that use
it) we end up finding out that
Bugs item #1409706, was opened at 2006-01-19 02:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=684975aid=1409706group_id=119783
Please note that this message will contain a full copy of
just realised my compromise wont work because i dont think there is a
way to tell the difference between a default constructor that is
implemented and the one provided by java.
what we are doing right now is the opposite. we always try the
pageparams constructor, and if there isnt one then we
I don't know yet why but the ErrorPage is marked as stateless (as it can because there are no call backs in the page)But the url that we see in the browser is of that error page. But if you do a refresh of an error page now you get page expired...
I thought ErrorPage would have a IRedirectListener
i assume you mean ExceptionErrorPage?
it looks like the problem is that the page is not bookmarkable and yet
has no listeners either. since it's not bookmarkable it cannot be
recreated via refresh. since it has no listeners, it was assumed to be
stateless and not left in the session!
We only recently started getting to the limits we can do with our current component model: essentially _javascript_/css id's, component rendering and so forth are quite troublesome when using the 'old' approach. This is probably not something that can be discovered up front. For most web
Ok,
Now if someone would put these releases (1.2 and 2.0) to timeline
(just roughly), I could start discussing here locally about the change.
Ari S.
- Original Message -
From: Martijn Dashorst [EMAIL PROTECTED]
To: wicket-develop@lists.sourceforge.net
Sent: Thursday, January 19,
I'd like to discuss locking of the session for dynamic resources. For
things like images and possibly reports, it might be a better idea
*not* to lock.
Eelco
-- Forwarded message --
From: Eelco Hillenius [EMAIL PROTECTED]
Date: Jan 19, 2006 11:47 AM
Subject: Re: [Wicket-user]
Can't we flag a request target such that it isn't synchronized on the session? Default should synchronize, but make it overridable?MartijnOn 1/19/06,
Eelco Hillenius [EMAIL PROTECTED] wrote:
I'd like to discuss locking of the session for dynamic resources. Forthings like images and possibly
Yes, we can. That's the whole point of the getLock method in
IRequestTarget. The question now is whether we should make the
exception for dynamic resources at all, and how we would implement
that (e.g. would we do it for all resources, or just a few classes, or
do we ask resources themselves).
Yes i mean that page. And i get why it was But if we do some kind of client side redirect to it we also have to make sure that it is not stateless.The problem is that then i think many pages are not stateless..
johanOn 1/19/06, Jonathan Locke [EMAIL PROTECTED] wrote:
i assume you mean
Would it be possible to make IResourceStreamLocator.locate take class
instead of class loader?
And is it all right that ResourceSettings.setResourceStreamLocator takes
class (ResourceStreamLocator) instead of an interface?
-Matej
---
I think i agree with Matej on this one(have already made some refactorings.)But just to make sure.Settings.getResourceLocator() should return an instance and not a implemenation.Then is it a bad thing that we change the interface from:
public IResourceStream locate(ClassLoader classLoader, String
On 1/19/06, Johan Compagner [EMAIL PROTECTED] wrote:
I think i agree with Matej on this one
(have already made some refactorings.)
But just to make sure.
Settings.getResourceLocator() should return an instance and not a
implemenation.
why? why do we the interface than?
Then is it a bad
Johan
there is one more: AbstractResourceStreamLoader and
ResourceStreamLoader seem to be redundant. Looks like I didn't
finished some refactoring. I guess ResourceStreamLoader seems to be
more or less obsolete/redundant
Juergen
On 1/19/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
On
Feature Requests item #1410109, was opened at 2006-01-19 18:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=684978aid=1410109group_id=119783
Please note that this message will contain a
Sorry i meant of course interface... :(so returning the interface in Settingsand making the Class param method the interface method?will do that refactor.Which can be removed? Because DefaultResourceStreamLocater extends ResourceStreamLocator
And the default is a list of IResourceLocators and some
Feature Requests item #1410298, was opened at 2006-01-19 23:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=684978aid=1410298group_id=119783
Please note that this message will contain a
18 matches
Mail list logo
