Re: final modifier on AuthenticatedWebApplication getSessionFactory method (2.0 branch)
Thanks!
Ernesto
Eelco Hillenius wrote:
done.
Eelco
On 1/5/07, Ernesto Reinaldo Barreiro [EMAIL PROTECTED] wrote:
Dear Wicket Devs,
Would it be possible to remove the final modifier on
protected final ISessionFactory getSessionFactory()
{
return new ISessionFactory()
{
private static final long serialVersionUID = 1L;
public Session newSession(Request request)
{
return newSession();
}
public Session newSession()
{
try
{
return webSessionClass
.getDeclaredConstructor(AuthenticatedWebApplication.class).newInstance(
AuthenticatedWebApplication.this);
}
catch (Exception e)
{
throw new
WicketRuntimeException(Unable to instantiate web session
class
+
webSessionClass, e);
}
}
};
}
of the class AuthenticatedWebApplication on the wicket-auth-roles
project?
In some application we need to override this method mainly because my
webSessionClass class does not have a constructor accepting an
AuthenticatedWebApplication class but a constructor accepting a subclass
of
AuthenticatedWebApplication.class.
Kind regards,
Ernesto
--
View this message in context:
http://www.nabble.com/final-modifier-on-AuthenticatedWebApplication-getSessionFactory-method-%282.0-branch%29-tf2925663.html#a8178503
Sent from the Wicket - Dev mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/final-modifier-on-AuthenticatedWebApplication-getSessionFactory-method-%282.0-branch%29-tf2925663.html#a8214828
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Wicket and Backbase
why dont you give us an example of markup you are having difficulty outputting? -igor On 1/7/07, Toscano [EMAIL PROTECTED] wrote: Hello, I have been doing some testing for a very big project, and I have been seduced by Wicket. In the web interface side, we are considering Backbase, but although I could integrate easily simple controls like buttons, I don't know how to output the special html that backbase needs... Do I have to create specific wicket.markup.html components? Can anybody help me with how to face this? Thank you very much!, Oskar -- View this message in context: http://www.nabble.com/Wicket-and-Backbase-tf2937954.html#a8213853 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: hangman exception: attach
yes, and thats what ive been using - quick hierarchy (ctrl+t), but that doesnt show anon classes and doesnt work across projects reliably. -igor On 1/8/07, Erik van Oosten [EMAIL PROTECTED] wrote: Press Ctrl-T while the cursor is on a method definition, or press Ctrl-T twice when the cursor is on a method implementation. Another helpfull shortcut is Ctrl-Alt-H (Open Call Hierarchy). Have fun, Erik. Igor Vaynberg wrote: fixed, damn looks like eclipse' quick hierarchy doesnt support anonymous classes. is there a way to see all overrides of a method? -igor -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: RefreshingView and IDataProvider
dataprovider is for the dataview, why would you want to use it in the refreshing view? in 2.0 i plan on refactoring the refreshing view, removing getItemModels and instead make its model object of type IteratorIModel -igor On 1/8/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Hi, Is there a reason why RefreshingView does not require an IDataProvider, and requires instead to implement getItemModels()? Thanks in advance, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: hangman exception: attach
Hmm, that's weird. They do show up here. My Eclipse version is fairly new. Maybe you're using something oldish? Erik. Igor Vaynberg schreef: yes, and thats what ive been using - quick hierarchy (ctrl+t), but that doesnt show anon classes and doesnt work across projects reliably. -igor On 1/8/07, Erik van Oosten [EMAIL PROTECTED] wrote: Press Ctrl-T while the cursor is on a method definition, or press Ctrl-T twice when the cursor is on a method implementation. Another helpfull shortcut is Ctrl-Alt-H (Open Call Hierarchy). Have fun, Erik. Igor Vaynberg wrote: fixed, damn looks like eclipse' quick hierarchy doesnt support anonymous classes. is there a way to see all overrides of a method? -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: hangman exception: attach
3.2.1, you? -igor On 1/8/07, Erik van Oosten [EMAIL PROTECTED] wrote: Hmm, that's weird. They do show up here. My Eclipse version is fairly new. Maybe you're using something oldish? Erik. Igor Vaynberg schreef: yes, and thats what ive been using - quick hierarchy (ctrl+t), but that doesnt show anon classes and doesnt work across projects reliably. -igor On 1/8/07, Erik van Oosten [EMAIL PROTECTED] wrote: Press Ctrl-T while the cursor is on a method definition, or press Ctrl-T twice when the cursor is on a method implementation. Another helpfull shortcut is Ctrl-Alt-H (Open Call Hierarchy). Have fun, Erik. Igor Vaynberg wrote: fixed, damn looks like eclipse' quick hierarchy doesnt support anonymous classes. is there a way to see all overrides of a method? -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: Wicket and Backbase
Oskar, The BackBase language is XML right? So what you can do is give the BackBase elements a wicket:it attribute and attach components to it, just as would do with html tags. Regards, Erik. On 1/7/07, Toscano [EMAIL PROTECTED] wrote: Hello, I have been doing some testing for a very big project, and I have been seduced by Wicket. In the web interface side, we are considering Backbase, but although I could integrate easily simple controls like buttons, I don't know how to output the special html that backbase needs... Do I have to create specific wicket.markup.html components? Can anybody help me with how to face this? Thank you very much!, Oskar -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: hangman exception: attach
I am home now so I can't check it. Erik. Igor Vaynberg schreef: 3.2.1, you? -igor
Re: Wicket and Backbase
My back base knowledge is poor, so can you give an example of what kind of markup you need to produce? Eelco On 1/8/07, Toscano [EMAIL PROTECTED] wrote: Hello, Thank you very much for your responses. I understand what you want to say, but I'm afraid I don't know how to do it. My Wicket knowledge is poor yet, can you show me or redirect me to an example of this?. Again, thank you for your time! Oskar Erik van Oosten wrote: Oskar, The BackBase language is XML right? So what you can do is give the BackBase elements a wicket:it attribute and attach components to it, just as would do with html tags. Regards, Erik. On 1/7/07, Toscano [EMAIL PROTECTED] wrote: Hello, I have been doing some testing for a very big project, and I have been seduced by Wicket. In the web interface side, we are considering Backbase, but although I could integrate easily simple controls like buttons, I don't know how to output the special html that backbase needs... Do I have to create specific wicket.markup.html components? Can anybody help me with how to face this? Thank you very much!, Oskar -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ -- View this message in context: http://www.nabble.com/Wicket-and-Backbase-tf2937954.html#a8225176 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Wicket and Backbase
wicket can generate any xml markup, give us an example and we will show you how -igor On 1/8/07, Toscano [EMAIL PROTECTED] wrote: Hello, Thank you very much for your responses. I understand what you want to say, but I'm afraid I don't know how to do it. My Wicket knowledge is poor yet, can you show me or redirect me to an example of this?. Again, thank you for your time! Oskar Erik van Oosten wrote: Oskar, The BackBase language is XML right? So what you can do is give the BackBase elements a wicket:it attribute and attach components to it, just as would do with html tags. Regards, Erik. On 1/7/07, Toscano [EMAIL PROTECTED] wrote: Hello, I have been doing some testing for a very big project, and I have been seduced by Wicket. In the web interface side, we are considering Backbase, but although I could integrate easily simple controls like buttons, I don't know how to output the special html that backbase needs... Do I have to create specific wicket.markup.html components? Can anybody help me with how to face this? Thank you very much!, Oskar -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ -- View this message in context: http://www.nabble.com/Wicket-and-Backbase-tf2937954.html#a8225176 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Wicket and Backbase
Perhaps it is time to read up on the examples. You can find these on http://wicketframework.org/ and http://cwiki.apache.org/WICKET/. Please ask further on the user list. This is the developers list. Eelco, BackBase uses a XUL syntax with things like windowstuff/window, these are read and converted by a javascript library on the client side. Another implementation that does this is ZK (http://www.zkoss.org/). Both BackBase and ZK have a live demo where you can enter the tags in your browser. Regards, Erik. Toscano wrote: Hello, Thank you very much for your responses. I understand what you want to say, but I'm afraid I don't know how to do it. My Wicket knowledge is poor yet, can you show me or redirect me to an example of this?. Again, thank you for your time! Oskar -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: RefreshingView and IDataProvider
* Igor Vaynberg: dataprovider is for the dataview, why would you want to use it in the refreshing view? We find IDataProvider handy for providing data... As the name suggests. It is useful even outside of DataView, mainly in Wicket Contrib Dojo. in 2.0 i plan on refactoring the refreshing view, removing getItemModels and instead make its model object of type IteratorIModel What is strange is that RefreshingView expects an IteratorIModel whereas IDataProvider expects an IteratorObject, and another method model(Object) to get an IModel. I think data could be provided in a uniform way throughout the repeater package. IMO it would be clearer to have RefreshingView use an IDataProvider. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Wicket and Backbase
Thank you again for your answers. I'm sorry because maybe I'm asking in the wrong forum... For example, backbase renders a tree control using this xml: b:treelist b:treelistrow b:treelistcell b:type=headSubject/b:treelistcell b:treelistcell b:type=headFrom/b:treelistcell b:treelistcell b:type=headPosted/b:treelistcell /b:treelistrow b:treelistrow b:treelistcellIs the Seven Samurai good?/b:treelistcell b:treelistcellJeremy Hartley/b:treelistcell b:treelistcell15-08-2005, 13:01/b:treelistcell /b:treelistrow b:treelistrow b:treelistcell2001 - Question about religion/b:treelistcell b:treelistcellJohn Deare/b:treelistcell b:treelistcell23-07-2005, 17:14/b:treelistcell b:treelistchildren b:treelistrow b:treelistcellRe: 2001 - Question about religion/b:treelistcell b:treelistcellMarcel Diepstra/b:treelistcell b:treelistcell24-07-2005, 8:01/b:treelistcell /b:treelistrow /b:treelistchildren /b:treelistrow /b:treelist Question is: how can I ouput this kind of xml from a data structure on Wicket? My point is to use much more complicated backbase controls, but if I can learn how to do this, I think I will be able to do anyone. Again, thank you very much! Eelco Hillenius wrote: My back base knowledge is poor, so can you give an example of what kind of markup you need to produce? Eelco On 1/8/07, Toscano [EMAIL PROTECTED] wrote: Hello, Thank you very much for your responses. I understand what you want to say, but I'm afraid I don't know how to do it. My Wicket knowledge is poor yet, can you show me or redirect me to an example of this?. Again, thank you for your time! Oskar Erik van Oosten wrote: Oskar, The BackBase language is XML right? So what you can do is give the BackBase elements a wicket:it attribute and attach components to it, just as would do with html tags. Regards, Erik. On 1/7/07, Toscano [EMAIL PROTECTED] wrote: Hello, I have been doing some testing for a very big project, and I have been seduced by Wicket. In the web interface side, we are considering Backbase, but although I could integrate easily simple controls like buttons, I don't know how to output the special html that backbase needs... Do I have to create specific wicket.markup.html components? Can anybody help me with how to face this? Thank you very much!, Oskar -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ -- View this message in context: http://www.nabble.com/Wicket-and-Backbase-tf2937954.html#a8225176 Sent from the Wicket - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Wicket-and-Backbase-tf2937954.html#a8225780 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Wicket and Backbase
here is a panel that will output b:treelistrow tag
// model
class TreeListRow { ListTreeListCell cells; }
class TreeListCell { String type, String text; }
//panel
class TreeListRowPanel extends Panel {
public TreeListRowPanel(String id, IModelTreeListRow model) {
super(id, new CompoundPropertyModel(model));
add(new ListView(cells) {
populateItem(ListItem item) {
TreeListCell cell=item.getModelObject();
item.add(new SimpleAttributeModifier(b:type,
cell.gettype());
item.add(new Label(text, cell.gettext()));
}
}
}
}
markup:
wicket:panel
b:treelistrow
b:treelistcell wicket:id=cells/b:treelistrow
/wicket:panel
thats all there is to that, you simple attach wicket tags to backbase markup
tags. once you grok this i can explain how to build the recursive tree
structure to you
-igor
On 1/8/07, Toscano [EMAIL PROTECTED] wrote:
Thank you again for your answers. I'm sorry because maybe I'm asking in
the
wrong forum...
For example, backbase renders a tree control using this xml:
b:treelist
b:treelistrow
b:treelistcell b:type=headSubject/b:treelistcell
b:treelistcell b:type=headFrom/b:treelistcell
b:treelistcell b:type=headPosted/b:treelistcell
/b:treelistrow
b:treelistrow
b:treelistcellIs the Seven Samurai
good?/b:treelistcell
b:treelistcellJeremy Hartley/b:treelistcell
b:treelistcell15-08-2005, 13:01/b:treelistcell
/b:treelistrow
b:treelistrow
b:treelistcell2001 - Question about
religion/b:treelistcell
b:treelistcellJohn Deare/b:treelistcell
b:treelistcell23-07-2005, 17:14/b:treelistcell
b:treelistchildren
b:treelistrow
b:treelistcellRe: 2001 - Question about
religion/b:treelistcell
b:treelistcellMarcel
Diepstra/b:treelistcell
b:treelistcell24-07-2005,
8:01/b:treelistcell
/b:treelistrow
/b:treelistchildren
/b:treelistrow
/b:treelist
Question is: how can I ouput this kind of xml from a data structure on
Wicket?
My point is to use much more complicated backbase controls, but if I can
learn how to do this, I think I will be able to do anyone.
Again, thank you very much!
Eelco Hillenius wrote:
My back base knowledge is poor, so can you give an example of what
kind of markup you need to produce?
Eelco
On 1/8/07, Toscano [EMAIL PROTECTED] wrote:
Hello,
Thank you very much for your responses.
I understand what you want to say, but I'm afraid I don't know how to
do
it.
My Wicket knowledge is poor yet, can you show me or redirect me to an
example of this?.
Again, thank you for your time!
Oskar
Erik van Oosten wrote:
Oskar,
The BackBase language is XML right?
So what you can do is give the BackBase elements a wicket:it
attribute
and attach components to it, just as would do with html tags.
Regards,
Erik.
On 1/7/07, Toscano [EMAIL PROTECTED] wrote:
Hello,
I have been doing some testing for a very big project, and I have
been
seduced by Wicket. In the web interface side, we are considering
Backbase,
but although I could integrate easily simple controls like buttons,
I
don't
know how to output the special html that backbase needs... Do I
have
to
create specific wicket.markup.html components? Can anybody help me
with
how
to face this?
Thank you very much!,
Oskar
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
--
View this message in context:
http://www.nabble.com/Wicket-and-Backbase-tf2937954.html#a8225176
Sent from the Wicket - Dev mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/Wicket-and-Backbase-tf2937954.html#a8225780
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: RefreshingView and IDataProvider
On 1/8/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: We find IDataProvider handy for providing data... As the name suggests. It is useful even outside of DataView, mainly in Wicket Contrib Dojo. glad to hear it :) in 2.0 i plan on refactoring the refreshing view, removing getItemModels and instead make its model object of type IteratorIModel What is strange is that RefreshingView expects an IteratorIModel whereas IDataProvider expects an IteratorObject, and another method model(Object) to get an IModel. I think data could be provided in a uniform way throughout the repeater package. IMO it would be clearer to have RefreshingView use an IDataProvider well, if you look at it closer the refreshingview has no concept nor overhead of paging. it is a simple repeater that is fed with an iterator. it is meant for small datasets. the dataprovider was designed to work with large datasets, thus a separate size() method and iterator() that takes a range. so to impose this onto simpler usecases which do not require paging is silly imho. roughly the hierarchy goes: refreshingview-pageablerefreshingview-dataview. does this make sense? -igor . -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: RefreshingView and IDataProvider
* Igor Vaynberg: well, if you look at it closer the refreshingview has no concept nor overhead of paging. it is a simple repeater that is fed with an iterator. it is meant for small datasets. OK I understand your point now. In the ideal world I see: * IDataProvider: Iterator iterator() IModel model(Object object) * IPageableDataProvider extends IDataProvider: Iterator iterator(int first, int count) int size() IModel model(Object object) In particular I made the error several times to return IteratorObject instead of IteratorIModel in RefreshingView. Also the fact that branch 1.X uses Java 1.4 without generics does not help. I'm confident that you'll always be able to argue, but these are my honest feelings! -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: RefreshingView and IDataProvider
Another request: we need to know the item at a given row position in the table for AJAX callbacks on selected rows. What is the best option to do that with a RefreshingView? Call iterator() and iterate until reaching the required index? Is there room for improvement on this? Wicket could provide a method for doing that maybe. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: RefreshingView and IDataProvider
On 1/8/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: In particular I made the error several times to return IteratorObject instead of IteratorIModel in RefreshingView. Also the fact that branch 1.X uses Java 1.4 without generics does not help. yep, i have done that too on several occasions. 1.4 isnt very helpful in that regard. i named the method getItemModels() in hopes that it will help keep users remember to return models. i even wrote a ModelIteratorAdapter to make the wrapping easy. i think this is just a case of having to remember what to return. come to think of it maybe what we should do is change the return signature from Iterator to ModelIteratorAdapter and rename that to ModelIterator. thoughts? -igor
Re: RefreshingView and IDataProvider
what is the actual usecase? -igor On 1/8/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Another request: we need to know the item at a given row position in the table for AJAX callbacks on selected rows. What is the best option to do that with a RefreshingView? Call iterator() and iterate until reaching the required index? Is there room for improvement on this? Wicket could provide a method for doing that maybe. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
refactor storing pages and versions
Hi, Currently, pages and versions of pages are stored separately. Pages are stored in IPageMaps, and each page has a IPageVersionManager. By default (and I wonder how many users actually ever did override this) the IPageVersionManager is UndoPageVersionManager, which keeps a list of changes in the instance. As the instance is kept as a reference of the page, the size of a page in a session is the sum of the size of the actual page at that time + the size of the list of all the changes. This is regardless of how the PageMap/ session store works unfortunately, and by default, you can have Integer.MAX versions. That potentially fills up memory pretty badly if you do a lot of component replacement. And Integer.MAX isn't the best guarantee to keep memory down either. Furthermore, it works pretty lousy with the new session store. That store saves every page/ version combination to disk, but including the whole version manager (all versions), which is inefficient. With this way of saving, you really don't need more than one. Anyway, to make a long story short here is what I think we should do: - Align pagemaps and version management so that pages and versions are stored in, and retrieved from the same entity. - Change the SecondLevelCacheSessionStore so that it either saves pages without the version manager but rather exactly as they are at that moment or save the first version as a full page, and subsequent versions as changes. This would be my choice as it is more efficient in especially storing it, and storing is the part having a greater impact than retrieving. - Page should only use a temporary instance of IPageVersionManager and the newVersionManager method could be private imo as I don't see much use now users being able to provide their own (in fact, we could get rid of the IPageVersionManager interface). When endVersion is called, the changes would be flushed and saved to the pagemap and the version manager instance should be nulled. WDYT? Eelco
Re: refactor storing pages and versions
i dont even see the point of having an IPageVersionManager. it is tied to Change which has an undo() method, so what other kind of manager can you write except the undo one? -igor On 1/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi, Currently, pages and versions of pages are stored separately. Pages are stored in IPageMaps, and each page has a IPageVersionManager. By default (and I wonder how many users actually ever did override this) the IPageVersionManager is UndoPageVersionManager, which keeps a list of changes in the instance. As the instance is kept as a reference of the page, the size of a page in a session is the sum of the size of the actual page at that time + the size of the list of all the changes. This is regardless of how the PageMap/ session store works unfortunately, and by default, you can have Integer.MAX versions. That potentially fills up memory pretty badly if you do a lot of component replacement. And Integer.MAX isn't the best guarantee to keep memory down either. Furthermore, it works pretty lousy with the new session store. That store saves every page/ version combination to disk, but including the whole version manager (all versions), which is inefficient. With this way of saving, you really don't need more than one. Anyway, to make a long story short here is what I think we should do: - Align pagemaps and version management so that pages and versions are stored in, and retrieved from the same entity. - Change the SecondLevelCacheSessionStore so that it either saves pages without the version manager but rather exactly as they are at that moment or save the first version as a full page, and subsequent versions as changes. This would be my choice as it is more efficient in especially storing it, and storing is the part having a greater impact than retrieving. - Page should only use a temporary instance of IPageVersionManager and the newVersionManager method could be private imo as I don't see much use now users being able to provide their own (in fact, we could get rid of the IPageVersionManager interface). When endVersion is called, the changes would be flushed and saved to the pagemap and the version manager instance should be nulled. WDYT? Eelco
Re: refactor storing pages and versions
Exactly. Eelco On 1/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i dont even see the point of having an IPageVersionManager. it is tied to Change which has an undo() method, so what other kind of manager can you write except the undo one? -igor On 1/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi, Currently, pages and versions of pages are stored separately. Pages are stored in IPageMaps, and each page has a IPageVersionManager. By default (and I wonder how many users actually ever did override this) the IPageVersionManager is UndoPageVersionManager, which keeps a list of changes in the instance. As the instance is kept as a reference of the page, the size of a page in a session is the sum of the size of the actual page at that time + the size of the list of all the changes. This is regardless of how the PageMap/ session store works unfortunately, and by default, you can have Integer.MAX versions. That potentially fills up memory pretty badly if you do a lot of component replacement. And Integer.MAX isn't the best guarantee to keep memory down either. Furthermore, it works pretty lousy with the new session store. That store saves every page/ version combination to disk, but including the whole version manager (all versions), which is inefficient. With this way of saving, you really don't need more than one. Anyway, to make a long story short here is what I think we should do: - Align pagemaps and version management so that pages and versions are stored in, and retrieved from the same entity. - Change the SecondLevelCacheSessionStore so that it either saves pages without the version manager but rather exactly as they are at that moment or save the first version as a full page, and subsequent versions as changes. This would be my choice as it is more efficient in especially storing it, and storing is the part having a greater impact than retrieving. - Page should only use a temporary instance of IPageVersionManager and the newVersionManager method could be private imo as I don't see much use now users being able to provide their own (in fact, we could get rid of the IPageVersionManager interface). When endVersion is called, the changes would be flushed and saved to the pagemap and the version manager instance should be nulled. WDYT? Eelco
Re: refactor storing pages and versions
oops. by so totally sure i meant not totally sure, of course ;-) Jonathan Locke wrote: the original idea was that you might want to version pages some other way. for example if you want to capture every last change to the page for sure at the cost of some extra memory, you could do a deep clone. i have no problem with getting rid of the interface and making the entire implementation private. when i wrote this, it seemed there might be other ways to do this. in hindsight, i think this is a job for the framework alone and not something we want people mucking with. given that, i don't think it matters how ugly the implementation is so long as it writes out just the diffs (retrievals of disk stored pages accessed with the back button will be quite rare so a greater cost of reconstructing is easily offset by a cheaper cost of writing the diffs). conceptually it now seems like the design has shifted indeed and that the logical place to put all the versioning is down inside the pagemap implementation such that it shares that information with whatever session store is in use. the session store would use the change information however it wants. in that manner someone could write their own versioning code if they really wanted to. but it would be a private implementation detail of the session store that nobody should ever see. so page would forward info to pagemap and pagemap to session store impl. so totally sure if that works out completely, but it's a thought. btw, SecondLevelCacheSessionStore seems a little fuzzy to me as a name. it presumes someone knows what a second level cache is. what about something a little more direct like maybe FileBackedSessionStore? not sure i love that either, but it's maybe a little more obvious. igor.vaynberg wrote: i dont even see the point of having an IPageVersionManager. it is tied to Change which has an undo() method, so what other kind of manager can you write except the undo one? -igor On 1/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi, Currently, pages and versions of pages are stored separately. Pages are stored in IPageMaps, and each page has a IPageVersionManager. By default (and I wonder how many users actually ever did override this) the IPageVersionManager is UndoPageVersionManager, which keeps a list of changes in the instance. As the instance is kept as a reference of the page, the size of a page in a session is the sum of the size of the actual page at that time + the size of the list of all the changes. This is regardless of how the PageMap/ session store works unfortunately, and by default, you can have Integer.MAX versions. That potentially fills up memory pretty badly if you do a lot of component replacement. And Integer.MAX isn't the best guarantee to keep memory down either. Furthermore, it works pretty lousy with the new session store. That store saves every page/ version combination to disk, but including the whole version manager (all versions), which is inefficient. With this way of saving, you really don't need more than one. Anyway, to make a long story short here is what I think we should do: - Align pagemaps and version management so that pages and versions are stored in, and retrieved from the same entity. - Change the SecondLevelCacheSessionStore so that it either saves pages without the version manager but rather exactly as they are at that moment or save the first version as a full page, and subsequent versions as changes. This would be my choice as it is more efficient in especially storing it, and storing is the part having a greater impact than retrieving. - Page should only use a temporary instance of IPageVersionManager and the newVersionManager method could be private imo as I don't see much use now users being able to provide their own (in fact, we could get rid of the IPageVersionManager interface). When endVersion is called, the changes would be flushed and saved to the pagemap and the version manager instance should be nulled. WDYT? Eelco -- View this message in context: http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8232968 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: refactor storing pages and versions
btw, SecondLevelCacheSessionStore seems a little fuzzy to me as a name. it presumes someone knows what a second level cache is. what about something a little more direct like maybe FileBackedSessionStore? not sure i love that either, but it's maybe a little more obvious. I don't know. It doesn't have to be stored in the file system (at least not according to the original idea) but could for instance be stored in a database system. Eelco
