Re: What is the best slideshow?
I really like Exposure that a friend of mine has made. There is no Wicket wrapper for it (yet) but you can easily integrate it yourself. http://exposureforjquery.wordpress.com/ // Daniel On 11 sep 2010, at 13:27, Paolo wrote: I found this: http://lazydev.ildella.net/wicket-slides-080-released-with-smoothgallery Is it the best solution to show a sequence of image? I don't like to use flash. And this use javascript, so it may be OK. thank you. - 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: Wicket vendor lockin and backwards compatibility, 1.4/1.5
Well... I'm in no position to say but I don't think the port 1.4-1.5 will be that expensive. With earlier versions there doesn't seem to have been much complaints. I would start with 1.4, don't worry, get my app deployed and then upgrade when it's time to upgrade. // Daniel jalbum.net On 21 maj 2010, at 14:57, napple fabble wrote: We're starting a new project and thinking about using Wicket for presentation layer. One concern is about backwards compatibility and support. I understand 1.5 is coming and in not fully backwards compatible. The concerns: If we start with wicket 1.4.8, a few years from now all development is done to 1.5.x and no one cares about boring old 1.4 anymore. No bugs will get fixed anymore and when Internet Explorer 10 is released, page markup, javascript, and AJAX features stop working. We need to do an expensive wicket 1.4-1.5 port for our application. Or, we start with wicket 1.5. It gets GA released whenever, and goes through a few years of being buggy and unmature. What's the best option to take now? How big are the backwards incompatible changes planned for 1.5? What's the schedule for 1.5? How mature are wicket x.0 releases usually? What's the track record on updating older releases? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vendor-lockin-and-backwards-compatibility-1-4-1-5-tp2226109p2226109.html Sent from the Wicket - User 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Ajax Channels
Hello Xavier, you can override AbstractDefaultAjaxBehavior.getChannelName() to return something|d and the channel will switch to drop behavior. I'm still using 1.3 so it may be different in 1.4. I've seen no documentation other than the code itself, but if my memory serves me right there are no other options. // Daniel jalbum.net On 27 feb 2010, at 13:59, Xavier López wrote: I've been facing a scenario where AJAX requests processing times were abnormally elevated. That situation has already been fixed (problem of AppServer configuration), but meanwhile, I was looking for some way to avoid queueing all requests, in a way such that only the last request should be processed (a good example would be an AutoComplete textfield). I found this post http://old.nabble.com/Discard-queued-ajax-requests-td27140816.html, on the same issue. The post states that using |d at the end of the ajax channel does the job. However, the only way I know to specify the channel is by making ajax calls from my code (js functions WicketAjaxGet/Post). There are some questions that pop up off my head, just out of curiosity: Is it possible to specifiy that channel, let's say, in an AjaxBehavior ? Looking through wicket-ajax.js i've seen the channel is defaulted to 0|s. What does that |s mean ? Is there any documentation on the flags like can (or seem to) be added to the channel ? Thanks! Xavier - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Discard queued ajax requests
Found the answer. If we set the channel name to something that ends with |d (pipe d) the channel changes to drop behavior. Great! (but a bit obscure) // Daniel On 2010-01-13, at 08:52, Daniel Frisk wrote: Wicket friends, another question regarding high latency. Here is the scenario: * I have a lot of network latency so all ajax requests have considerable delay. * User types in a form that submit itself on every keyup event * All but the first submit is queued since the ajax channel is busy Now when the first submit is processed I would like to somehow prune the queue so that only the last submit is processed and all other submits are discarded. Can this be done? // Daniel jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
New photo album generator
Our fancy new Wicket/jQuery/Flash photo album generator, soon ready to be released. What do you think so far? http://jalbum.net/beta/camelot/ // Daniel Frisk jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: New photo album generator
Damn, you found one of the few remaining jsp-pages :-) The map scrolls around to show the latest downloads, it's supposed to be a feature not a bug... // Daniel jalbum.net On 2010-01-12, at 10:54, Major Péter wrote: Hi, The site looks great, nice UI! I think I found some problem on: http://jalbum.net/maps/downloads.jsp (JSP :) ) Here if I zoom in on Europe with double clicks, there is a point where the app is taking control and the map goes to Tokyo, or random parts of the earth, but I guess I've just got lost on the camelot page. :( Regards, Peter 2010-01-12 10:23 keltezéssel, Daniel Frisk írta: Our fancy new Wicket/jQuery/Flash photo album generator, soon ready to be released. What do you think so far? http://jalbum.net/beta/camelot/ // Daniel Frisk jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: New photo album generator
Ohh, but thank you :) We still have some polishing to do before releasing, we want to scale huge images before uploading and such. So far we have rolled our own integration and not used WiQuery. I'm a bit new to jQuery but we seem to have great use for it both here and there, I will probably have a look at WiQuery again and not be such a stubborn NIH guy. // Daniel Frisk jalbum.net On 2010-01-12, at 10:34, Stijn Maller wrote: Simply WOW! What's not to like? :o) Just out of interest, did you use WiQuery? 2010/1/12 Daniel Frisk dan...@jalbum.net Our fancy new Wicket/jQuery/Flash photo album generator, soon ready to be released. What do you think so far? http://jalbum.net/beta/camelot/ // Daniel Frisk jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: New photo album generator
Not yet. Also this will not be released as general component (a least not now) for developers, it's intended for end users of the site only. // Daniel Frisk jalbum.net On 2010-01-12, at 10:34, Martin Makundi wrote: Is there a tutorial how to use it? ** Martin 2010/1/12 Daniel Frisk dan...@jalbum.net: Our fancy new Wicket/jQuery/Flash photo album generator, soon ready to be released. What do you think so far? http://jalbum.net/beta/camelot/ // Daniel Frisk jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: New photo album generator
That explains it... The button is a flash-movie which we use to upload photos, no fallback yet. // Daniel Frisk jalbum.net On 2010-01-12, at 12:25, Reinout van Schouwen wrote: Op dinsdag 12-01-2010 om 10:23 uur [tijdzone +0100], schreef Daniel Frisk: Our fancy new Wicket/jQuery/Flash photo album generator, soon ready to be released. What do you think so far? It's looking very nice but I can't press the Upload photos button. It seems to be disabled or overlaid by some Flash layer?! (I'm not using Adobe Flash but swfdec. Anyway I try to evade Flash where I can.) regards, -- Reinout van Schouwen - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Throttled AjaxFormSubmitBehavior
Wicket afficianados, I'm optimizing our application for high network latency and have found some questions/issues that I thought the list might help me with. Throttled AjaxFormSubmitBehavior I have a form which submit itself on keyup events, naturally I want to throttle that so I set a throttle limit with setThrottleDelay(...). Now this is what happens: I start typing in the form and after a delay the form is submitted. But if I continue writing during processing of that first ajax request one message per keyup is postboned and queued. When the first submit finish the form continue to submit the keystrokes one by one until the queue is empty. Bug, feature or crappy code on my behalf? // Daniel jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Discard queued ajax requests
Wicket friends, another question regarding high latency. Here is the scenario: * I have a lot of network latency so all ajax requests have considerable delay. * User types in a form that submit itself on every keyup event * All but the first submit is queued since the ajax channel is busy Now when the first submit is processed I would like to somehow prune the queue so that only the last submit is processed and all other submits are discarded. Can this be done? // Daniel jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Open Source projects using Wicket
Pushing definitely is more performance efficient - you know exactly when and where you push it and it's easy (happy-day-scenario) to optimize. Partly the ease of optimization results from difficulty of making complex relations. I would expect push to put more load on your servers due to serializing to second level cache, and getting a page back from that cache might also be more expensive. Of course, it depends where you pull from. And then when you're within one request, you probably have that data you'd push already in memory (e.g. Hibernate's session cache if you use that), so it might not be more expensive in that sense either. I do agree that pull models can lead to more complex structures, but that also depends on what kind of models you use (e.g. reflection based models actually can save code, but obviously using lots of anonymous classes won't). :-) Eelco A third option, which from my POV is perhaps the most elegant, is to roll your own page store that serializes the pages instantly after the request. The serialization have special hooks to replace entites or whatever that you would prefer to have as LDM with a placeholder that just stores the type and id when serialized. When/if the page is later deserialized you get the entity fresh from your object repository (cache). Why is this elegant? You get the programming model of push with the benefits of pull without writing any code for model proxies. I have communicated this idea before but nobody but me seems to prefer it, I'm actually surprised :-) // Daniel jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Open Source projects using Wicket
Of course, serialization isn't always necessary but in this case the idea was to _enforce_ serialization. The cost of serialization compared to the actual page construction time (often with database accesses and such) seems to often be very small. Scalability is the same as for using explicit LDMs in your code. Once you have set it up you can never forget to detach stuff and end up with an overstuffed session. You don't have to serialize to disk either you can keep the data in memory or in your Terracotta cluster or whatever. I think it has clear advantages to explicit model proxies. Models proxies are still necessary in some cases, but usually you can just put an entity in your component and it will work as if you had used LDMs. I'm not saying this is a golden... But it's a really nice alternative in many cases. // Daniel jalbum.net probably because serialization is not guaranteed. you can use a http session store on a single node cluster and never have anything serialized. -igor A third option, which from my POV is perhaps the most elegant, is to roll your own page store that serializes the pages instantly after the request. The serialization have special hooks to replace entites or whatever that you would prefer to have as LDM with a placeholder that just stores the type and id when serialized. When/if the page is later deserialized you get the entity fresh from your object repository (cache). Why is this elegant? You get the programming model of push with the benefits of pull without writing any code for model proxies. I have communicated this idea before but nobody but me seems to prefer it, I'm actually surprised :-) // Daniel jalbum.net
Re: Open Source projects using Wicket
I don't have a prepared sample, but that's a great idea. I will put one together (perhaps with Iolite). // Daniel jalbum.net Daniel do you have any sample code for this. Could be cool with a small quickstart, you could even use the Iolite for this, and drop it's ldms... 2009/10/16 Daniel Frisk dan...@jalbum.net Of course, serialization isn't always necessary but in this case the idea was to _enforce_ serialization. The cost of serialization compared to the actual page construction time (often with database accesses and such) seems to often be very small. Scalability is the same as for using explicit LDMs in your code. Once you have set it up you can never forget to detach stuff and end up with an overstuffed session. You don't have to serialize to disk either you can keep the data in memory or in your Terracotta cluster or whatever. I think it has clear advantages to explicit model proxies. Models proxies are still necessary in some cases, but usually you can just put an entity in your component and it will work as if you had used LDMs. I'm not saying this is a golden... But it's a really nice alternative in many cases. // Daniel jalbum.net probably because serialization is not guaranteed. you can use a http session store on a single node cluster and never have anything serialized. -igor A third option, which from my POV is perhaps the most elegant, is to roll your own page store that serializes the pages instantly after the request. The serialization have special hooks to replace entites or whatever that you would prefer to have as LDM with a placeholder that just stores the type and id when serialized. When/if the page is later deserialized you get the entity fresh from your object repository (cache). Why is this elegant? You get the programming model of push with the benefits of pull without writing any code for model proxies. I have communicated this idea before but nobody but me seems to prefer it, I'm actually surprised :-) // Daniel jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hippo's patch for wicket ids
Ok, I'm lazy and couldn't decipher that code at a glance. What does it
do?
// Daniel
jalbum.net
On 2009-10-15, at 03:09, Douglas Ferguson wrote:
Has anybody seen this:
http://www.onehippo.org/cms7/integration_testing.html
Seems like a nice alternative vs. having to set markupIds on all
components.
Thoughts?
They have a patch for wicket:
Index: jdk-1.4/wicket/src/main/java/org/apache/wicket/Session.java
===
*** jdk-1.4/wicket/src/main/java/org/apache/wicket/Session.java
(revision 724306)
--- jdk-1.4/wicket/src/main/java/org/apache/wicket/Session.java
(working copy)
***
*** 1475,1478
--- 1475,1489
{
return sequence++;
}
+
+ /**
+* Retrieves the next available session-unique value for the
supplied Component
+*
+* @param component
+*the component which requests the generation of a
markup identifier
+* @return session-unique value
+*/
+ public Object getMarkupId(Component component) {
+ return new Integer(nextSequenceValue());
+ }
}
Index: jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
===
*** jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
(revision 724306)
--- jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
(working copy)
***
*** 1426,1437
return null;
}
! final int generatedMarkupId = storedMarkupId instanceof Integer
! ? ((Integer)storedMarkupId).intValue() : Session.get
().nextSequenceValue();
!
! if (storedMarkupId == null)
! {
! setMarkupIdImpl(new Integer(generatedMarkupId));
}
// try to read from markup
--- 1426,1445
return null;
}
! String markupIdPostfix;
! if (!(storedMarkupId instanceof Integer)) {
! Object markupIdFromSession =
Session.get().getMarkupId(this);
! if (storedMarkupId == null markupIdFromSession !=
null) {
! setMarkupIdImpl(markupIdFromSession);
! }
! storedMarkupId = markupIdFromSession;
! }
! if (storedMarkupId instanceof Integer) {
! markupIdPostfix = Integer.toHexString(((Integer)
storedMarkupId).intValue()).toLowerCase();
! } else if (storedMarkupId instanceof String) {
! return (String) storedMarkupId;
! } else {
! markupIdPostfix = storedMarkupId.toString();
}
// try to read from markup
***
*** 1449,1455
markupIdPrefix = getId();
}
- String markupIdPostfix = Integer.toHexString
(generatedMarkupId).toLowerCase();
markupIdPostfix = RequestContext.get().encodeMarkupId
(markupIdPostfix);
String markupId = markupIdPrefix + markupIdPostfix;
--- 1457,1462
Then in their session, they return stable ids
private MapString,Integer pluginComponentCounters = new
HashMapString,Integer();
// Do not add the @Override annotation on this
public Object getMarkupId(Component component) {
String markupId = null;
for (Component ancestor=component.getParent(); ancestor!
=null markupId==null; ancestor=ancestor.getParent()) {
if (ancestor instanceof IPlugin || ancestor instanceof
Home) {
markupId = ancestor.getMarkupId(true);
break;
}
}
if (markupId == null) {
return root;
}
int componentNum = 0;
if (pluginComponentCounters.containsKey(markupId)) {
componentNum = pluginComponentCounters.get
(markupId).intValue();
}
++componentNum;
pluginComponentCounters.put(markupId, new Integer
(componentNum));
return markupId + _ + componentNum;
}
}
-
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
Open source Wicket blog
Hi, we have developed a blog tool in Wicket for our website. I just wanted to see if there is any interest in having that as an open source project? The code would have to be adopted for general use and be untangled from some dependencies that we don't want to open source, so I just want to check if there is any interest before doing the initial work. Not promising anything so don't start haunting me, but let me know if you are interested. Check it out at: http://jalbum.net/blog // Daniel jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Website 2.0
This isn't offical or anything but I know how interesting technical details are. So here it goes, just for you (and the list of course :-) Hits are ~10 MPages / day with thousands of new users each day so it's steadily increasing. We run our own hosting and try to keep it cost efficent. Separate clusters for community, widgets and Camelot. The community is based on Wicket, clustered with Terracotta and runs on Jetty. Database is MySql - Percona editon. That's about it. We also do a free downloadable desktop application for album generation, that I personally think is one of the best Java apps out there. // Daniel jalbum.net On 2009-10-13, at 17:04, Jeremy Thomerson wrote: Very nice work. Do you know about how many hits your site gets regularly? -- Jeremy Thomerson http://www.wickettraining.com On Tue, Oct 13, 2009 at 6:08 AM, Daniel Frisk dan...@jalbum.net wrote: Thanks guys! We are really happy with the site, it's getting there! I have no idea how many human-hours we have spent. It have gone thru a first incarnation and then some incremental refinements and finally this overhaul that we recently did. ~1000 perhaps, maybe? :-) // Daniel jalbum.net On 2009-10-13, at 10:23, Pieter Degraeuwe wrote: Indeed: nice piece of work ! On Tue, Oct 13, 2009 at 10:01 AM, Juri Prokofiev proj...@gmail.com wrote: This is a really nice work. Amazing! How many human-hours have you spent for development? - 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: Open source Wicket blog
We store the blog posts in a database. If we decide to open source it I will of course add some interface for generic storage so you can use whatever you see fit. Might include a file storage facility as default so you can get it up and running easily. // Daniel jalbum.net On 2009-10-14, at 10:23, da...@davidwbrown.name wrote: How are the blogs stored? Daniel Frisk dan...@jalbum.net wrote .. Hi, we have developed a blog tool in Wicket for our website. I just wanted to see if there is any interest in having that as an open source project? The code would have to be adopted for general use and be untangled from some dependencies that we don't want to open source, so I just want to check if there is any interest before doing the initial work. Not promising anything so don't start haunting me, but let me know if you are interested. Check it out at: http://jalbum.net/blog // Daniel jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Website 2.0
We recently did a complete overhaul of our web site: reworked the graphics, refactoring, added some jQuery goodies and of course added lots of features. Wicket really continues to deliver! All in all it was a smooth operation. The complexity of the site continues to grow but we have managed to keep the codebase nice and tight with reusable components. I'm really proud of our work here so far. What ya think? http://jalbum.net // Daniel Frisk - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Website 2.0
Thanks Maarten, I'd usually describe our software in general as three thirds. We have written 1/3 that is OS, 1/3 isn't open source (yet... because of various reasons) and 1/3 is other open source projects that we use. No parts of our web site itself is open source (yet). We could probably separate our package structure at some point with an open and a closed part. I'll let you know when it happens. Sharp-eyed spotting that bug, I should fix that. // Daniel jalbum.net On 2009-10-13, at 11:56, Maarten Bosteels wrote: Hi David, The website looks great ! Is the wicket application open source ? I think there's a small bug on https://jalbum.net/signup Maybe it's intentional, but I couldn't see why: the first two labels are both linked to the input with id=username li label for=usernameName/label input id=id139 name=name value= class=bigtxt sbox hint type=text div id=id13b class=feedback/div /li li label for=usernameUsername/label input id=username name=userName value= class=bigtxt sbox hint type=text div id=id13c class=feedback/div /li regards Maarten On Tue, Oct 13, 2009 at 10:23 AM, Pieter Degraeuwe pieter.degrae...@systemworks.be wrote: Indeed: nice piece of work ! On Tue, Oct 13, 2009 at 10:01 AM, Juri Prokofiev proj...@gmail.com wrote: This is a really nice work. Amazing! How many human-hours have you spent for development? On Tue, Oct 13, 2009 at 9:54 AM, Daniel Frisk dan...@jalbum.net wrote: We recently did a complete overhaul of our web site: reworked the graphics, refactoring, added some jQuery goodies and of course added lots of features. Wicket really continues to deliver! All in all it was a smooth operation. The complexity of the site continues to grow but we have managed to keep the codebase nice and tight with reusable components. I'm really proud of our work here so far. What ya think? http://jalbum.net // Daniel Frisk - 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 -- 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Website 2.0
Thanks guys! We are really happy with the site, it's getting there! I have no idea how many human-hours we have spent. It have gone thru a first incarnation and then some incremental refinements and finally this overhaul that we recently did. ~1000 perhaps, maybe? :-) // Daniel jalbum.net On 2009-10-13, at 10:23, Pieter Degraeuwe wrote: Indeed: nice piece of work ! On Tue, Oct 13, 2009 at 10:01 AM, Juri Prokofiev proj...@gmail.com wrote: This is a really nice work. Amazing! How many human-hours have you spent for development? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Pimp your Wicket app!
Name of your application: http://jalbum.net Intranet or internet: [ ] intranet [X ] internet Public or private site: [ X] public [ ] private [ ] both Average number of concurrent users: ~500 Max number of concurrent users you have encountered: Don't know Average number of Wicket served requests per (business)day: ~20 M Number of servers running your Wicket frontend code: 4 Number of cores/CPUs per server: 4 Number of JVMs running on your server for Wicket frontend code: 1 Do these JVMs run in a cluster? [ X] yes [ ] no -Xmx setting (max memory) for your JVMs: 4 GB // Daniel jalbum.net On 2009-05-07, at 10:54, Martijn Dashorst wrote: I (and possibly the rest of the Wicket community) would like to know more about your deployed Wicket applications. Even though we have a page that enables everyone to list their Wicket application, it lacks the details we all crave for. So I'd like to invite everyone to share their setup with us. Now pimp your application! Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Caching of rendered panels
Great ideas! I think I will try to implement it is a WebComponent
decorator that can wrap a component and add the caching. I'll let you
know if it works out for me.
// Daniel
jalbum.net
On 2009-03-27, at 20:40, Matej Knopp wrote:
You have to be really brave to use IComponentSource :-)
It's almost never a good idea anyway. It makes sense if you have
container with big amount of small component and you can restore the
whole hierarchy from e.g. an entity Id.
but it was last time used with Wicket 1.3. There's not guarantee it
will work...
-Matej
On Fri, Mar 27, 2009 at 8:13 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
ive never had to do this, but maybe something like this will work :)
class myheavypanel implements icomponentsource {
private String cache;
public Component restoreComponent(String id) {
if (cache==null) {
return this;
} else {
return new label(id, cache).setescapemarkup(false);
}
}
public myheavypanel() {
.
add(new abstracttransformbehavor() {
public abstract CharSequence transform(final Component
component, final CharSequence output) {
myheavypanel.this.cache=output;
return output;
}});
}
}
its kinda hacky but might work :)
-igor
On Fri, Mar 27, 2009 at 11:50 AM, Daniel Frisk dan...@jalbum.net
wrote:
In our case it's not really that the rendering itself is taking to
long, it
is getting the data from the model (database) so your advice is in
some
sense correct. Restructuring the code so that we can efficently
cache the
model is a lot of work and I would prefer to somehow cache the
rendered
html.
So if we presume that I actually know what I am doing, any ideas
how it can
be done?
// Daniel
On 2009-03-27, at 19:23, Jeremy Thomerson wrote:
Don't share component instances across requests / especially
sessions.
Don't prematurely optimize.
Cache your model and test the rendering. If it really is taking
too long,
figure out why and worry about it then.
--
Jeremy Thomerson
http://www.wickettraining.com
On Fri, Mar 27, 2009 at 1:12 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
Hi,
I also thought about s.th. like this because we'll have very
complex
component graphs that have to be composed dynamically based on the
language of the user and ~3 other things. I thought about caching
complete component instances, but didn't come so far that I
thought
about how this could be integrated into wicket - perhaps dead
simple via
some
_cacheService.getReallyComplexComponentCached( complexComponent,
userInfo )
I don't know how cheap exactly rendering of our complex component
structure will be, but if this would take more than say 10
millis we
would also try to cache already rendered markup.
Cheers,
Martin
On Fri, 2009-03-27 at 16:49 +0100, Daniel Frisk wrote:
I have a situation where I have some panels which I want to
render say
at most once a minute and during that period they should be
static.
I tried a few approches which hasn't really worked out for me
so I
wanted to know if somebody has created such a thing or how this
could
be done. Ideas are also welcome...
// Daniel Frisk
jalbum.net
-
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
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Caching of rendered panels
I have a situation where I have some panels which I want to render say at most once a minute and during that period they should be static. I tried a few approches which hasn't really worked out for me so I wanted to know if somebody has created such a thing or how this could be done. Ideas are also welcome... // Daniel Frisk jalbum.net - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Caching of rendered panels
In our case it's not really that the rendering itself is taking to long, it is getting the data from the model (database) so your advice is in some sense correct. Restructuring the code so that we can efficently cache the model is a lot of work and I would prefer to somehow cache the rendered html. So if we presume that I actually know what I am doing, any ideas how it can be done? // Daniel On 2009-03-27, at 19:23, Jeremy Thomerson wrote: Don't share component instances across requests / especially sessions. Don't prematurely optimize. Cache your model and test the rendering. If it really is taking too long, figure out why and worry about it then. -- Jeremy Thomerson http://www.wickettraining.com On Fri, Mar 27, 2009 at 1:12 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, I also thought about s.th. like this because we'll have very complex component graphs that have to be composed dynamically based on the language of the user and ~3 other things. I thought about caching complete component instances, but didn't come so far that I thought about how this could be integrated into wicket - perhaps dead simple via some _cacheService.getReallyComplexComponentCached( complexComponent, userInfo ) I don't know how cheap exactly rendering of our complex component structure will be, but if this would take more than say 10 millis we would also try to cache already rendered markup. Cheers, Martin On Fri, 2009-03-27 at 16:49 +0100, Daniel Frisk wrote: I have a situation where I have some panels which I want to render say at most once a minute and during that period they should be static. I tried a few approches which hasn't really worked out for me so I wanted to know if somebody has created such a thing or how this could be done. Ideas are also welcome... // Daniel Frisk jalbum.net - 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: Wicket meetup in Switzerland?
We have had a little bit of both languages. Most swedes are resonable proficent in english so we have used that when not all attendes know swedish. If you have some business planned in Stockholm you are more than welcome! // Daniel jalbum.net On 2009-02-22, at 22:03, Nino Martinez wrote: What language are it in? Swedish? Or English? regards Nino Daniel Frisk wrote: I can't complain, our meetings in Stockholm/Sweden have always been attended by usually 20-30 people or so. We have had some really great presentations and very intresting discussions. If you want to get notified of the upcoming meetings (one might be coming soon it's long overdue) sign up at our google group at http://wicket.jalbum.net // Daniel jalbum.net On 2009-02-22, at 12:45, Nino Martinez wrote: Yeah We have trouble here in Denmark too, all our events has only been max 5 people... So Cemal if you know of anyone who could be interested in a WUG DK please tell.. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket meetup in Switzerland?
I can't complain, our meetings in Stockholm/Sweden have always been attended by usually 20-30 people or so. We have had some really great presentations and very intresting discussions. If you want to get notified of the upcoming meetings (one might be coming soon it's long overdue) sign up at our google group at http://wicket.jalbum.net // Daniel jalbum.net On 2009-02-22, at 12:45, Nino Martinez wrote: Yeah We have trouble here in Denmark too, all our events has only been max 5 people... So Cemal if you know of anyone who could be interested in a WUG DK please tell.. jWeekend wrote: Thomas, This is partly because, strange as it may seem, not everyone that develops with Wicket uses this list. We have clients and students that have come over for jWeekend Wicket courses from Switzerland and for our http://jWeekend.com/dev/LWUGReg/ London Wicket Events - I have never seen them post here, although they really enjoy Wicket. If it looks like you'll be going ahead let me know if you like me to contact them about your idea. You are also more than welcome to visit us at our next London Wicket Event (which will be on April 1st, at Google - details to be confirmed) that has gone from strength to strength in nearly 2 years since jWeekend founded it with Al Maw, but we also experienced quiet moments, especially during the first 6 months. In fact, despite regularly getting up to 50 people registering these days, it's very rare that our guests will post here afterwards saying how much they enjoy our events so others will know and come along, even though they tell us they love our events and keep coming back and wish we arranged more of them! We also offer to help people with their commercial/work projects during our events, I think that helped us build some momentum in the early days. The moral of the story is don't give up - you need to start somewhere, even if there's just a handful of you. What you may also find difficult at the start is getting enough people to prepare and deliver presentations that your guests would be willing to travel for. At the start it was just Al and I giving presentations, with maybe one other speaker if we were lucky. It took me several months to get that ball rolling smoothly, and even now we try to arrange things with our presenters several months in advance and jWeekend help with their presentation preparation and occasionally, cover their travel/ accommodation expenses. We give everyone Pizza too, and are almost always the last to leave the pub after the event! I think some of our hard-core regulars feel it's just a good night out, as we seem to attract a really good bunch of people - and, from my experience, that is representative of the Wicket community/users generally. Let me know if you think we can help with what you're starting up in Switzerland. Regards - Cemal http://jWeekend.com jWeekend Thomas Mäder-2 wrote: Whoa! The silence is deafening! Since I've had one answer in a week, I guess there is just no interest. Oh well... Thomas On Mon, Feb 16, 2009 at 12:04 PM, Thomas Mäder thomas.mae...@devotek-it.chwrote: Hi Folks, I would be willing to organize a Wicket meetup in Switzerland if there is enough interest. I propose a meeting somewhere in Zürich. The format I imagine is that participants could (don't have to) shortly (15-20min.) present their work with Wicket (demos are always nice). That would be followed by general mingling with drinks snacks. For the date, I would shoot for the week starting March 16, 17:30-20:30h. Would you be interested in participating in/hosting/sponsoring such a thing? Either reply here or to me privately, and if there is enough interest, I'll set up a thing on the wiki. Thomas -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch -- Wicket Eclipse Consulting www.devotek-it.ch thomasmaeder.blogspot.com - 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: Moving from Tapestry to Wicket?
I actually read your mail but I didn't quite get it, what is your main concern? It seems to me like Wicket would be a perfect fit to your four criteria. // Daniel jalbum.net On 2008-10-30, at 21:05, GK1971 wrote: Hi. I hope this email is appropriate for the forum - its my first time posting. My partner and I are in the process of working on a site that currently uses Tapestry 4 and must be reasonably scalable vertically (we have horizontally covered in a road map). I am looking around at technologies that we can pursue in the future that will provide us with a way of creating a wonderful experience for a user based on dynamic content with Java as a base language. I have used Tapestry 3 and 4 in prior lives in prior companies and as Tapestry 5 was still early a year ago when we started the project I decided to work with Tapestry 4 an understand that once the site was up and running we may look at rewriting the web layer in an updated framework, using the lessons we had learned along the way about our specific application. I have grown unhappy with Tapestry generally - for example, its clumsy handling of AJAX. Even a seasoned developer can write a Tapestry application which is incredibly complex and inefficient, also. I'm not certain its declarative approach in Tapestry 5 is a wise thing from a productivity point of view (maintenance). Debugging a Tapestry application can be difficult. I found myself looking at JSF, but we'd like to actually deliver a functioning site quickly and not have our hands tied by bureaucracy. I also looked into other frameworks, and short of writing something myself I have found the best for our needs to be Tapestry 5 (scares me - what will Tapestry 6 bring in terms of backward compatibility etc?) and Wicket. I'm liking the look of Wicket but I wondered if it would fill a few ideas I have. I have had significant issues with DOJO/Tapestry bugs that I cannot fix myself and that has limited productivity. I would like to write an AJAX library for myself and hook it into Wicket somehow. Would this be possible. I feel it may be a pain in Tapestry because there 'appears' to be such a high coupling with DOJO now. Would it be conceptually easy for me to write Javascript/AJAX and hook them into Wicket in a simple way? I understand Wicket has a good framework for AJAX but if I require to implement code of my own, is it easy to slip under the hood (with Tapestry this is very hard). Many forums have mentioned scalability is an issue, but I believe that this is down to an applications individual handling of state rather than the framework. Am I correct? I am not so worried about this vertical scaling as long as I can horizontally scale my application on many servers (which I can if I control state). What's the road map for Wicket? I understand it is now one of the main Apache projects (which is one reason I am looking at it), so I assume it won't disappear sometime next year after I have invested time and effort into developing with it. Please tell me you are not going to pull a 'Tapestry' on me and other users by making future versions so ridiculously incompatible I have to rewrite my project again? Honestly, I'm looking for a framework that will allow me to: 1) Utilize HTML templates (which you do, I understand). 2) Utilize CSS (which you do) files externally for my artist. 3) Utilize Javascript (which I assume you do). 4) Utilize a Java, component based web framework for creating a fast lightweight but rich user experience for my users (which I guess you do). I have just purchased Wicket in Action so as I can do some research, but I do appreciate your time if possible. Many thanks for your help, and your help. Regards, Graeme. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domain Model as interfaces
Hi, I'm not sure I understand exactly what is your problem but wouldn't something like this: Db4oImpl / JpaImpl / WhateverImpl ---extends--- AbstractBaseClassWithYourBusinessLogic ---implements--- YourInterface Where needed you would delegate to the base class (just adding the impl specific annotation). Just out of interest: do you really need to be able to easily switch between different persistence providers? // Daniel jalbum.net On 2008-10-16, at 03:00, Edgar Merino wrote: Hello, I couldn't find any other place to post this, so I'm doing it here, (it's related to java web development anyway). I've been working on a project where wicket has access to the domain layer through interfaces because I didn't want my project to depend on any dbms, however I've been thinking and the main problem here lies with db4o, since it cannot make use of JPA annotations on entities (domain models). I would like to get rid of those interfaces and use concrete implementations to handle business code inside the entities, but then the above problem arises. So what recommendations can you give to have a fully implemented domain model (using jpa annotations) but still be able to use any dbms (or orm/dmbs) without having to map those the domain model at the service layer? I hope I can get some feedback on this, as it has been the main problem I've been facing when coding scalable web applications. Regards, Edgar Merino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Open Modal Dialog at specific position on screen (not center)
Hi! You have to set the parameter wmode=opaque in your flash-object tag. That will make it a part of normal z-ordering. http://www.communitymx.com/content/source/E5141/wmodeopaque.htm // Daniel jalbum.net On 2008-10-14, at 22:42, groffhibbitz wrote: Hi, I'm running into a problem where my modal dialog is popping up, but being covered by a flash component that is on the page. The z-index seems to have nothing to do with this, as I can set the z-index of my flash component to - and z-index of the modal to 20001. All I want to do to solve this is not pop up the modal dialog in the center of the page (which is where the flash component is) but instead pop it up right above where the button I click is that opens it. Can I call a javascript function to move the modal once it has been shown? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Individual session timeout
Code example:
private static void setSessionTimeout(int seconds) {
HttpSession session = getHttpSession();
if (session != null) {
session.setMaxInactiveInterval(seconds);
}
}
private static HttpSession getHttpSession() {
WebRequest request = (WebRequest)
WebRequestCycle.get().getRequest();
return request.getHttpServletRequest().getSession();
}
// Daniel
jalbum.net
On 2008-09-26, at 14:34, Nino Saturnino Martinez Vazquez Wael wrote:
I mean the method on the ordinary java session
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpSession.html
You can get that from the wicket session... Or request cycle... I
cant remember..
Stefan Lindner wrote:
I forgut to tell you that I use Wicket 1.4 M3. I can't see any
settimeout-Method in Session.
Stefan
-Ursprüngliche Nachricht-
Von: Nino Saturnino Martinez Vazquez Wael [mailto:[EMAIL PROTECTED]
] Gesendet: Freitag, 26. September 2008 12:59
An: users@wicket.apache.org
Betreff: Re: Individual session timeout
session.settimeout() ?
Stefan Lindner wrote:
The global session timeout for all sessions can be set in the
web.xml
file. Is it possible to set an individual session timeout for each
session? E.g. depending on the user's role?
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Output streams from external servlet
I think this can be achived most easily with two requests. Create a
class called ExternalPanel that displays a page that redirects to the
servlet. Like this:
public class ExternalPanel extends Panel {
public ExternalPanel(String id, String url) {
super(id);
add(new InlineFrame(include, new RedirectPage(url)));
}
}
Hope this works for you.
// Daniel Frisk
jalbum.net
On 2008-06-25, at 01:28, krisNog wrote:
Hello everyone!
I have a question regarding external servlets. I have a panel that I
would
like to stream content into from an external servlet. The overridden
onRender method I'm using for the Panel is shown below where /
whatever is
the servlet that is outputting some arbitrary HTML that I would like
rendered in my wicket panel. I know this isn't the proper way of
doing
things but I have no control over the external servlet and need to
incorporate its output into my wicket panel...
My problem the code below dispatches to the servlet and the
servlet
begins streaming out of sequence from the wicket panel. So the html
from the
servlet starts streaming then the wicket page starts streaming and the
servlet html isn't within my wicket panel and then I start getting
errors
(shown after the onRender method)...
Please let me know if I'm not being clear enough I'd be happy to
elaborate!
protected void onRender(MarkupStream markupStream) {
ServletWebRequest servletWebRequest = (ServletWebRequest)
getRequest();
HttpServletRequest request =
servletWebRequest.getHttpServletRequest();
WebResponse webResponse = (WebResponse) getResponse();
HttpServletResponse response =
webResponse.getHttpServletResponse();
RequestDispatcher dispatcher =
request.getRequestDispatcher(/whatever);
try {
dispatcher.include(request, response);
response.flushBuffer();
} catch (ServletException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
} catch (IOException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
}
Error stack trace:
ERROR - WicketFilter - closing the buffer error
java.lang.IllegalStateException: getWriter can't be used after
getOutputStream was invoked
at
org
.apache
.jetspeed
.aggregator
.impl.HttpBufferedResponse.getWriter(HttpBufferedResponse.java:68)
at
javax
.servlet
.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:112)
at
org.apache.wicket.protocol.http.WebResponse.write(WebResponse.java:
355)
at
org
.apache
.wicket
.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:73)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:
391)
at
org
.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
199)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
215)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org
.apache
.catalina
.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)
at
org
.apache
.catalina
.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:594)
at
org
.apache
.catalina
.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at
org
.apache
.jetspeed
.dispatcher
.JetspeedRequestDispatcher.include(JetspeedRequestDispatcher.java:73)
at
org
.apache
.wicket
.protocol
.http.portlet.WicketPortlet.processRequest(WicketPortlet.java:519)
at
org
.apache
.wicket
.protocol.http.portlet.WicketPortlet.doView(WicketPortlet.java:416)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at
org
.apache
.jetspeed
.factory.JetspeedPortletInstance.render(JetspeedPortletInstance.java:
103)
at
org
.apache
.jetspeed
.container
.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:277)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
269)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org
.apache
.catalina
.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)
at
org
.apache
.catalina
.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:594)
at
org
.apache
.catalina
.core.ApplicationDispatcher.include
Re: Antwort: Re: Including wicket in JSPs?
Perhaps you can use object as a drop in replacement of iframe? I
haven't tested it in different web browsers so no guarantees from me :-)
object data=http://java.net; type=text/html/object
// Daniel Frisk
jalbum.net
On 2008-06-24, at 08:37, [EMAIL PROTECTED] wrote:
Hi Jim,
thank you for your suggestion, but we use XHTML 1.0 Strict, so we
can't
use IFrames.
Jan
jnorris [EMAIL PROTECTED] schrieb am 23.06.2008 18:26:27:
Hi Jan,
I have a legacy home-grown jsp application where I'm showing wicket
pages in
the content area using an inframe tag. Initially I had a problem
that
turned out to be caused by not using the closing tag for the iframe.
Here's
an example that works in IE6/7:
head
style type=text/css
iframe{ float:left; height:500px; width:100%; display:block;
frameborder:0;}
/style
/head
body
jsp:include page=/leftside.jsp flush=true /
jsp:include page=/top.jsp flush=true /
iframe src=http://someserver/WicketDemoPage?someparm=somevalue;
frameborder=0/iframe
jsp:include page=/bottom.jsp flush=true /
jsp:include page=/rightside.jsp flush=true /
/body
This technique works for me with bookmarkable pages, so in the above
case
the following would be put in the init() method of the Application
class:
mountBookmarkablePage( /WicketDemoPage, WicketDemoPage.class );
HTH,
Jim
Jan.Koops wrote:
Hello !
We are using a JSP-based content management system for navigation,
page
layout etc.
Now we're evaluating Wicket as our application framework: A Wicket
application should appear in the center of the JSP based layout and
navigation.
Has somebody already included a wicket page via jsp:include or other
ways?
It seems to me a Page would be the wrong Wicket component to
include,
since no body or header should be rendered.
Best regards
Jan
--
View this message in context: http://www.nabble.com/Including-
wicket-in-JSPs--tp18071635p18072855.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: idea: automatic component repo
A friend of mine has a motto Appearence is everything. If this component marketplace also get a reasonably sexy frontend it could be a real winner. We have developed a kind of Theme marketplace for our photo album software but since we are tech guys we suitably named it Skin repository http://jalbum.net/skins It has been a HUGE success and it's dead easy to install new skins for the end users. We as developers are of course more advanced users and could just as easy do a cvs/svn checkout. But it's not as easy and available, and even developers are as lazy (and not to mention busy) as everyone else. I for one would love to browse this component marketplace and checkout demos of fancy stuff! // Daniel Frisk jalbum.net On 2008-06-19, at 10:17, Jonathan Locke wrote: this sort of marketplace might give JSF's claim to have lots of prefab components a real run for the money... i think with some effort, we could do this in a few weeks... Jonathan Locke wrote: was thinking the same thing and would be the icing on the cake. website never shuts down... crawler adds components and the demos just appear on the site automagically via OSGi. mebbe we need cheeser's transparent OSGi first though? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WUG (wicket user group) @ Øredev
We might show up with a small team from the north :-) But nothing decided yet, november is after the summer and ages away. I don't think you have to worry. when we have had the WUG meetings in Stockholm people have always been very late with registering. // Daniel jalbum.net On 2008-06-18, at 13:36, Martijn Dashorst wrote: I'll turn up :). And even try to do a presentation myself (not sure about what, but something about integrating with some google goodness) Martijn On Wed, Jun 18, 2008 at 1:25 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Guys, I think this thread are taking a wrong turn, could you please keep it a bit serious, i'd like to hear if anybody has intent to show up? It'll be really bad publicity for wicket if it are arranged and then nobody shows up. This is why I'd like an indicator on it. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localizer cache with 150.000+ entries causing OutOfMemory
So the patch did help? I too have observed this problem but it was at the moment less of a problem than other heap eaters, now this is next in line. We have added a script which automatically restarts the server when repeated OOME occurs and are down to a couple of times per week without the patch. But still, who wouldn't want to see months of uptime... // Daniel jalbum.net On 2008-06-10, at 11:29, Stefan Fußenegger wrote: Hi Igor, Thanks for your quick reply and the patch, sorry for not searching the mailinglist only but not JIRA. Your patch was for 1.4, I applied it to 1.3.3, created a quickstart including JUnit test and attached it to the JIRA issue. Hope this fix gets into the next maintenance release. I am to lazy to create a properly patched jar and a MVN repo for my team right now ;) Regards, Stefan igor.vaynberg wrote: try applying this patch and see if it helps https://issues.apache.org/jira/browse/WICKET-1667 -igor On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger [EMAIL PROTECTED] wrote: I am just analysing a heap dump (god bless the -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due to an OutOfMemoryError (GC overhead limit exceeded to be precise). Using jhat, the 175456 instances of class org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry immediately got my attention. While looking through the 107 instance of ConcurrentHashMap, I found one *really* big one: Localizer.cache has a hash table length of 262144, each of its 32 segments with about 5300 entries, where a hash key is a string, sometimes longer than 500 charactes, similar to (see Localizer.getCacheKey(String,Component)): fooTitle.bar- org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink- org.apache.wicket.markup.html.panel.Fragment:track- org.apache.wicket.markup.html.list.ListItem:14- my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos- org.apache.wicket.markup.html.list.ListItem:0- my.company.BarListPanel$1:bars-my.company.FooListPanel:panel- my.company.boxes.BodyBox:2- org.apache.wicket.markup.repeater.RepeatingView:body- my.company.layout.Border:border-my.company.pages.music.FoobarPage: 43-de-null Those numbers pretty much convinced me: The localizer cache has blown away my application. Looking at this hash keys, I suspect the following problem: those strings are constructed from the position of a localized String on a page, which is quite a bad thing if you use nested list views or repeating views to construct your page. For instance, I have a panel with a long (pageable) list of entries, might be 5000 entries which might appear on various positions in a repeating view I use as a container for most of my pages. Let's say there are 5 possible positions, this would cause 2500 thousand cached entries, each with a key of 300+ characters plus some more characters for the cached message - feel free to do the maths. From a quick estimate I'd say: No wonder, this has blown away my app. As a quick fix, I'd suggest to regularly clear the localizer cache, use a more sophisticated cache (that expires old entries once in a while!!) or to disable the cache completely. However, don't try to overwrite Localizer.newCache() and clear the cache regularly: clearCache() will replace your cache with a ConcurrentHashMap (not using Localizer.newCache()). However, quite unlikely, that this will happen as newCache() is private anyway ;) I am going to add some code to clear the cache regularly. Best regards, Stefan PS: I'll also create a JIRA issue, but I am really short on time right now. - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17751273.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
I have to admit I haven't read thru all of this thread, so my answer might be to something else... But here we go: I think we actually do something very similar to this in our system, we automatically detach any instances of jpa-enitities (replacing them with a surrogate with only the class and id) and then get them again from the db-cache if the page is reconstructed again. So far it works like a charm and the programming model is very convinient. Just dump whatever entity you like as member of a component and it is automatically detached and then loaded back when needed. I implemented this by hooking in to serialization, just checking each object in ObjectOutputStream.replaceObject and ObjectInputStream.resolveObject. Also had to use my own PageMapEntries to get a suitable hook. Might work as an idea for your implementation perhaps? // Daniel jalbum.net On 2008-06-04, at 19:03, Eelco Hillenius wrote: On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... I tried to write this two days ago, but wasn't able to pull it off... I wrote an instantiation listener that introspected on the fields of components and replaced IModel members with a proxy. These proxies would register themselves with the request cycle for cleaning up whenever the getObject was called, and the request cycle then would go through the list of registered models and detach them at the end of the request. The problem I ran into however is that these members can be final, assigned at a later stage (typically are actually) and such. But if there is some way to automatically detach model members, we could get rid of the model member in component and instead just let components have models by default where it actually always makes sense, such as form components. Anyway, that's something for 1.5. If it is fixable, I think that would be the way out of the generics controversy :-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
I implemented this by hooking in to serialization, just checking each object in ObjectOutputStream.replaceObject and ObjectInputStream.resolveObject. Also had to use my own PageMapEntries to get a suitable hook. Might work as an idea for your implementation perhaps? That's a cool idea for individual projects. For Wicket in general however, the problem would be that it wouldn't work for every session store (it wouldn't for instance for HttpSessionStore which doesn't serialize on each request). Also, 1.3's default session store serializes on each request, but does not reuse that serialized instance until the back button is used (or if you're doing session replication and come in through another node I guess). Are you sure your detachment works like you think it does? Well... I haven't actually hooked into the SessionStore but instead have implemented a special PageMapEntry that stores a serialized page with my special serialization (hooked in by overridden getPageMapEntry(...) in my BasePage). The special serialization takes place when the page is put into the pagemap. If the pagemap entry should be stored to disk later it is an object with serialized data that gets serialized again. I'm pretty sure it works as I intended and it might be generalized. The programming model sure is very nifty. // Daniel jalbum.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Meetup in Stockholm/Sweden - 22/5
On Thursday @ 4PM it's time for our next meetup in Stockholm. This time we have four Wicket related presentations and on top of that free beer and a poker tournament! :-) More information at http://wicket.jalbum.net and don't forget to drop me an e-mail to tell that you are coming. // Daniel jalbum.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance question
Maybe the profiler that is bundled with NetBeans can be sufficent? http://profiler.netbeans.org/ // Daniel jalbum.net On 2008-04-15, at 09:41, Johan Compagner wrote: you can use this one for a while http://yourkit.com/eap/index.jsp not everything has to be opensource or free johan On Tue, Apr 15, 2008 at 12:39 AM, Ritz123 [EMAIL PROTECTED] wrote: Havent used a profiler in a while - is there any opensource one which can work with tomcat? igor.vaynberg wrote: profile it and see where the time goes, or paste some code from those pages -igor On Mon, Apr 14, 2008 at 2:57 PM, Ritz123 [EMAIL PROTECTED] wrote: Hi, I have created first couple of pages of my wicket application but have some performance concerns. The pages (even the refresh alone takes 6-7 secs on Dual Core 2.2GHz Pentium with 4GB of RAM). DB is located on the remote host, but has caching at the application server - so thats not adding to the latency for the refresh. Here is the requestlogger information for the home page refresh couple of times Can someone point me to the direction on going about finding out what is taking this long other than (and may be simpler than) running a profiler on the application - atleast initially. My application is running in deployment mode and is running in tomcat. = ! before getting top nav menuitems 1208209856242 ! after getting top nav menuitems 1208209860972 time taken 4730 2008-04-14 14:51:07,677 (http-0.0.0.0-8080-Processor12) [ RequestLogger.jav a:320:INFO ] time=11567,event=BookmarkablePage[com.neobits.web.pages.Index],resp onse = BookmarkablePage [com.neobits.web.pages.Index],sessionid=729B1C0D58665D15518 044E5C8A63088.jvm1,sessionsize=1177,sessionstart=Mon Apr 14 14:38:51 PDT 2008,re quests =4,totaltime=28472,activerequests=3,maxmem=532M,total=266M,used=56M ! before getting top nav menuitems 1208209878458 ! after getting top nav menuitems 1208209878696 time taken 238 2008-04-14 14:51:25,266 (http-0.0.0.0-8080-Processor4) [ RequestLogger.java :320:INFO ] time =6888,event=BookmarkablePage[com.neobits.web.pages.Index],respon se = BookmarkablePage [com.neobits.web.pages.Index],sessionid=729B1C0D58665D1551804 4E5C8A63088.jvm1,sessionsize=1177,sessionstart=Mon Apr 14 14:38:51 PDT 2008,requ ests =5,totaltime=35360,activerequests=3,maxmem=532M,total=266M,used=55M ! before getting top nav menuitems 1208209893292 ! after getting top nav menuitems 1208209893526 time taken 234 2008-04-14 14:51:40,514 (http-0.0.0.0-8080-Processor6) [ RequestLogger.java :320:INFO ] time =7309,event=BookmarkablePage[com.neobits.web.pages.Index],respon se = BookmarkablePage [com.neobits.web.pages.Index],sessionid=729B1C0D58665D1551804 4E5C8A63088.jvm1,sessionsize=1177,sessionstart=Mon Apr 14 14:38:51 PDT 2008,requ ests =6,totaltime=42669,activerequests=4,maxmem=532M,total=266M,used=46M -- View this message in context: http://www.nabble.com/Performance-question-tp16690935p16690935.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Performance-question-tp16690935p16691538.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Our new and shiny Wicket site!
After a couple of months coding we have released our Wicket website! It has generally been a pleasure porting our jsp site and we have been able to add a lot of functionality as well. Check it out at http://jalbum.net // Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Our new and shiny Wicket site!
Thanks! We wrote our own grid for linking to the photo albums, and the actual albums are generated by our desktop client. The whole concept is a bit different than Flickr and it's not a one size fits all solution. // Daniel On 2008-02-28, at 02:41, Scott Swank wrote: Daniel, Nice site. Do you use pickwick for your photo albums or did you write your own? On Wed, Feb 27, 2008 at 5:30 PM, Nick Heudecker [EMAIL PROTECTED] wrote: +1 On Wed, Feb 27, 2008 at 7:23 PM, Matej Knopp [EMAIL PROTECTED] wrote: I don't think there is anything wrong with posting emails about new wicket based sites. Not everyone has the time to be checking wiki pages constantly. -Matej On Wed, Feb 27, 2008 at 11:30 AM, C. Bergström [EMAIL PROTECTED] wrote: On Wed, 2008-02-27 at 11:22 +0100, Daniel Frisk wrote: After a couple of months coding we have released our Wicket website! It has generally been a pleasure porting our jsp site and we have been able to add a lot of functionality as well. Check it out at http://jalbum.net I think this sort of enthusiasm is great, but a wiki page 'sites using wicket' has been created for this reason. I didn't read the site, but [1] is especially slow. I'd definitely profile that page and make sure you're both using caching and that your cache is tuned properly. Success! ./C [1] http://jalbum.net/skins/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Our new and shiny Wicket site!
We are definately going with more ajax and stuff! But first things first so we need to get it running super smooth and then we'll add the bling :-) // Daniel On 2008-02-28, at 08:23, Nino Saturnino Martinez Vazquez Wael wrote: Hi Daniel Looks nice, is a touch of ajax on its way(I think it kinds of makes the flow go a bit easyer) ? I noticed that your web container arent either picking up cookies thats why the jsession id are appended: http://jalbum.net/tour;jsessionid=B45F87100AAA623164CE4934FCB884B6 Theres a small guide on the wiki on howto forward stuff correctly if youre using apache and tomcat combo... regards Nino Daniel Frisk wrote: After a couple of months coding we have released our Wicket website! It has generally been a pleasure porting our jsp site and we have been able to add a lot of functionality as well. Check it out at http://jalbum.net // Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Model for previous pages
Thanks Igor, with some restructuring of the pages this should be just as useful and without the need to access previous pages. // Daniel On 2008-01-25, at 18:11, Igor Vaynberg wrote: string url=urlfor(getpage()); url=requestutils.toabsolutepath(url); pass url onto paypal to use as the return url and you will come back to the exact same page... -igor On Jan 25, 2008 5:13 AM, Daniel Frisk [EMAIL PROTECTED] wrote: We have a use case in our system where users are redirected to a third party web site (Paypal), they later get redirected back to our site. How is it now possible to access the previous page or the model for that page (if we assume that the user continue with the same session)? // Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Model for previous pages
We have a use case in our system where users are redirected to a third party web site (Paypal), they later get redirected back to our site. How is it now possible to access the previous page or the model for that page (if we assume that the user continue with the same session)? // Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
Thanks for your input guys, after some experimenting I used the annotation solution and got it working on 1.3 with some tweaking. I had to take out the IResponseStrategy and just override respond(..) in the RequestCycleProcessor instead. Also the redirection portion had to be rewritten as included below to get the paths right. I'll add my findings to the wiki page. --- redirect portion that has to be changed to get the paths right --- StringBuffer url = new StringBuffer(https://;); url.append(httpServletRequest.getServerName()); url.append(: + MyWebApplication.get().getHttpsPort()); url.append(webRequest.getHttpServletRequest().getContextPath()); url.append(webRequest.getServletPath()); webResponse.redirect(url.toString()); --- end of redirect portion --- // Daniel On 2007-09-25, at 08:00, Eelco Hillenius wrote: All the other encode methods get the proper wicket URL but doesn't prepend the webapp URI which this final encode method does. Beyond filing a RFE to either make this method non-final or provide a postEncode (RequestCycle, IRequestTarget) method before URL encoding, we will have to copy the entire class and provide this behavior. Thoughts? I stand by my suggestion that you could just try to redirect to a secure page. After that, the relative URLs stay secure no? If I'm missing something, please tell. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Redirect to HTTPS?
I'm trying to add a check to the constructor on one of our pages (a credit card processing page) which should: 1. If protocol is HTTPS; continue as usual 2. Else redirect so that HTTPS is used to access the same page I saw the sample in the wiki with the annotations that intercepted the request processing and etc but it seemed overly complicated for this tiny check, any ideas for a minimal implementation which could serve this purpose? // Daniel Frisk jalbum.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
Well... Now that was certainly helpful. This was not intended as a do my homework question, read it as: I don't know Wicket inside out yet and could use a hint if someone gets an idea from reading my question. You wasn't that someone today and you didn't help with your post, you lose karma :-) // Daniel On 2007-09-24, at 19:00, Igor Vaynberg wrote: just take whatever has been discussed on this list and strip it down to whatever level you need. i dont think any one is interesting in doing this for you... -igor On 9/24/07, Daniel Frisk [EMAIL PROTECTED] wrote: I'm trying to add a check to the constructor on one of our pages (a credit card processing page) which should: 1. If protocol is HTTPS; continue as usual 2. Else redirect so that HTTPS is used to access the same page I saw the sample in the wiki with the annotations that intercepted the request processing and etc but it seemed overly complicated for this tiny check, any ideas for a minimal implementation which could serve this purpose? // Daniel Frisk jalbum.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
User Group Stockholm/Sweden
Hi, we are currently adopting Wicket as our primary web framework (at jalbum.net) and these recent User Group activites seems like a good thing! I think everybody in Stockholm/Sweden who's got an intrest in Wicket should gather at our office and have good time while we share our Wicket experiences. Let us be the first to invite to a meeting at the 5th of November where Per Ejeklint has kindly agreed to present his cool application for remote controlling the heating of his summer house! For more information see: http://wicket.jalbum.net/ Send me an e-mail if you're coming, and we will bring the beer :-) // Daniel Frisk
User Group Stockholm / Sweden - Invitation
Hi, we are currently adopting Wicket as our primary web framework (at jalbum.net) and I got inspired by the recent User Group activites. I think everybody in Stockholm/Sweden who's got an intrest in Wicket should gather at our office and have good time while we share our Wicket experiences. Let us be the first to invite to a meeting at the 5th of November where Per Ejeklint has kindly agreed to present his cool application for remote controlling his summer house heating! For more information see: http://wicket.jalbum.net/ and send me an e- mail if you are coming. // Daniel Frisk ([EMAIL PROTECTED])
