I dont think we can get rid of it all.
We need checking because what if i do this
MyModelInnerClassPageA model = new MyModelInnerClassPageA()
PageB b = new PageB(model)
This is ofcourse a simple example but there are all kind of variants.
So if we remove it and dont log big warnings/errors this
That's what we're doing right now. And that's what causing all the
pain. It's much more complicated to have this work automatically,
mostly because of circular references, anonymous classes, etc. Look at
the AbstractPageStore, Component#write/readObject, Page#writeReplace,
PageHolder, etc.
-Matej
im pretty sure that is already pretty much what is going on
-igor
On Mon, Mar 2, 2009 at 3:26 PM, James Carman
wrote:
> Can we use some creative readResolve/writeReplace logic to serialize
> the page references? So, when you write out the page reference, you
> spit out one of Igor's Pageid
Can we use some creative readResolve/writeReplace logic to serialize
the page references? So, when you write out the page reference, you
spit out one of Igor's Pageid objects? Then, on the readResolve()
method, it will use the page id to lookup the actual page reference.
On Mon, Mar 2, 2009 at 6
By bad practice I meant unnecessary or "accidental" page references.
They don't bring you much apart from performance degradation and if
you are lucky nice fat stacktrace :)
We might be able to detect page reference, that should be pretty
simple - i.e. override page#writeObject and check if there
i already built something similar to the page.getreference() Matej is
talking about. see PageId, Page#getPageId(), and
RequestCycle#urlFor(PageId). this is very useful for building
breadcrumbs as you dont have to pass a stack of pages around.
generally i agree, supporting page references is a pit
The problem of course are explicit page references. Actually, it is
the code in wicket that makes it possible to use page references. It's
*huge* pain to maintain and it still doesn't work flawlessly (and
never will). Anonymous classes are only tip of iceberg.
Also, if we get rid of all the magic
The problem is not IMO the page reference that gets passed in
explicitly, but those anonymous references to the surrounding
page/component that are the cause of subtle bugs. The problem is that
you won't get rid of those references with this solution...
Martijn
On Mon, Mar 2, 2009 at 11:38 PM, Ma
I like it! That could really simplify some things and reduce the number of
strange / hard to trace serialization errors.
On Mon, Mar 2, 2009 at 4:38 PM, Matej Knopp wrote:
> Hi,
>
> more perceptive people have probably noticed that there is some really
> obscure page serialization related code
Hi,
more perceptive people have probably noticed that there is some really
obscure page serialization related code in Wicket. What it is supposed
to do is to make sure that when PageA holds reference to pageB, pageA
and pageB get serialized separately and when pageA is deserialized,
pageB is loade
this is why sharing jars across web applications is generally a bad
idea unless the jars are specifically designed to be shared. you are
going to run into the same problem with any jar that stores a cache in
a static variable, because all of a sudden this cache is shared across
multiple application
I had no luck with this on the users mail list ( us...@wicket.apache.org )
maybe here its a better fit for this email
Hello,
I have a problem with the wicket - spring integration in wicket 1.4 rc2 , i
think its similar to https://issues.apache.org/jira/browse/WICKET-1848
The use case is like th
create a jira issue please
-igor
On Mon, Mar 2, 2009 at 12:23 PM, Alex Parvulescu
wrote:
> Hello,
>
> Can you please add page parameters to the IRequestTarget logging ?
>
> Its a simple addition to
> org.apache.wicket.protocol.http.RequestLogger#getRequestTargetString(IRequestTarget
> target) :
Hello,
Can you please add page parameters to the IRequestTarget logging ?
Its a simple addition to
org.apache.wicket.protocol.http.RequestLogger#getRequestTargetString(IRequestTarget
target) :
so this
else if (target instanceof IBookmarkablePageRequestTarget)
{
IBook
14 matches
Mail list logo
