Re: Dealing with transient and persistent objects in Wicket sessions and models
On 06/21/2015 08:05 PM, Don Ferguson wrote: For persistence, I use the ActiveObjects ORM library, originally developed by Daniel Spiewak and now actively maintained by Atlassian. In AO, database entities are described by java interfaces. For your use case (transient objects that may or may not be persisted), I use a dynamic proxy whose implementation can be serialized. When setters are called on the entity, the proxy stores the (unsaved) data in a HashMap. An actual database record is only created on an explicit call to entity.save(). By implementing it this way, panels that manipulate database records can operate on either new (transient) records or records that already exist. If the user cancels without saving, there is no detritus in the database to clean up. If anyone out there is interested in using AO with Wicket, I’d be happy to share my code experience. I like the AO programming model, and its support for automatic schema migration means that you can change table definitions by adding/removing setters and getters in the entity interfaces; AO can infer the SQL to migrate tables to the new schema. For a quick (but somewhat outdated) introduction to AO, see: https://activeobjects.java.net/0.8.2/ActiveObjects.pdf https://activeobjects.java.net/0.8.2/ActiveObjects.pdf The repository can be found here: https://bitbucket.org/activeobjects https://bitbucket.org/activeobjects It’s an obscure framework, but I find it a pleasure to use, and it plays reasonably well with Wicket. -Don Sounds interesting and I'll definitely be keeping an eye out for AO for future projects. But for my current project I'll have to stick with Hibernate and by hooking into the serialization process I have kind of made my own placeholder / proxy. That approach seems to work fine so far. Kind regards, Edmund - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AJAX refreshing of complex components (custom, ListViews and the like)
Good morning, This not a question that I'd like to ask here, it's rather something which I once thought about publishing on my blog but as it is a simple solution to a recurring problem, I post it here, as I haven't got a blog yet. I lack of time and, to be honest, I have kind of an ill health… So, AFAIK on this list, a recurring problem seems to be: how to refresh complex components, like repeaters, firstly, and how to do that efficiently, secondly. So from the top of my head, here is the general way to do the first thing, not for repeaters, but in general cases. Ready ? Component componentToRefresh = new Component(…); parent.addOrRemove(componentToRefresh); target.add(parent); It's so useful that I forced myself to learn it by hearth ;-) A good thing done isn't it? Now, let me explain why ListView and other components must be added to the page that way. I have not read myself that part of the Wicket source code. But for me, the logic is this : When you only write: target.add(componentToRefresh), Wicket looks for an HTML id in order to refresh the component. BUT if the component has changed so much that even it's id (generated or provided by you) is not reliable itself to identify it, what do you do? Fine wicketeers guys, correct me if I'm wrong but for me, here is why you must in some cases use the parent component's id. Think about a DataTable! The parent id is stable, not the cells' ones. Even if it's just an example. Now for the second part: how to do that efficiently (in terms of response times)? Some people, just like me, realized that for a ListView of potentially lots of data, or at least when it's costly to compute just a ListView element, it is still not perfect to use the parent. So they apparently read about the http://wicketinaction.com/ blog themselves and found a rather clean and efficient way to implement such a component: https://github.com/vineetsemwal/quickview (And my memory is still OK, apparently ;-) I read the documentation mentioned in the link above myself and it was sufficient to adapt the given syntax to a video game heavily based on Websockets with Atmosphere (cheers JF Arcand ;-), so I think I won't say more for the moment. As we say in France: Et voilà ! Many thanks for any feedback and: have a lot of fun! Pierre -- Je n'aime pas seulement ma vie, mais aussi celle des autres. (Blade Runner)
Re: Wicket with some servlet container on Android?
Guten Tag Martin Grigorov, am Sonntag, 21. Juni 2015 um 23:09 schrieben Sie: Netty doesn't support server side http sessions[...] When running in Android there will be just one client so it could be simplified. Exactly, one might even argue that using a session as cache only for performance related things may be unnecessary as well, because there's no server with high load and local flash storage is getting faster as well and such. But I guess that wouldn't simply things much because Wicket simply relies on a session, right? @Thorsten: please tell me that i-jetty works fine and let me enjoy the summer :-) I would love to, I hope I can give it a try in the next two weeks. Thank you guys for the very interesting details! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Is it possible to avoid serialization of page after ajax request?
We run into a disc and cpu bottleneck on a wicket page with 1+ users, that uses ajax updates via polling (AjaxSelfUpdatingTimerBehavior). The result of our investigation is that page store needs about 10ms for serialization, while the framework serializes and deserializes the same data again and again. The question is: is it possible to use a kind of copy on write-strategy in IPageStore, that keeps always the latest verison of the page in memory? At least for non-versioned pages it should be possible, but IManageablePage does not expose if the page is versioned or not. For versioned pages it's maybe not possible, because modifications are applied before the PageStore has a chance to make a copy of the page. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-avoid-serialization-of-page-after-ajax-request-tp4671295.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is it possible to avoid serialization of page after ajax request?
Hi, Check http://ci.apache.org/projects/wicket/guide/6.x/guide/internals.html#pagestoring The latest used page per user session is kept in the http session. It is a *live*, detached but not serialized java object. If Wicket cannot find it there then it will look for a serialized version of the page in the disk store. Later a page is stored to the page storages only if it was touched (see org.apache.wicket.page.IPageManager#touchPage) during the request cycle. So I guess in your case you have many writes to the disk because the page is loaded from the http session and then touched due to some logic in your application. Please check the user guide, see what exactly happens in your app and give more details so we can find a solution. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Jun 22, 2015 at 3:11 PM, Fridolin Jackstadt frid...@gmail.com wrote: We run into a disc and cpu bottleneck on a wicket page with 1+ users, that uses ajax updates via polling (AjaxSelfUpdatingTimerBehavior). The result of our investigation is that page store needs about 10ms for serialization, while the framework serializes and deserializes the same data again and again. The question is: is it possible to use a kind of copy on write-strategy in IPageStore, that keeps always the latest verison of the page in memory? At least for non-versioned pages it should be possible, but IManageablePage does not expose if the page is versioned or not. For versioned pages it's maybe not possible, because modifications are applied before the PageStore has a chance to make a copy of the page. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-avoid-serialization-of-page-after-ajax-request-tp4671295.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Version Support
On Mon, Jun 22, 2015 at 3:59 PM, Mihir Chhaya mihir.chh...@gmail.com wrote: Hello, This is regarding technical support for various Wicket Versions. I am aware of community and commercial support information available on Wicket website at https://wicket.apache.org/help/ But, I am looking for additional information on following: 1) Is there any strategy/rules for technical support available only from certain version and beyond? One might get support from community for any historical version, but Apache Wicket might no longer be releasing patch for those. There is no official support from us, since we are all volunteers :-). Your manager might become happy from a document on the wicket site claiming anything about our releases, but what actually matters is: - is anyone willing to fix an issue in any version at all - is it possible to craft a release for that version (for example 1.3 can't be built anymore within the team because of missing Java 1.4 JDKs for their platforms) 2) One of the developers from another team at my work location mentioned that only last two or three versions are supported at any given time. Could anybody please shed light on this? The current major release and the major release prior to that are actively supported. So currently that is 6.x and 1.5.x. Older releases might get security fixes. Which is not too bad, considering 1.5.x was crafted a long time ago, and most projects have migrated to 6.x. 3) Is there any link/documentation available which could be referred for managers to look at the Wicket website itself for the list of officially supported versions? This might sound weird to ask though, but it is just one of those 'Is it officially mentioned anywhere?' kind of question. This page provides some insight into which releases are supported. https://wicket.apache.org/start/download.html Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Version Support
Hello, This is regarding technical support for various Wicket Versions. I am aware of community and commercial support information available on Wicket website at https://wicket.apache.org/help/ But, I am looking for additional information on following: 1) Is there any strategy/rules for technical support available only from certain version and beyond? One might get support from community for any historical version, but Apache Wicket might no longer be releasing patch for those. 2) One of the developers from another team at my work location mentioned that only last two or three versions are supported at any given time. Could anybody please shed light on this? 3) Is there any link/documentation available which could be referred for managers to look at the Wicket website itself for the list of officially supported versions? This might sound weird to ask though, but it is just one of those 'Is it officially mentioned anywhere?' kind of question. Thanks, -Mihir.
Re: Wicket Version Support
Thanks, Martin for your guidance. On Mon, Jun 22, 2015 at 10:13 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Mon, Jun 22, 2015 at 3:59 PM, Mihir Chhaya mihir.chh...@gmail.com wrote: Hello, This is regarding technical support for various Wicket Versions. I am aware of community and commercial support information available on Wicket website at https://wicket.apache.org/help/ But, I am looking for additional information on following: 1) Is there any strategy/rules for technical support available only from certain version and beyond? One might get support from community for any historical version, but Apache Wicket might no longer be releasing patch for those. There is no official support from us, since we are all volunteers :-). Your manager might become happy from a document on the wicket site claiming anything about our releases, but what actually matters is: - is anyone willing to fix an issue in any version at all - is it possible to craft a release for that version (for example 1.3 can't be built anymore within the team because of missing Java 1.4 JDKs for their platforms) 2) One of the developers from another team at my work location mentioned that only last two or three versions are supported at any given time. Could anybody please shed light on this? The current major release and the major release prior to that are actively supported. So currently that is 6.x and 1.5.x. Older releases might get security fixes. Which is not too bad, considering 1.5.x was crafted a long time ago, and most projects have migrated to 6.x. 3) Is there any link/documentation available which could be referred for managers to look at the Wicket website itself for the list of officially supported versions? This might sound weird to ask though, but it is just one of those 'Is it officially mentioned anywhere?' kind of question. This page provides some insight into which releases are supported. https://wicket.apache.org/start/download.html Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
