that max page versions thing can be removed
in the access stack it doesn't make any sense. because you don't control one
page because
setting that to 5 still means that there can be 5 pages with each 5 versions
is a back button support of 25
what you want is control that last (25) value.  So you want to control the
max number of back buttons over
all the pages, that is what the pagemap evict strategy does.

johan


On 6/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:

Ok, I'll take a look at whether I can follow this this weekend. That
must be the worst code ever though, if it's so unobvious. And why do
we still have that maxPageVersions application parameter, and the
maxversions member in the pageversion member? The whole way this works
sounds like one big fat hack to me; it probably is to get around the
initial limitations without breaking the API, is that correct?

Eelco


On 6/8/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> no it is true for page versions
> there will be a Access object created for every page version
> that will be pushed on the access stack (in the pagemap)
> that access object has 2 variables: pageid and versionnumber
>  that makes it unique
>
> and you are looking at the wrong thing that Settings.maxPageVersionsdoesn't
> do much
> its the:
> public LeastRecentlyAccessedEvictionStrategy(int
> maxVersions) (IPageMapEvictionStrategy)
>
> that one evicts such a access objects from the pagemap.
> and if it events an Access object with pageid 7 and version 2
> it will delete that version from the changelist of the versionmanger for
> that page
> and if that is the last one the complete page is removed. If not then
there
> is just one version less for that page.
>
> So no in wicket 1.2 we don't build up a page over and over again. There
is
> really only 5 or 7 (i see 5 is now the default)
> page/pageversions alive at one time (5 access objects)
>
> the problem was if i remember correctly pure ajax pages. (and i don't
see at
> the moment how that did go wrong in 1.2)
>
>
> johan
>
>
>
>
> On 6/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > I don't think that is true for page *versions*, which is also used
> > when you use component replacement, ajax or not.
> >
> > A quick look reveals that Settings#maxPageVersions is still max int,
> > and in 1.2, Page has
> >
> >         protected IPageVersionManager newVersionManager()
> >         {
> >                 final IPageSettings settings =
> > getSession().getApplication().getPageSettings();
> >                 return new UndoPageVersionManager(this,
> settings.getMaxPageVersions());
> >         }
> >
> > Then, UndoPageVersionManager has
> >
> >                 // If stack is overfull, remove oldest entry
> >                 if (getVersions() > maxVersions)
> >                 {
> >                         expireOldestVersion();
> >                 }
> >
> > in method endVersion. So unless I miss something in the larger
> > picture, it looks to me that whenever you do component replacement on
> > a page, it just keeps building up versions until max int is reached.
> > And this is exactly what I've been objecting to in the past, and I
> > still think max int is a crazy (dangerous) default. But please do
> > enlighten me if I'm wrong. And maybe this time we can either clear
> > this up or fix it for once and for all.
> >
> > Eelco
> >
> >
> > On 6/8/07, Johan Compagner <[EMAIL PROTECTED] > wrote:
> > > that growing of a page constantly is only a problem when you use one
> page
> > > and through ajax request you constantly change that single page.
> > >
> > > if not then the page versions will be removed because there can only
be
> 7
> > > (pages + page versions) by default
> > >
> > > johan
> > >
> > >
> > >
> > > On 6/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > We're using 1.2.6.  Is the 2nd level cache available prior to
1.3?
> > > >
> > > > It's only in 1.3 I'm afraid.
> > > >
> > > > > As for page complexity, we commonly have a reasonably robust
> repeater
> > > > > or list view on each page (though without too many rows) along
with
> a
> > > > > form or two.
> > > > >
> > > > > I'm concerned about models because as I do work on a given page
I
> see
> > > > > the older page maps change in size.  I.e. I have p0=30K, p1=33K
--
> > > > > then I do something substantial on p2 and see the size of p0 &
p1
> each
> > > > > increase by 11K.
> > > >
> > > > One known issue with the old sessionstore is that deltas of a page
are
> > > > stored in the page itself. This will result in the page keep on
> > > > growing. We've had lots of discussion about this, which resulted
in
> > > > the default session store implementation of 1.3 now storing the
whole
> > > > page for each version to second level cache (temp dir) instead.
> > > >
> > > > I'm not sure how to fix this for 1.2 tbh. To limit how far those
> > > > versions can grow, you can set maxVersions in
UndoPageVersionManager,
> > > > which in 1.2 is a setting somewhere (sorry don't know from the top
of
> > > > my head).
> > > >
> > > > Eelco
> > > >
> > > >
> > >
>
-------------------------------------------------------------------------
> > > > This SF.net email is sponsored by DB2 Express
> > > > Download DB2 Express C - the FREE version of DB2 express and take
> > > > control of your XML. No limits. Just data. Click to get it now.
> > > > http://sourceforge.net/powerbar/db2/
> > > > _______________________________________________
> > > > Wicket-user mailing list
> > > > Wicket-user@lists.sourceforge.net
> > > >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > > >
> > >
> > >
> > >
>
-------------------------------------------------------------------------
> > > This SF.net email is sponsored by DB2 Express
> > > Download DB2 Express C - the FREE version of DB2 express and take
> > > control of your XML. No limits. Just data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > Wicket-user mailing list
> > > Wicket-user@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > >
> > >
> >
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to