Re: Wicket in JBoss cluster

2009-10-23 Thread Jan Grathwohl
Thanks guys, I think I understand now what's going on.

Does anyone know which configuration settings are needed for JBoss 4.2 to
make things work?



2009/10/23 Randy S. randypo...@gmail.com

 Oh I see. Thanks for the explanation.

 I can't comment on JBoss's session replication. I'm familiar with websphere
 with a DB-backed session which does not deserialize until it has to re-load
 from the DB, either because you bounced nodes or had the session expunged
 from memory due to the limit of in-memory sessions.

 On Oct 22, 2009 5:41 PM, Matej Knopp matej.kn...@gmail.com wrote:

 Not quite. On every request when page is changed and the session with
 page is replicated on cluster the receiving nodes should store the
 page to diskpagestore. This way every state of page should be saved.
 But this will only work if the container deserializes sessions
 immediately after replication.

 -Matej

 On Fri, Oct 23, 2009 at 12:00 AM, Randy S. randypo...@gmail.com wrote: 
 Are you saying that beca...

 - To
 unsubscribe, e-mail: users-...



Wicket in JBoss cluster

2009-10-22 Thread Jan Grathwohl
Dear all,

would you be so kind and share your experience about whether it is
reasonable to use Wicket for app development in the following situation:

We are planning to develop an application that will be deployed in our
customer's portlet environment (JBoss Portal). There will be two clustered
JBoss instances with JBoss's own session replication mechanism enabled. The
main reason for the clustering is to have failover that should be
transparent for logged in users, and this has to work really reliably. I
don't know what the exact configuration of the load balancer and the JBoss
servers will be, and how much influence we will have on it.

Is it safe to use wicket in such a situation, or should we rather go for a
more stateless framework?

I did some tests to run a very simple Wicket app in two clustered JBoss
instances, and after I shut down the instance with the active session, the
session continues to be available on the other cluster node, and the links
in the pages still work. So far, so good. But when I hit the browser's back
button, I receive a Page Expired Error. This probably means that the content
of the page store is not correctly replicated to the other cluster node?

Is this a known limitation, or caused by some wrong configuration?

Thanks for any feedback on these topics, please let me know what your
experiences and opinions are.

Kind regards,

Jan


Re: ModalWindow - Address Is Not Valid

2009-09-27 Thread Jan Grathwohl
Hi Alexander,

this one here looks like your problem:

https://issues.apache.org/jira/browse/WICKET-2207

But the issue is marked as fixed in JIRA, since end of April. Do you use the
latest Wicket version?



2009/9/27 Alexander Shindler alexshind...@hotmail.com


 Hi Jeremy,



 Bychance, I found out that it must be some sort of compatibility problem
 with Internet Explorer 8. Even though strangely when I run it from the host
 computer even with IE8 it runs fine, but for some reason other computers on
 the network using IE8 cannot open the modal windows and get the error I
 mentioned below. When I tried using IE7 from the computers on the network,
 everything runs smoothly.



 I can't think of reason why - any suggestions?



 The strangest thing is that I have no problem using IE8 from the host
 computer. I'm guessing it must be some new security feature on IE8...but
 I've no idea what the workaround could be for this apart from using a
 different browser/version...




  Date: Sat, 26 Sep 2009 18:34:44 -0500
  Subject: Re: ModalWindow - Address Is Not Valid
  From: jer...@wickettraining.com
  To: users@wicket.apache.org
 
  Can you show some code?
 
  --
  Jeremy Thomerson
  http://www.wickettraining.com
 
 
 
  On Thu, Sep 24, 2009 at 1:41 AM, Alexander Shindler 
  alexshind...@hotmail.com wrote:
 
  
   Hi,
  
  
  
   I have been using wicket to develop an intranet web application. I have
   tabbedpanels with AjaxLinks which when clicked open up ModalWindows. I
 am
   running tomcat on my computer and my application works fine. When I
 access
   my application from another networked computer, when I click the links,
 the
   modalwindows are not opened and all I get is a message saying that the
   address is not valid (http:///) - can anyone exalin why this happens?
  
  
  
   Alex
  
   _
   Get the best of MSN on your mobile
   http://clk.atdmt.com/UKM/go/147991039/direct/01/
  

 _
 Get the best of MSN on your mobile
 http://clk.atdmt.com/UKM/go/147991039/direct/01/



Re: Datepicker popup when textfield is selected

2009-08-16 Thread Jan Grathwohl

Hi Cem,

I don't know how this can be done with the wicket datepicker, but the  
JQuery datepicker has that already built in, without the need to write  
any additional JavaScript (only one line to init the datepicker and  
attach it to a text field).


Maybe you could just add that one to a normal Wicket TextField,  
instead of using the wicket datepicker?


See here: http://jqueryui.com/demos/datepicker/


Am 14.08.2009 um 12:20 schrieb copenhag copenhagen:


Hi,

Would it be possible to make the datepicker popup whenever a  
textfield is

selected?

Thereby the textfield will be no editable, but only the datepicker  
will

modify the textfield value.

Here is an example on the behaviour i am looking for with the wicket
datepicker object:

http://blog.davglass.com/files/yui/cal2/

Best Regards
Cem...



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



Re: AutoComplete results disappear when using scrollbar in IE

2009-05-26 Thread Jan Grathwohl

Hi Igor,

my specific use case does not allow to limit the number of results,  
but I found another solution that seems to work so far. I modified the  
wicket-autocomplete.js to the following behaviour:


If the browser is IE and not running in Quirks mode, an event handler  
function is added to the document that registers each click, and  
checks which html element was clicked.
The onblur handler of the autocomplete field is modified in a way that  
the result list is not hidden immediately on blur, but with a short  
delay of 200 ms. If the click listener observes a click outside of the  
document body (i.e. tag name of the clicked element is HTML) during  
that delay - which happens when the user clicks the scroll bar - the  
result list will not be hidden, but the input field be re-focused  
instead.


This works for my case, but I don't know if it will be suitable as a  
general fix for others, and I have only tested it with IE 7 and  
Firefox. Should I still provide a patch or quickstart with the  
modification?


Jan



Am 20.05.2009 um 17:57 schrieb Igor Vaynberg:


sounds like we either need to build paging into the list, or you need
to limit the number of results you show.

-igor

On Tue, May 19, 2009 at 2:13 AM, Jan Grathwohl
jan.grathw...@kontrast.de wrote:

Hi list,

I am using Wicket's AutoCompleteTextField in my application, and  
the result
list that is shown to the user by the autocomplete can be quite  
long in some
situations, so that it does not fit into the browser window  
anymore, and the

complete result list is only visible by scrolling down in the browser
window.

The problem with IE is now, if users try to use the browser's  
scrollbar to
get to the end of the result list, the list immediately disappears.  
It looks
like the click on the scrollbar in IE fires an onblur event, which  
hides the
autocomplete's result list. As a result of this, the autocomplete  
can only
be used in IE by scrolling down the page with the mouse's scroll  
wheel, but

IE users without a mouse are in trouble...

Funny thing is that this only happens if I use a HTML doctype  
declaration in
the HTML page. If I remove the declaration from the HTML, IE runs  
in Quirks
mode and does not fire onblur any more when clicking the scroll  
bar, and
everything works. But removing the doctype declaration from my HTML  
then

again breaks all the existing CSS, so this is not really a solution.

Is this a known issue (or an issue at all)? Did anyone on this list  
have the

same problem, and found a way to fix it or work around it?

I know I could make the result list itself scrollable, by setting a  
height

for div.wicket-aa, so users would scroll the div instead of the whole
browser window. But if there is a possibility to keep the current  
behaviour
of the autocomplete, only fix the problem with the click on the  
scrollbar, I

would prefer that.


BTW, the objectautocomplete component from wicket-stuff shows the  
same

problem. Just add

!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html

to the example HTML page, and the autocomplete's result list  
disappears when

you click on the scrollbar.


Regards,

Jan






-
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



AutoComplete results disappear when using scrollbar in IE

2009-05-19 Thread Jan Grathwohl

Hi list,

I am using Wicket's AutoCompleteTextField in my application, and the  
result list that is shown to the user by the autocomplete can be quite  
long in some situations, so that it does not fit into the browser  
window anymore, and the complete result list is only visible by  
scrolling down in the browser window.


The problem with IE is now, if users try to use the browser's  
scrollbar to get to the end of the result list, the list immediately  
disappears. It looks like the click on the scrollbar in IE fires an  
onblur event, which hides the autocomplete's result list. As a result  
of this, the autocomplete can only be used in IE by scrolling down the  
page with the mouse's scroll wheel, but IE users without a mouse are  
in trouble...


Funny thing is that this only happens if I use a HTML doctype  
declaration in the HTML page. If I remove the declaration from the  
HTML, IE runs in Quirks mode and does not fire onblur any more when  
clicking the scroll bar, and everything works. But removing the  
doctype declaration from my HTML then again breaks all the existing  
CSS, so this is not really a solution.


Is this a known issue (or an issue at all)? Did anyone on this list  
have the same problem, and found a way to fix it or work around it?


I know I could make the result list itself scrollable, by setting a  
height for div.wicket-aa, so users would scroll the div instead of the  
whole browser window. But if there is a possibility to keep the  
current behaviour of the autocomplete, only fix the problem with the  
click on the scrollbar, I would prefer that.



BTW, the objectautocomplete component from wicket-stuff shows the same  
problem. Just add


!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html

to the example HTML page, and the autocomplete's result list  
disappears when you click on the scrollbar.



Regards,

Jan





Sending HTML email from Wicket app

2008-06-06 Thread Jan Grathwohl

Hi,

what is the preferred way to send HTML email messages from a Wicket  
application? I could not find anything related to sending email in  
the Javadocs, and no examples on the web.


My idea was to create a Wicket page for the content of the email,  
render this page into a String, and then send the email with the  
Jakarta Commons mail client. But I could not figure out how to do  
that either. Is this possible, to instantiate a new WebPage object,  
set the necessary fields, and then render it into a String variable  
instead of writing it to the HTTP response? If yes, could somebody  
tell me what I have to do?


BR and Thanks,

Jan



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]