Re: When NOT to use models ?
it's more like an model graph.. so you say IModelListSomething dataFromDB=new LoadableDetachedModel() ... IModelInteger countModel=new CascadingLoad..ModelInteger,ListSomething(dataFromDB); add(new Label(counter,countModel)); countModel.detach() is called from Label, and dataFromDB.detach() is called fram countModel. Because it's generic you can use it everywhere.. Ok. I came up with something similar based on the assumption: models do not change during render. I made a ModelLatch that caches the model value after onBeforeRender and frees the latch at onDetach. The problem is that there is no onBeforeRender event and one must implement it for each container at least and for components that need it and are ajax updated without their parent container: public class ModelLatch implements IDetachable { private boolean latched; private boolean strict = true; /** * */ public void onBeforeRender() { this.setLatched(true); } /** * @see org.apache.wicket.model.IDetachable#detach() */ public void detach() { this.setLatched(false); } /** * @param DataType * @param DataTypeModel * @param dataTypeModel * @return IModelDataType */ public DataType, DataTypeModel extends IModelDataType IModelDataType getInstance( DataTypeModel dataTypeModel) { return new LatchModelDataType(dataTypeModel); } /** * @param latched the latched to set */ public void setLatched(boolean latched) { this.latched = latched; } /** * @return the latched */ public boolean isLatched() { return latched; } /** * @author Martin * * @param T */ private class LatchModelT implements IModelT { private IModelT rootModel; private boolean cached; private T cache; /** * @param rootModel */ public LatchModel(IModelT rootModel) { this.rootModel = rootModel; } /** * @see org.apache.wicket.model.IModel#getObject() */ @Override public T getObject() { if (isLatched()) { return getCachedValue(); } return rootModel.getObject(); } /** * @return T */ private T getCachedValue() { if (cached) { return cache; } try { return cache = rootModel.getObject(); } finally { cached = true; } } /** * @see org.apache.wicket.model.IModel#setObject(java.lang.Object) */ @Override public void setObject(T object) { if (isLatched() isStrict()) { throw new IllegalStateException(Strict latch does not allow modifying values in latched state.); } rootModel.setObject(object); } /** * @see org.apache.wicket.model.IDetachable#detach() */ @Override public void detach() { setLatched(false); cached = false; } } /** * @return the strict */ public boolean isStrict() { return strict; } } - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When NOT to use models ?
Am Montag, den 26.10.2009, 10:24 +0200 schrieb Martin Makundi: Hmm, maybe I'm missing something, but if you want to have EVALUATED once per request, I think the following should be sufficient. (unless I'm missing somtething) I want a generic centrally managed solution. I don't want to cache every model manually. we are using this one: http://www.wicket-praxis.de/blog/2009/01/03/modell-referenzen/ it's more like an model graph.. so you say IModelListSomething dataFromDB=new LoadableDetachedModel() ... IModelInteger countModel=new CascadingLoad..ModelInteger,ListSomething(dataFromDB); add(new Label(counter,countModel)); countModel.detach() is called from Label, and dataFromDB.detach() is called fram countModel. Because it's generic you can use it everywhere.. mm:) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When NOT to use models ?
Hmm, maybe I'm missing something, but if you want to have EVALUATED once per request, I think the following should be sufficient. (unless I'm missing somtething) new AbstractReadOnlyModelT() { private transient T cachedValue; @Override public T getObject() { if (cachedValue == null) { cachedValue = ...; //evaluate here, only once per request } return cachedValue; } }; since the cached value is transient, it will be null when it is deserialized. But during the requestCyclue, the evaluation will only happen once. (at least, if I'm not missing something...) On Sun, Oct 25, 2009 at 7:02 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: What I found was that I was instantiating my LDM's as private variables in my custom components but that they were not being detached. In this case you need to programatically register your non default models to participate in the detachment process. See the Wiki here for an example: http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models#WorkingwithWicketmodels-ManagingthelifecycleofnondefaultdetachableIModel%27s Which part there in particular? I read it and it didn't yet ring my bell... is there really another way to register for onDetach events apart from the model being directly involved in render cycle as a formcomponent's or another component's defaultmodel? For your option 3 I would say you should create a custom IModel implementation that is aware of your caching strategy so that your Component's don't need to care about how the data is loaded. Well.. that's the dream ;) Furthermore, I would like it to be more or less automatic. Maybe models like: 1. SettingThisModelWillResetCacheModel extends IModel 2. SettingThisModelWillNOTResetCacheModel extends IModel Furthremore, they would probably be created using a factory method in a cache manager: CacheManager cacheManager = new CacheManager(detachableToo); cacheManager.newIndependentCachedModel(IModel ...) cacheManager.newCachedModelWhoseChangeFiresExpire(IModel ...) AND maybe I could chain cacheManagers to say cache manger A will expire if any of its dependent managers B-C-D expire. Also it should be easy to add cacheManager.addCacheExpirationListener(Runnable ..) or something. ... Anybody else need something like this? We could write a draft and see if it works and continue improving the design. ** Martin Your implementation could hold a Map of all related models and update according to your rules or better yet build a service that does the caching and dirty detection and then just have the LDM source the cell value from the service. Something like: new LoabableDetachableModel () { protected CellValue load () { return cellService.getValue (row, col); } } Regards, Mike evaluated only one time per render can be done with LoadableDetachedModel .. I do not mean LOADED once per render. I mean EVALUATED once per render. In my understanding LoadableDetachableModel does not guarantee reset in any particular stage. can you explain it a littly bit (a link to your original message?) I mean for rexample I have many models like this: new AbstractReadOnlyModelString() { public String getObject() { // evaluate message with some logic return message; } } Furthermore, I have several components that, say, depend on this value. This getObject() will be called many times durung render and the logic will be evaluated many times. If I make it detachable it will yes be detached but I am not sure that the detaching is guaranteed at some specific point in request cycle? To make my use case more clear I will give an example: say I have a wicket page with a panel that contains a table with columns rows and y rows. Furthermore, let's assume it is a spreadsheet emulator: you can write formulas into the cells that depend on the other cells which means that the value of each cell is recursively evaluated dependent on the other cell's values. Requirements: 1. During render time each cell's model value should be cached once it has been evaluated (we do not want to recurse many times to fetch the same value). 2. If the value of any cell changes, all the dependent cells should be (for example) ajax refreshed and re-evaluated. For simplicity, we could re-set the cache of all models when change occurs. And redraw-all. 3. We want to reset cache ONLY if change occurs. In my understanding requirement 3 cannot be directly reached with detachable models. ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --
Re: When NOT to use models ?
Which is identical to the LoadableDetachableModel. Nothing in LDM states that it is meant exclusively for DB access. Martijn On Mon, Oct 26, 2009 at 8:52 AM, Pieter Degraeuwe pieter.degrae...@systemworks.be wrote: Hmm, maybe I'm missing something, but if you want to have EVALUATED once per request, I think the following should be sufficient. (unless I'm missing somtething) new AbstractReadOnlyModelT() { private transient T cachedValue; �...@override public T getObject() { if (cachedValue == null) { cachedValue = ...; //evaluate here, only once per request } return cachedValue; } }; since the cached value is transient, it will be null when it is deserialized. But during the requestCyclue, the evaluation will only happen once. (at least, if I'm not missing something...) On Sun, Oct 25, 2009 at 7:02 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: What I found was that I was instantiating my LDM's as private variables in my custom components but that they were not being detached. In this case you need to programatically register your non default models to participate in the detachment process. See the Wiki here for an example: http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models#WorkingwithWicketmodels-ManagingthelifecycleofnondefaultdetachableIModel%27s Which part there in particular? I read it and it didn't yet ring my bell... is there really another way to register for onDetach events apart from the model being directly involved in render cycle as a formcomponent's or another component's defaultmodel? For your option 3 I would say you should create a custom IModel implementation that is aware of your caching strategy so that your Component's don't need to care about how the data is loaded. Well.. that's the dream ;) Furthermore, I would like it to be more or less automatic. Maybe models like: 1. SettingThisModelWillResetCacheModel extends IModel 2. SettingThisModelWillNOTResetCacheModel extends IModel Furthremore, they would probably be created using a factory method in a cache manager: CacheManager cacheManager = new CacheManager(detachableToo); cacheManager.newIndependentCachedModel(IModel ...) cacheManager.newCachedModelWhoseChangeFiresExpire(IModel ...) AND maybe I could chain cacheManagers to say cache manger A will expire if any of its dependent managers B-C-D expire. Also it should be easy to add cacheManager.addCacheExpirationListener(Runnable ..) or something. ... Anybody else need something like this? We could write a draft and see if it works and continue improving the design. ** Martin Your implementation could hold a Map of all related models and update according to your rules or better yet build a service that does the caching and dirty detection and then just have the LDM source the cell value from the service. Something like: new LoabableDetachableModel () { protected CellValue load () { return cellService.getValue (row, col); } } Regards, Mike evaluated only one time per render can be done with LoadableDetachedModel .. I do not mean LOADED once per render. I mean EVALUATED once per render. In my understanding LoadableDetachableModel does not guarantee reset in any particular stage. can you explain it a littly bit (a link to your original message?) I mean for rexample I have many models like this: new AbstractReadOnlyModelString() { public String getObject() { // evaluate message with some logic return message; } } Furthermore, I have several components that, say, depend on this value. This getObject() will be called many times durung render and the logic will be evaluated many times. If I make it detachable it will yes be detached but I am not sure that the detaching is guaranteed at some specific point in request cycle? To make my use case more clear I will give an example: say I have a wicket page with a panel that contains a table with columns rows and y rows. Furthermore, let's assume it is a spreadsheet emulator: you can write formulas into the cells that depend on the other cells which means that the value of each cell is recursively evaluated dependent on the other cell's values. Requirements: 1. During render time each cell's model value should be cached once it has been evaluated (we do not want to recurse many times to fetch the same value). 2. If the value of any cell changes, all the dependent cells should be (for example) ajax refreshed and re-evaluated. For simplicity, we could re-set the cache of all models when change occurs. And redraw-all. 3. We want to reset cache ONLY if change occurs. In my understanding requirement 3 cannot be directly reached with detachable models.
Re: When NOT to use models ?
Hmm, maybe I'm missing something, but if you want to have EVALUATED once per request, I think the following should be sufficient. (unless I'm missing somtething) I want a generic centrally managed solution. I don't want to cache every model manually. ** Martin new AbstractReadOnlyModelT() { private transient T cachedValue; �...@override public T getObject() { if (cachedValue == null) { cachedValue = ...; //evaluate here, only once per request } return cachedValue; } }; since the cached value is transient, it will be null when it is deserialized. But during the requestCyclue, the evaluation will only happen once. (at least, if I'm not missing something...) On Sun, Oct 25, 2009 at 7:02 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: What I found was that I was instantiating my LDM's as private variables in my custom components but that they were not being detached. In this case you need to programatically register your non default models to participate in the detachment process. See the Wiki here for an example: http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models#WorkingwithWicketmodels-ManagingthelifecycleofnondefaultdetachableIModel%27s Which part there in particular? I read it and it didn't yet ring my bell... is there really another way to register for onDetach events apart from the model being directly involved in render cycle as a formcomponent's or another component's defaultmodel? For your option 3 I would say you should create a custom IModel implementation that is aware of your caching strategy so that your Component's don't need to care about how the data is loaded. Well.. that's the dream ;) Furthermore, I would like it to be more or less automatic. Maybe models like: 1. SettingThisModelWillResetCacheModel extends IModel 2. SettingThisModelWillNOTResetCacheModel extends IModel Furthremore, they would probably be created using a factory method in a cache manager: CacheManager cacheManager = new CacheManager(detachableToo); cacheManager.newIndependentCachedModel(IModel ...) cacheManager.newCachedModelWhoseChangeFiresExpire(IModel ...) AND maybe I could chain cacheManagers to say cache manger A will expire if any of its dependent managers B-C-D expire. Also it should be easy to add cacheManager.addCacheExpirationListener(Runnable ..) or something. ... Anybody else need something like this? We could write a draft and see if it works and continue improving the design. ** Martin Your implementation could hold a Map of all related models and update according to your rules or better yet build a service that does the caching and dirty detection and then just have the LDM source the cell value from the service. Something like: new LoabableDetachableModel () { protected CellValue load () { return cellService.getValue (row, col); } } Regards, Mike evaluated only one time per render can be done with LoadableDetachedModel .. I do not mean LOADED once per render. I mean EVALUATED once per render. In my understanding LoadableDetachableModel does not guarantee reset in any particular stage. can you explain it a littly bit (a link to your original message?) I mean for rexample I have many models like this: new AbstractReadOnlyModelString() { public String getObject() { // evaluate message with some logic return message; } } Furthermore, I have several components that, say, depend on this value. This getObject() will be called many times durung render and the logic will be evaluated many times. If I make it detachable it will yes be detached but I am not sure that the detaching is guaranteed at some specific point in request cycle? To make my use case more clear I will give an example: say I have a wicket page with a panel that contains a table with columns rows and y rows. Furthermore, let's assume it is a spreadsheet emulator: you can write formulas into the cells that depend on the other cells which means that the value of each cell is recursively evaluated dependent on the other cell's values. Requirements: 1. During render time each cell's model value should be cached once it has been evaluated (we do not want to recurse many times to fetch the same value). 2. If the value of any cell changes, all the dependent cells should be (for example) ajax refreshed and re-evaluated. For simplicity, we could re-set the cache of all models when change occurs. And redraw-all. 3. We want to reset cache ONLY if change occurs. In my understanding requirement 3 cannot be directly reached with detachable models. ** Martin - To unsubscribe,
Re: When NOT to use models ?
Martin Makundi wrote: Hmm, maybe I'm missing something, but if you want to have EVALUATED once per request, I think the following should be sufficient. (unless I'm missing somtething) I want a generic centrally managed solution. I don't want to cache every model manually. From what I get from your discussion, this might help http://www.codesmell.org/blog/2009/05/idetachlistener-saves-the-day/, which shows how to check for components' fields. ++ joseph - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When NOT to use models ?
What I found was that I was instantiating my LDM's as private variables in my custom components but that they were not being detached. In this case you need to programatically register your non default models to participate in the detachment process. See the Wiki here for an example: http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models#WorkingwithWicketmodels-ManagingthelifecycleofnondefaultdetachableIModel%27s Which part there in particular? I read it and it didn't yet ring my bell... is there really another way to register for onDetach events apart from the model being directly involved in render cycle as a formcomponent's or another component's defaultmodel? For your option 3 I would say you should create a custom IModel implementation that is aware of your caching strategy so that your Component's don't need to care about how the data is loaded. Well.. that's the dream ;) Furthermore, I would like it to be more or less automatic. Maybe models like: 1. SettingThisModelWillResetCacheModel extends IModel 2. SettingThisModelWillNOTResetCacheModel extends IModel Furthremore, they would probably be created using a factory method in a cache manager: CacheManager cacheManager = new CacheManager(detachableToo); cacheManager.newIndependentCachedModel(IModel ...) cacheManager.newCachedModelWhoseChangeFiresExpire(IModel ...) AND maybe I could chain cacheManagers to say cache manger A will expire if any of its dependent managers B-C-D expire. Also it should be easy to add cacheManager.addCacheExpirationListener(Runnable ..) or something. ... Anybody else need something like this? We could write a draft and see if it works and continue improving the design. ** Martin Your implementation could hold a Map of all related models and update according to your rules or better yet build a service that does the caching and dirty detection and then just have the LDM source the cell value from the service. Something like: new LoabableDetachableModel () { protected CellValue load () { return cellService.getValue (row, col); } } Regards, Mike evaluated only one time per render can be done with LoadableDetachedModel .. I do not mean LOADED once per render. I mean EVALUATED once per render. In my understanding LoadableDetachableModel does not guarantee reset in any particular stage. can you explain it a littly bit (a link to your original message?) I mean for rexample I have many models like this: new AbstractReadOnlyModelString() { public String getObject() { // evaluate message with some logic return message; } } Furthermore, I have several components that, say, depend on this value. This getObject() will be called many times durung render and the logic will be evaluated many times. If I make it detachable it will yes be detached but I am not sure that the detaching is guaranteed at some specific point in request cycle? To make my use case more clear I will give an example: say I have a wicket page with a panel that contains a table with columns rows and y rows. Furthermore, let's assume it is a spreadsheet emulator: you can write formulas into the cells that depend on the other cells which means that the value of each cell is recursively evaluated dependent on the other cell's values. Requirements: 1. During render time each cell's model value should be cached once it has been evaluated (we do not want to recurse many times to fetch the same value). 2. If the value of any cell changes, all the dependent cells should be (for example) ajax refreshed and re-evaluated. For simplicity, we could re-set the cache of all models when change occurs. And redraw-all. 3. We want to reset cache ONLY if change occurs. In my understanding requirement 3 cannot be directly reached with detachable models. ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When NOT to use models ?
Hi Martin, I saw the same type of behavior you are talking about with LoadableDetachableModels not detaching but AbstractReadOnlyModel's working properly. What I found was that I was instantiating my LDM's as private variables in my custom components but that they were not being detached. In this case you need to programatically register your non default models to participate in the detachment process. See the Wiki here for an example: http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models#WorkingwithWicketmodels-ManagingthelifecycleofnondefaultdetachableIModel%27s For your option 3 I would say you should create a custom IModel implementation that is aware of your caching strategy so that your Component's don't need to care about how the data is loaded. Your implementation could hold a Map of all related models and update according to your rules or better yet build a service that does the caching and dirty detection and then just have the LDM source the cell value from the service. Something like: new LoabableDetachableModel () { protected CellValue load () { return cellService.getValue (row, col); } } Regards, Mike evaluated only one time per render can be done with LoadableDetachedModel .. I do not mean LOADED once per render. I mean EVALUATED once per render. In my understanding LoadableDetachableModel does not guarantee reset in any particular stage. can you explain it a littly bit (a link to your original message?) I mean for rexample I have many models like this: new AbstractReadOnlyModelString() { public String getObject() { // evaluate message with some logic return message; } } Furthermore, I have several components that, say, depend on this value. This getObject() will be called many times durung render and the logic will be evaluated many times. If I make it detachable it will yes be detached but I am not sure that the detaching is guaranteed at some specific point in request cycle? To make my use case more clear I will give an example: say I have a wicket page with a panel that contains a table with columns rows and y rows. Furthermore, let's assume it is a spreadsheet emulator: you can write formulas into the cells that depend on the other cells which means that the value of each cell is recursively evaluated dependent on the other cell's values. Requirements: 1. During render time each cell's model value should be cached once it has been evaluated (we do not want to recurse many times to fetch the same value). 2. If the value of any cell changes, all the dependent cells should be (for example) ajax refreshed and re-evaluated. For simplicity, we could re-set the cache of all models when change occurs. And redraw-all. 3. We want to reset cache ONLY if change occurs. In my understanding requirement 3 cannot be directly reached with detachable models. ** Martin
When NOT to use models ?
Hi Recently, on the mailing list, I read quite some people saying basically than using models all over the place was a bad idea. Can someone explain it a bit more ? Indeed, I was kind of agreeing until recently, when I had an issue with a (self made) Behavior taking a string. I needed this string to be refresh on each page display... So what to do then ? Introduce a model to be able to use LoadableDetachableModel if needed (and maybe still providing a convenience method from string to modelString). So, since, I'm kind of thinking that as soon that you do a reusable component, you should use models if data is needed. The only proper use case I could think of for not using a model is through a convenience method or for a local only component. And even that is doubtful, I've already rewritten some locally used component then to a Model (instead of the initial string)... As such, in the end, using a model looks like a warranty against future changes. Do I miss some use cases ? thanks in advance joseph - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When NOT to use models ?
Hi! I have said that you might need to cache your model values, in some performance situations. If you do not use models, you do not need same kind of caching (because the value is fixed). Nevetheless, using models results in cleaner code, but I am dreaming of a centralized caching mechanism such that each model value would be evaluated only one time per render / model change. t. Martin 2009/10/23 Joseph Pachod j...@thomas-daily.de: Hi Recently, on the mailing list, I read quite some people saying basically than using models all over the place was a bad idea. Can someone explain it a bit more ? Indeed, I was kind of agreeing until recently, when I had an issue with a (self made) Behavior taking a string. I needed this string to be refresh on each page display... So what to do then ? Introduce a model to be able to use LoadableDetachableModel if needed (and maybe still providing a convenience method from string to modelString). So, since, I'm kind of thinking that as soon that you do a reusable component, you should use models if data is needed. The only proper use case I could think of for not using a model is through a convenience method or for a local only component. And even that is doubtful, I've already rewritten some locally used component then to a Model (instead of the initial string)... As such, in the end, using a model looks like a warranty against future changes. Do I miss some use cases ? thanks in advance joseph - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When NOT to use models ?
Am Freitag, den 23.10.2009, 15:06 +0300 schrieb Martin Makundi: Hi! I have said that you might need to cache your model values, in some performance situations. If you do not use models, you do not need same kind of caching (because the value is fixed). Nevetheless, using models results in cleaner code, but I am dreaming of a centralized caching mechanism such that each model value would be evaluated only one time per render / model change. evaluated only one time per render can be done with LoadableDetachedModel .. or do i miss some point? can you explain it a littly bit (a link to your original message?) mm:) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When NOT to use models ?
evaluated only one time per render can be done with LoadableDetachedModel .. I do not mean LOADED once per render. I mean EVALUATED once per render. In my understanding LoadableDetachableModel does not guarantee reset in any particular stage. can you explain it a littly bit (a link to your original message?) I mean for rexample I have many models like this: new AbstractReadOnlyModelString() { public String getObject() { // evaluate message with some logic return message; } } Furthermore, I have several components that, say, depend on this value. This getObject() will be called many times durung render and the logic will be evaluated many times. If I make it detachable it will yes be detached but I am not sure that the detaching is guaranteed at some specific point in request cycle? To make my use case more clear I will give an example: say I have a wicket page with a panel that contains a table with columns rows and y rows. Furthermore, let's assume it is a spreadsheet emulator: you can write formulas into the cells that depend on the other cells which means that the value of each cell is recursively evaluated dependent on the other cell's values. Requirements: 1. During render time each cell's model value should be cached once it has been evaluated (we do not want to recurse many times to fetch the same value). 2. If the value of any cell changes, all the dependent cells should be (for example) ajax refreshed and re-evaluated. For simplicity, we could re-set the cache of all models when change occurs. And redraw-all. 3. We want to reset cache ONLY if change occurs. In my understanding requirement 3 cannot be directly reached with detachable models. ** Martin mm:) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org