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 AbstractReadOnlyModel<T>() { > 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 AbstractReadOnlyModel<String>() { >> >> 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 >> >> > > > -- > Pieter Degraeuwe > Systemworks bvba > Belgiëlaan 61 > 9070 Destelbergen > GSM: +32 (0)485/68.60.85 > Email: pieter.degrae...@systemworks.be > visit us at http://www.systemworks.be > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org