Re: Google App Engine and Wicket

2009-04-12 Thread Eelco Hillenius
 Both articles avoid the DiskPageStore problem by using the HttpSessionStore,
 however if you do a search through the mailing list archives for
 HttpSessionStore you'll find numerous references to problems in using it in
 the long term and especially in a real, production application, so I don't
 think that's a good long term solution, so my original question still
 stands. Is there an alternative or is Wicket perhaps not well suited for use
 in the App Engine.

It's probably a good idea to have a specialized implementation of
ISessionStore for App Engine that uses whatever makes sense with App
Engine for medium term storage ('cause that's what it is... short term
storage is the current page, which is typically local memory, and
older pages are used for the duration of the session, and typically
just keeping the last few in memory suffices.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Google App Engine and Wicket

2009-04-12 Thread Adriano dos Santos Fernandes

Maarten Bosteels wrote:

But AFAIK GAE doesn't use/guarantee sticky sessions, so I am afraid
you can't rely on local memory.

App Engine uses multiple web servers to run your application, and
automatically adjusts the number of servers it is using to handle
requests reliably. A given request may be routed to any server, and it
may not be the same server that handled a previous request from the
same user.
http://code.google.com/appengine/docs/java/runtime.html#Requests_and_Servlets

It would be interesting to test the performance of an ISessionStore
backed by the App Engine datastore.
FYI, I've put a app. with a static variable counter (just a static, not 
in session). And since two days there, the counter is maintained.


So I guess they solution uses something like Terracotta. BTW, they web 
server is Jetty.



Adriano


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: IMPORTANT: Nabble posting disabled due to spam

2009-04-12 Thread Luther Baker
Slightly o/t ...

Is there a way, in Gmane to limit the view to a bookmarkable tree of
responses to a single thread?

The frameset doesn't work for me since the articles I'm looking at don't
appear in the URL. The article specific url doesn't work for me since it
doesn't provide any context or reference to the tree.

Nabble does this

http://www.nabble.com/serialVersionUID-td23001300.html

Can Gmane do something similar?

http://news.gmane.org/group/gmane.comp.java.wicket.user/last=/force_load=t
http://news.gmane.org/gmane.comp.java.wicket.user
http://article.gmane.org/gmane.comp.java.wicket.user/66353

Thanks,

-Luther


On Mon, Mar 30, 2009 at 5:13 AM, Reinout van Schouwen rein...@gmail.comwrote:

 Op maandag 30-03-2009 om 11:54 uur [tijdzone +0200], schreef Martijn
 Dashorst:
  I've disabled posting through the Nabble interface because they don't
  seem able to prevent spam coming through their interface. If you want
  to ask a question, please subscribe to the list. If you don't want to
  do that, complain with Nabble support to improve their spam filtering.

 For people who dislike the large volume of mail caused by the
 mailinglist, I recommend the Gmane nntp/web interface:
 http://news.gmane.org/gmane.comp.java.wicket.user

 regards,

 --
 Reinout van Schouwen


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: serialVersionUID

2009-04-12 Thread Ben Tilford
I've always seen it done as public. Anyways I checked the javadoc and the
access modifier does not matter.

On Sun, Apr 12, 2009 at 1:56 AM, Eelco Hillenius
eelco.hillen...@gmail.comwrote:

  The purpose of the *public* static final long serialVersionUID is for
 long

 Why do you stress *public*? private is the norm for serialVersionUID.

 Eelco

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Google App Engine and Wicket

2009-04-12 Thread Maarten Bosteels
Good news:  
http://groups.google.com/group/google-appengine-java/msg/f50bbb131dc524c1

quote
HttpSessions will work out of the box if you enable them in your
appengine-web.xml.

We do not guarantee that all requests for the same session go to the same
JVM, but persistence of sessions is managed behind the scenes with the
datastore and memcache.

You are, of course, free to use the memcache and/or datastore API's directly
if you want more control. 
/quote

Maarten

On Sun, Apr 12, 2009 at 4:18 PM, Adriano dos Santos Fernandes
adrian...@uol.com.br wrote:
 Maarten Bosteels wrote:

 But AFAIK GAE doesn't use/guarantee sticky sessions, so I am afraid
 you can't rely on local memory.

 App Engine uses multiple web servers to run your application, and
 automatically adjusts the number of servers it is using to handle
 requests reliably. A given request may be routed to any server, and it
 may not be the same server that handled a previous request from the
 same user.

 http://code.google.com/appengine/docs/java/runtime.html#Requests_and_Servlets

 It would be interesting to test the performance of an ISessionStore
 backed by the App Engine datastore.

 FYI, I've put a app. with a static variable counter (just a static, not in
 session). And since two days there, the counter is maintained.

 So I guess they solution uses something like Terracotta. BTW, they web
 server is Jetty.


 Adriano


 -
 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: JOptionpane dialog windows

2009-04-12 Thread Martin Voigt
I'm not sure if I understand this right, are you talking about
javax.swing.JOptionPane? While wicket shares some concepts with swing
and maybe the TreeModel classes, it has nothing to do with swing
except both are loosely based on the same principles, event driven
etc. So no, you cannot use swing components in a wicket application,
except you are talking about embedding an applet or something, which
would be a bad idea from my POV.

But maybe I misunderstood you.

bw,
Martin

2009/4/11 Vladimir Zavada zava...@gmail.com:
 I have a question about using JOptionPane dialogs in my wicket application.
 Is it safe to use them? Is it better to use javascript alert or JOptionPane
 dialog?

 thx for your opinion

 -
 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



Refreshing page / onBeforeRender() issue

2009-04-12 Thread Henrique Boregio
I have a web page with a simple design where a NavigationPanel
contains a few links which replace the main panel with other panels.

My problem is that when I initialize this web page, it creates all of
the panels which will eventually replace a main panel (according to
the link in the NavigationPanel that the user has clicked) by calling
their constructors. Since the constructors initialize a bunch of
components and also retrieve data from a database, it takes a long
time to render the web page since it is also loading all of the other
panels.

Since I want to perform a kind of lazy loading (I only load the
components of the panels if the user has clicked on the corresponding
link in the NavigationPanel), I moved the code where I initialize the
components to the onBeforeRender() method instead of the constructor.
It worked fine for the first time I clicked a link but if I re-clicked
it, a wicket error would pop up since I was trying to add new
components that had already been added.

My solution was something like:

protected void onBeforeRender() {
  super.onBeforeRender();

  if(!firstTime) {
 return;
  }

  // create the components used in this panel
  ...
  firstTime = true
}


This way the components are created only if it is the first time I am
loading the panel.

My question is, is there a better or automatic way of doing this through wicket?
Thanks.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Refreshing page / onBeforeRender() issue

2009-04-12 Thread nick
Thank you for your mail. I am presently on vacation and will return April 14th. 
 

If you need urgent assistance, please email supp...@bookingbooster.com. You can 
also reach our Support via Skype callto://premiersupport

Thank you

Best regards,

Nick Wheeler

Booking Booster.com 
t: +44 (0)1273 573851 
e: integrat...@bookingbooster.com 

a: The Brighton Forum 
95 Ditchling Road 
Brighton BN1 4ST 
East Sussex 
United Kingdom
Booking Booster is the smarter, easier and more elegant way to update agent 
websites. Save time, Boost Bookings with: http://www.bookingbooster.com





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: serialVersionUID

2009-04-12 Thread Brill Pappin

Nice.
I think thats actually more important than we've been giving it credit  
for in this thread!


- Brill Pappin





On 12-Apr-09, at 12:51 AM, Luther Baker wrote:


I don't know much about it ... but would something like Terracotta
use/require/leverage the serialVersionUID for something not so  
obvious in

normal, singly homed deployments?

I think I understand that it helps confirm or explicitly 'version'
components that might be working together or across, say, JVM  
boundaries -
but it seems like, if not explicitly provided, a default value is  
built

automatically and, unless I want an older version to work with a newer
version, I am fine just letting that happen.

In fact, unless I am really abiding by serialVersionUID rules  
(changing it

explicitly - every time I make a relevant, corresponding change to the
containing class) - I'm not really gaining any functionality that the
runtime can't already do. In fact, unless rigorously maintained, it  
seems I
could likely end up with two different compiled versions with  
identical,
explicit serialVersionUIDs - which surely seems worse then leaving  
it alone?


-Luther


On Sat, Apr 11, 2009 at 10:56 PM, Adriano dos Santos Fernandes 
adrian...@uol.com.br wrote:


Brill Pappin wrote:

Actually i don't think a missing one will cause that to fail  
unless there

are a  lot of incompatible changes.

Just one incompatible change of class stored in the session and it  
will not

be deserialized.


However... even if it does matter, *in no way* should anyone  
depend on a
serialized session to store data if your app can't recover  
from a clean

session, you have bigger problems than not adding a serialVersionId.


Hum? What about stateful pages, which is the Wicket market?

If you can control your serial IDs, you have the chance of write  
custom
deserializers. That does not means you can't with an absent ID, but  
AFAIU

just the inclusion of one field and it will change making the
deserialization fail.



Adriano



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






smime.p7s
Description: S/MIME cryptographic signature


Re: serialVersionUID

2009-04-12 Thread Brill Pappin
It wouldn't because its not really meant as an accessible member of  
the class.
It's used at a lower level and would be accessible regardless of the  
scope.


- Brill Pappin





On 12-Apr-09, at 1:46 PM, Ben Tilford wrote:

I've always seen it done as public. Anyways I checked the javadoc  
and the

access modifier does not matter.

On Sun, Apr 12, 2009 at 1:56 AM, Eelco Hillenius
eelco.hillen...@gmail.comwrote:

The purpose of the *public* static final long serialVersionUID is  
for

long

Why do you stress *public*? private is the norm for serialVersionUID.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






smime.p7s
Description: S/MIME cryptographic signature


Re: Refreshing page / onBeforeRender() issue

2009-04-12 Thread Igor Vaynberg
you should only create the panels when the user clicks on the link

add(new link(..) {
 onclick() {
   panel=new somepanel(...);
   ((mypage)getpage()).setcontentpanel(panel);
  }
}

-igor

On Sun, Apr 12, 2009 at 5:56 PM, Henrique Boregio hbore...@gmail.com wrote:
 I have a web page with a simple design where a NavigationPanel
 contains a few links which replace the main panel with other panels.

 My problem is that when I initialize this web page, it creates all of
 the panels which will eventually replace a main panel (according to
 the link in the NavigationPanel that the user has clicked) by calling
 their constructors. Since the constructors initialize a bunch of
 components and also retrieve data from a database, it takes a long
 time to render the web page since it is also loading all of the other
 panels.

 Since I want to perform a kind of lazy loading (I only load the
 components of the panels if the user has clicked on the corresponding
 link in the NavigationPanel), I moved the code where I initialize the
 components to the onBeforeRender() method instead of the constructor.
 It worked fine for the first time I clicked a link but if I re-clicked
 it, a wicket error would pop up since I was trying to add new
 components that had already been added.

 My solution was something like:

 protected void onBeforeRender() {
  super.onBeforeRender();

  if(!firstTime) {
     return;
  }

  // create the components used in this panel
  ...
  firstTime = true
 }


 This way the components are created only if it is the first time I am
 loading the panel.

 My question is, is there a better or automatic way of doing this through 
 wicket?
 Thanks.

 -
 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: Refreshing page / onBeforeRender() issue

2009-04-12 Thread quiqueq


How can I be sure that there is only 1 instance of somepanel? If the user
clicks 10 times the link, 10 different panels would be created in memory.


igor.vaynberg wrote:
 
 you should only create the panels when the user clicks on the link
 
 add(new link(..) {
  onclick() {
panel=new somepanel(...);
((mypage)getpage()).setcontentpanel(panel);
   }
 }
 
 -igor
 

-- 
View this message in context: 
http://www.nabble.com/Refreshing-page---onBeforeRender%28%29-issue-tp23016450p23017567.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



Re: Refreshing page / onBeforeRender() issue

2009-04-12 Thread Igor Vaynberg
not exactly

everytime you click you would do:

{contentpanel.replace(newpanel); contentpanel=newpanel; }

the last line: contentpanel=newpanel; frees up the reference to the
old panel which will be garbage collected

-igor

On Sun, Apr 12, 2009 at 8:55 PM, quiqueq hbore...@gmail.com wrote:


 How can I be sure that there is only 1 instance of somepanel? If the user
 clicks 10 times the link, 10 different panels would be created in memory.


 igor.vaynberg wrote:

 you should only create the panels when the user clicks on the link

 add(new link(..) {
  onclick() {
    panel=new somepanel(...);
    ((mypage)getpage()).setcontentpanel(panel);
   }
 }

 -igor


 --
 View this message in context: 
 http://www.nabble.com/Refreshing-page---onBeforeRender%28%29-issue-tp23016450p23017567.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