Re: testing borders with WicketTester

2008-11-02 Thread Daniel Lipski

No, I think you misunderstood me, when I wrote about empty body I was
thinking about testing, I know that border without its body works like panel
and shouldnt be used in such case. 
I was writing about borders which have bodies, but during testing I was
interested in testing such borders with some 'stub' (ie empty) body.


jwcarman wrote:
> 
> Are you sure you don't want to use markup inheritance rather than borders?
> 
> On Sun, Nov 2, 2008 at 5:57 AM, Daniel Lipski
> <[EMAIL PROTECTED]> wrote:
>>
>> Sorry, but I dont get your point...
>> What do you mean self contained (in terms of Wicket API) ?
>>
>> Im sure there is a lot of user created border components which contain a
>> lot
>> of surrounding markup and components and it is very desireble(at least
>> for
>> me :)) to be able to 'unit' test such components with Wicket tester,
>> regardles (i.e with empty) to border body.
>> Does method Im looking for was not provided because of technical problems
>> ?
>> If so what is the simplest way to test border components (surrounding
>> markup
>> and components) with i.e empty body ?
>>
>> Regards
>> Daniel Lipski
>>
>>
>> igor.vaynberg wrote:
>>>
>>> borders are not meant to be self-contained like panels. they are meant
>>> to be used within something that contains markup, eg page or panel.
>>>
>>> -igor
>>>
>>> On Fri, Oct 31, 2008 at 8:14 AM, dlipski <[EMAIL PROTECTED]>
>>> wrote:

 Hi

 Is it possible (if not why?) to test Border components in a way similar
 to
 testing Panels ?  -WicketTester.startPanel(TestPanelSource) ? Its
 strange
 but I cant find corresponding method for Borders.

 Thanks in advance.

 Daniel Lipski
 --
 View this message in context:
 http://www.nabble.com/testing-borders-with-WicketTester-tp20268028p20268028.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/testing-borders-with-WicketTester-tp20268028p20288374.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/testing-borders-with-WicketTester-tp20268028p20298317.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]



Re: Broken pipe

2008-11-02 Thread Erik van Oosten

I have:

$ java -version
java version "1.6.0_10-rc"
Java(TM) SE Runtime Environment (build 1.6.0_10-rc-b28)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode)

$ uname -a
Linux server #1 SMP Wed May 28 20:21:05 UTC 2008 x86_64 GNU/Linux

Regards,
   Erik.


Martin Makundi wrote:

What is your exact version, mine is:

java version "1.6.0_10-beta"
Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b25)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b12, mixed mode)

Linux version 2.6.18-xenU (gcc version 4.1.2 20061115 (prerelease)
(Debian 4.1.1-21))

**
Martin


2008/11/3 Erik van Oosten <[EMAIL PROTECTED]>:
  

My latest application also runs on 64bit (Ubuntu 8.04). The JVM crashed
regularly (in the compiler) until I upgraded to Java 6u10.

Regards,
  Erik.



Martin Makundi wrote:


Hi!

I quite often suffer this exception.. anybody have similar experiences
and know of a workaround? It crashes the jvm..

2008-11-02 18:48:02,819 4[btpool0-4] ERROR TakpServlet  - Faltal
error, servlet service halted.
org.mortbay.jetty.EofException
  at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:657)
  at
org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:539)
  at
org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:560)
  at
org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:828)
  at
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:617)
  at
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:578)
  at
org.apache.wicket.protocol.http.BufferedHttpServletResponse.writeTo(BufferedHttpServletResponse.java:552)
  at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:341)
  at
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
  at wicket.quickstart.TakpServlet.service(TakpServlet.java:58)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
  at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
  at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
  at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
  at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
  at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
  at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
  at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
  at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
  at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
  at org.mortbay.jetty.Server.handle(Server.java:285)
  at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
  at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
  at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
  at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
  at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
  at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.io.IOException: Broken pipe
  at sun.nio.ch.FileDispatcher.write0(Native Method)
  at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
  at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
  at sun.nio.ch.IOUtil.write(IOUtil.java:60)
  at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
  at
org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:165)
  at
org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:192)
  at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:590)
  ... 28 more

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2b2290b73360, pid=22478, tid=1082333536
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b12 mixed mode
linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x4d3360]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x2aaabe6da800):  JavaThread "CompilerThread1" daemon
[_thre
ad_in_native, id=22489, stack(0x40731000,0x40832000)]

Current CompileTask:
C2:1729
 org.apache.wicket.extensions.yui.calendar.DatePicker.renderHead(Lor
g/apache/wicket/markup/html/IHeaderResponse;)V (706 bytes)

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR),
si_addr

Re: Broken pipe

2008-11-02 Thread Martin Makundi
What is your exact version, mine is:

java version "1.6.0_10-beta"
Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b25)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b12, mixed mode)

Linux version 2.6.18-xenU (gcc version 4.1.2 20061115 (prerelease)
(Debian 4.1.1-21))

**
Martin


2008/11/3 Erik van Oosten <[EMAIL PROTECTED]>:
> My latest application also runs on 64bit (Ubuntu 8.04). The JVM crashed
> regularly (in the compiler) until I upgraded to Java 6u10.
>
> Regards,
>   Erik.
>
>
>
> Martin Makundi wrote:
>>
>> Hi!
>>
>> I quite often suffer this exception.. anybody have similar experiences
>> and know of a workaround? It crashes the jvm..
>>
>> 2008-11-02 18:48:02,819 4[btpool0-4] ERROR TakpServlet  - Faltal
>> error, servlet service halted.
>> org.mortbay.jetty.EofException
>>   at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:657)
>>   at
>> org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:539)
>>   at
>> org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:560)
>>   at
>> org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:828)
>>   at
>> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:617)
>>   at
>> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:578)
>>   at
>> org.apache.wicket.protocol.http.BufferedHttpServletResponse.writeTo(BufferedHttpServletResponse.java:552)
>>   at
>> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:341)
>>   at
>> org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124)
>>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>>   at wicket.quickstart.TakpServlet.service(TakpServlet.java:58)
>>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>>   at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
>>   at
>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
>>   at
>> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
>>   at
>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
>>   at
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
>>   at
>> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
>>   at
>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
>>   at
>> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>>   at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
>>   at org.mortbay.jetty.Server.handle(Server.java:285)
>>   at
>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
>>   at
>> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
>>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
>>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
>>   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
>>   at
>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
>>   at
>> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
>> Caused by: java.io.IOException: Broken pipe
>>   at sun.nio.ch.FileDispatcher.write0(Native Method)
>>   at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
>>   at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
>>   at sun.nio.ch.IOUtil.write(IOUtil.java:60)
>>   at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
>>   at
>> org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:165)
>>   at
>> org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:192)
>>   at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:590)
>>   ... 28 more
>>
>> #
>> # An unexpected error has been detected by Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x2b2290b73360, pid=22478, tid=1082333536
>> #
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b12 mixed mode
>> linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x4d3360]
>> #
>> # If you would like to submit a bug report, please visit:
>> #   http://java.sun.com/webapps/bugreport/crash.jsp
>> # The crash happened outside the Java Virtual Machine in native code.
>> # See problematic frame for where to report the bug.
>> #
>>
>> ---  T H R E A D  ---
>>
>> Current thread (0x2aaabe6da800):  JavaThread "CompilerThread1" daemon
>> [_thre
>> ad_in_native, id=22489, stack(0x40731000,0x40832000)]
>>
>> Current CompileTask:
>> C2:1729
>>  org.apache.wicket.extensions.yui.calendar.DatePicker.renderHead(Lor
>> g/apache/wicket/markup/html/IHeaderResponse;)V (706 bytes)
>>
>> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR),
>> s

Re: Broken pipe

2008-11-02 Thread Erik van Oosten
My latest application also runs on 64bit (Ubuntu 8.04). The JVM crashed 
regularly (in the compiler) until I upgraded to Java 6u10.


Regards,
   Erik.



Martin Makundi wrote:

Hi!

I quite often suffer this exception.. anybody have similar experiences
and know of a workaround? It crashes the jvm..

2008-11-02 18:48:02,819 4[btpool0-4] ERROR TakpServlet  - Faltal
error, servlet service halted.
org.mortbay.jetty.EofException
   at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:657)
   at 
org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:539)
   at 
org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:560)
   at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:828)
   at 
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:617)
   at 
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:578)
   at 
org.apache.wicket.protocol.http.BufferedHttpServletResponse.writeTo(BufferedHttpServletResponse.java:552)
   at 
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:341)
   at 
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
   at wicket.quickstart.TakpServlet.service(TakpServlet.java:58)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
   at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
   at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
   at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
   at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
   at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
   at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
   at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
   at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
   at org.mortbay.jetty.Server.handle(Server.java:285)
   at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
   at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
   at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
   at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.io.IOException: Broken pipe
   at sun.nio.ch.FileDispatcher.write0(Native Method)
   at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
   at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
   at sun.nio.ch.IOUtil.write(IOUtil.java:60)
   at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
   at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:165)
   at 
org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:192)
   at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:590)
   ... 28 more

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2b2290b73360, pid=22478, tid=1082333536
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b12 mixed mode linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x4d3360]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x2aaabe6da800):  JavaThread "CompilerThread1" daemon [_thre
ad_in_native, id=22489, stack(0x40731000,0x40832000)]

Current CompileTask:
C2:1729  org.apache.wicket.extensions.yui.calendar.DatePicker.renderHead(Lor
g/apache/wicket/markup/html/IHeaderResponse;)V (706 bytes)

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x000
0002c
Registers:
RAX=0x2aaac6a2d7b8, RBX=0x066b, RCX=0x2aaac4e65370, RDX=0x00
08
RSP=0x4082dca8, RBP=0x4082def0, RSI=0x2aaac7500020, RDI=0x00
00
R8 =0x3053, R9 =0x2aaac6a2d7e8, R10=0x2aaac6c74e20, R11=0x00
002aaac74a5700
R12=0x4082eb78, R13=0x008d, R14=0x, R15=0x00
002aaac71992c0
RIP=0x2b2290b73360, EFL=0x00010202, CSGSFS=0xe033, ERR=0
x0004
  TRAPNO=0x000e

Top of Stack: (sp=0x40

Re: Moving from Tapestry to Wicket?

2008-11-02 Thread Jeremy Thomerson
I can vouch for the fact that Wicket's learning curve, compared to
Tapestry's, is MUCH, MUCH easier for an object-oriented Java programmer.  We
used Tapestry at my last place of employment, and I hated it.  When I left,
I chose Wicket, and for the past several years have been enjoying UI
development for the first time in my web app career.

You can get up and running in Wicket very quickly, and can really generate
some apps quickly.  The biggest thing is to make sure you have a solid
understanding of how to effectively use models before you begin a project -
or you'll kick yourself later.

I'm sure you'll enjoy your Wicket development experience - and the list is
very active and friendly - let us know if you need any help along the way.

-- 
Jeremy Thomerson
http://www.wickettraining.com

On Sun, Nov 2, 2008 at 10:23 AM, GK1971 <[EMAIL PROTECTED]> wrote:

>
> Hi Eelco,
>
> You are correct - right now my main worry is about development cost.
> Hardware cost is cheaper IMHO than having developers struggle with a hard
> framework and spending too much time trying to maintain and write code
> based
> around a hard framework.
>
> Honestly in our application (we have a roadmap for scalability) we are
> likely to get several hundred concurrent sessions per server with a few kb
> of state stored in the HTTPSession. Its not that much. What I was more
> concerned about was Page storage and storage that I can't control (for
> example, if I couldn't control IModel storage I would be concerned).
>
> We are unlikely to have spikes of traffic, but we are more likely to have
> dribs and drabs of users who potentially keep sessions open for perhaps
> minutes to hours.
>
> For our initial scaling the client will have an affinity to a specific
> server. We can control the number of users that we have on a server. We can
> then scale our servers horizontally if we hit a scaling issue on one of the
> servers. I'm starting not to worry about it too much.
>
> Honestly - I really face the same issues with Tapestry. What I don't face
> with Wicket is the development cost because it appears to be (I played with
> it yesterday) a very intelligent architecture. I was happy playing
> yesterday
> and even migrated our login page over very quickly. Of course I have to
> figure out how to handle my 'remember me' cookie and hit the database, but
> it all seems rather nice.
>
> Cheers, Graeme.
>
>
> Eelco Hillenius wrote:
> >
> >>> I have a complex table and many links on the page that are not
> >>> book-markable. Will that be a problem in terms of too much session
> >>> information?
> >
> > The default session store in Wicket saves history in some temp files
> > and only holds the current page in memory (well, the current page of
> > any page map in case you use more). Say that's a very heavy page,
> > taking up to 100K. And say you run a VM with 1 GB of dedicated memory.
> > You can support close to 10,000 concurrent sessions (close, because
> > obviously, you'll use memory for other things than just sessions).
> > Changes are that you run into bottlenecks with processors and database
> > utilization long before you run out of memory for one box.
> >
> > The only kind of web sites I probably wouldn't recommend Wicket as
> > used by default for are sites like Google, Yahoo and CNN etc, where
> > you can have enormous spikes in traffic that are very short lived.
> > But... the good news with Wicket then again is that you can build your
> > app entirely using bookmarkable pages (even stateless if you want, so
> > that you can avoid *any* memory usage) so that clustering will be easy
> > and cheap. On top of that, you can plug in your own implementations of
> > things like session store so that you can decide when/ how/ where
> > state should be kept.
> >
> > You have to weigh the benefits of the stateful programming model
> > against your technical requirements. But you can use Wicket for most
> > use cases if you give it a bit of thought.
> >
> >>> Would it be conceptually easy for me to write Javascript/AJAX and hook
> >>> them into Wicket in a simple way?
> >
> > Yeah, that's fairly simple. You can either write snippets that are
> > used by components/ behaviors that integrate with our regular AJAX
> > engine, or you can even plugin your own engine if you'd prefer that.
> >
> >>> Its all about cost.
> >
> > The funny thing is that in most discussions out there people focus on
> > the cost of servers/ memory/ etc. While probably for most people -
> > basically for anything that doesn't have the size of Google -
> > development and maintenance cost is often the highest component. So a
> > good development model makes sense.
> >
> >>> we have absolute faith that it will have a lot of users according to
> our
> >>> business plan.
> >
> > May I ask what you think is a lot (say hits per second and concurrent
> > sessions)? Thousands? Tens of thousands? Hundred of thousands? Even
> > millions? If you're talking about really large numbers, you n

Re: Should/Could ServletWebRequest.isAjax be cached?

2008-11-02 Thread Martin Makundi
>> So, some streamlining might be in order there, even after this particular 
>> issue.
>
> Do you have a lot of Ajax updates of small components without
> their own markup?
>  https://issues.apache.org/jira/browse/WICKET-1857
> might be hitting you as well and it would be interesting to
> see if your problem still occurs on trunk (or 1.4-RC1).

Not really, I have large chunks (containers.. actually a ListView...).

I had a look at the debug output and there is one
"DEBUG - MarkupCache- Markup not found:
org.apache.wicket.markup.html.form.Formfi_FIhtml"

and some
"DEBUG - ResourceStreamLocator  - Attempting to locate resource
'org/apache/wicket/markup/html/form/Form_fi_FI.html' on"
or similar

Most of the lines in the debug log consist of:
"DEBUG - MarkupContainer- Rendering raw markup"
and
"DEBUG - Component  - Begin render [MarkupContainer
[Component id =xx"

> The actual parsing results should be cached by IMarkupCache
> as far as I know, so if the parsing is really the issue you
> could try finding out why is the cache not working (and/or
> provide a reproduceable test case in a quickstart).

Can you be more specific about this? In what context should the
parsing results be cached?

You could try ajax-updating a large web page, say having a table with
2000+ rows, and profile it. Do the results look ok for you?

I will have a look, but I am not yet very familiar with Wicket
internals... the 'what should be''s and nots

**
Martin

>
> --
> Timo Rantalaiho
> Reaktor Innovations Oyhttp://www.ri.fi/ >
>
> -
> 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: Should/Could ServletWebRequest.isAjax be cached?

2008-11-02 Thread Timo Rantalaiho
On Sun, 02 Nov 2008, Martin Makundi wrote:
> The profiler shows that for a (large) page, 40% of the effort (20
> seconds per such particular page) goes into just parsing the tags and
> does not seem to process any logic.
> 
> So, some streamlining might be in order there, even after this particular 
> issue.

Do you have a lot of Ajax updates of small components without
their own markup?

If that is the case, then this issue

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

might be hitting you as well and it would be interesting to 
see if your problem still occurs on trunk (or 1.4-RC1).

The actual parsing results should be cached by IMarkupCache 
as far as I know, so if the parsing is really the issue you 
could try finding out why is the cache not working (and/or 
provide a reproduceable test case in a quickstart).

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations Oyhttp://www.ri.fi/ >

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



Re: Testing + IFrame

2008-11-02 Thread Timo Rantalaiho
On Fri, 31 Oct 2008, Bert van Heukelom wrote:
> I want to test an ajax upload component that uses an IFrame. I have
> difficulties when trying to access Components via their path that are
> contained in the IFrame. I manage to a reference of the Iframe but can not
> find a path-string that accesses a component (namly a form) within the
> Iframe.

Try doing wicketTester.debugComponentTrees() (or debugging 
the exact hierarchy by yourself).

> FormTester f =
> wicketTester.newFormTester("path:to:my:iframe:and:to:its:inner:form");

Long component paths like this are a bit problematic anyway.
You could try digging your Form up with a visitor to make it
less dependent on the path.

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations Oyhttp://www.ri.fi/ >

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



Re: Session destruction due to timeout...

2008-11-02 Thread schapes


Mendeleev wrote:
> 
> I passed the application key and it worked. Thanks a lot for the help. 
> 
> Would you be able to post your solution.  I am trying to solve the
> same problem.  Right now I am using the solution posted on this thread by
> Nino.  Do you have an alternate way of solving this problem without having
> to worry about issues when clustering?
> 
> 
> 
> 
> Johan Compagner wrote:
>> 
>> no you cant and Application.get() will never work then because the auto
>> destruct of a container
>> doesnt do that in a request ofcourse but just somewhere on some thread.
>> 
>> if you need an application object you could try:
>> 
>> Application.get(String applicationKey)
>> 
>> The session object is gone so you cant access it anymore.
>> 
>> On Wed, Oct 15, 2008 at 10:40 AM, Mendeleev <[EMAIL PROTECTED]> wrote:
>> 
>>>
>>> I need to add functionality to my Wicket application that allows me to
>>> record
>>> in the MySQL database the exact time a user logs out of the application.
>>> This includes recording the time the session is destroyed by the web
>>> container due to user inactivity.
>>>
>>> I tried:
>>> 1. An implementation of HttpSessionListener
>>> 2. Extending the HttpSessionStore class
>>> 3. WebApplication.sessionDestroyed(String sessionid)
>>> 4. An implementation of HttpSessionBindingListener
>>>
>>> All of these do not work in my case, because the methods are called
>>> AFTER
>>> the session is already destroyed. At that time, the hibernate session
>>> that
>>> connects to the database, does not exist anymore. I cannot reopen it,
>>> because the Application.get() method returns null at this time.
>>>
>>> My question is: is there any way that I can record the destruction right
>>> before it happens? Is there some sort of a listener I can implement?
>>>
>>> If not, how is the wicket application notified that the user navigates
>>> away
>>> from the page, starting a period of inactivity? If there is a way I can
>>> register that happening, I can solve the problem by adding a timer.
>>>
>>> Thanks,
>>> Drago
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Session-destruction-due-to-timeout...-tp19989230p19989230.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]
>>>
>>>
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Session-destruction-due-to-timeout...-tp19989230p20296278.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]



Re: JavaScript Framework Dependencies / Wicket Stuff commit access

2008-11-02 Thread Igor Vaynberg
you have svn. nino can set you up with the rest soon.

-igor

On Sun, Nov 2, 2008 at 1:33 PM, Uwe Schäfer <[EMAIL PROTECTED]> wrote:
> Igor Vaynberg schrieb:
>
>>> i´m just wondering why there isn´t a project like
>>> org.wicketstuff.javascript.mootools/jquery/extjs/whatever
>>
>> why? because you havent built it yet. wicketstuff is open for
>> participation, feel free.
>
> the answer i was hoping for ;)
>
> i´d like to ask for permission to commit org.wicketstuff.js.mootools project
> then and maybe some simple behaviours using it afterwards.
>
> sourceforge/teamcity/jira acount: "uweschaefer"
>
> cu uwe
>
> -
> 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]



Broken pipe

2008-11-02 Thread Martin Makundi
Hi!

I quite often suffer this exception.. anybody have similar experiences
and know of a workaround? It crashes the jvm..

2008-11-02 18:48:02,819 4[btpool0-4] ERROR TakpServlet  - Faltal
error, servlet service halted.
org.mortbay.jetty.EofException
   at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:657)
   at 
org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:539)
   at 
org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:560)
   at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:828)
   at 
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:617)
   at 
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:578)
   at 
org.apache.wicket.protocol.http.BufferedHttpServletResponse.writeTo(BufferedHttpServletResponse.java:552)
   at 
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:341)
   at 
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
   at wicket.quickstart.TakpServlet.service(TakpServlet.java:58)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
   at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
   at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
   at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
   at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
   at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
   at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
   at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
   at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
   at org.mortbay.jetty.Server.handle(Server.java:285)
   at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
   at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
   at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
   at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.io.IOException: Broken pipe
   at sun.nio.ch.FileDispatcher.write0(Native Method)
   at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
   at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
   at sun.nio.ch.IOUtil.write(IOUtil.java:60)
   at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
   at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:165)
   at 
org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:192)
   at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:590)
   ... 28 more

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2b2290b73360, pid=22478, tid=1082333536
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b12 mixed mode linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x4d3360]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x2aaabe6da800):  JavaThread "CompilerThread1" daemon [_thre
ad_in_native, id=22489, stack(0x40731000,0x40832000)]

Current CompileTask:
C2:1729  org.apache.wicket.extensions.yui.calendar.DatePicker.renderHead(Lor
g/apache/wicket/markup/html/IHeaderResponse;)V (706 bytes)

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x000
0002c
Registers:
RAX=0x2aaac6a2d7b8, RBX=0x066b, RCX=0x2aaac4e65370, RDX=0x00
08
RSP=0x4082dca8, RBP=0x4082def0, RSI=0x2aaac7500020, RDI=0x00
00
R8 =0x3053, R9 =0x2aaac6a2d7e8, R10=0x2aaac6c74e20, R11=0x00
002aaac74a5700
R12=0x4082eb78, R13=0x008d, R14=0x, R15=0x00
002aaac71992c0
RIP=0x2b2290b73360, EFL=0x00010202, CSGSFS=0xe033, ERR=0
x0004
  TRAPNO=0x000e

Top of Stack: (sp=0x4082dca8)
0x4082dca8:   2b2290bdac88 2aaa0001
0x4082dcb8:   2aaac62dff00 4082de60
0x4082dcc8:   0080 4082dde0
0x

Re: JavaScript Framework Dependencies

2008-11-02 Thread Uwe Schäfer

francisco treacy schrieb:


afaik there are several projects in wicketstuff. at least for
scriptaculous, jquery and mootools. no idea how good/extense these
implementations are though.


i saw the contrib-mootools stuff which is pretty great, i´m sure. but it 
contains a bunch of wrapping code for integrating mootools with wicket.


while this is all great, it looks like some kind of work to keep up with 
the mootools lib. this may be the reason for this project still being 
built against 1.1.


don´t get me wrong, i really dont want any effort to be doubled and so 
increase confusion, but what i´d like to do is nothing more than a 
facility to coordinate script inclusion for otherwise totally 
unconnected projects. very near to what sven did on wicketstuff-prototype.


cu uwe

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



Re: JavaScript Framework Dependencies

2008-11-02 Thread francisco treacy
afaik there are several projects in wicketstuff. at least for
scriptaculous, jquery and mootools. no idea how good/extense these
implementations are though.

there is also wickext (code.google.com/p/wickext/ ) for jquery.

francisco

On Sun, Nov 2, 2008 at 8:51 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 2, 2008 at 7:08 AM, Uwe Schäfer <[EMAIL PROTECTED]> wrote:
>> i´m just wondering why there isn´t a project like
>> org.wicketstuff.javascript.mootools/jquery/extjs/whatever
>
> why? because you havent built it yet. wicketstuff is open for
> participation, feel free.
>
> -igor
>
> -
> 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: JavaScript Framework Dependencies

2008-11-02 Thread Uwe Schäfer

Sven Meier schrieb:


this is exactly the reason why we have wicketstuff-prototype:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-prototype


good to hear that. i´ll look into it

thx uwe

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



Re: JavaScript Framework Dependencies / Wicket Stuff commit access

2008-11-02 Thread Uwe Schäfer

Igor Vaynberg schrieb:


i´m just wondering why there isn´t a project like
org.wicketstuff.javascript.mootools/jquery/extjs/whatever

why? because you havent built it yet. wicketstuff is open for
participation, feel free.


the answer i was hoping for ;)

i´d like to ask for permission to commit org.wicketstuff.js.mootools 
project then and maybe some simple behaviours using it afterwards.


sourceforge/teamcity/jira acount: "uweschaefer"

cu uwe

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



Re: example application for spring wicket hibernate

2008-11-02 Thread Sébastien Piller

you may look at wicket iolite too, it's very usefull

miro wrote:

are there any  examples for spring, wicket and hibernate ?
  



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



Re: example application for spring wicket hibernate

2008-11-02 Thread Tomasz Dziurko
Phonebook:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-phonebook .

If you need NetBeans project for it just tell me, I have it somewhere
on the disc

Regards
-- 
Tomasz Dziurko

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



Re: JavaScript Framework Dependencies

2008-11-02 Thread Igor Vaynberg
On Sun, Nov 2, 2008 at 7:08 AM, Uwe Schäfer <[EMAIL PROTECTED]> wrote:
> i´m just wondering why there isn´t a project like
> org.wicketstuff.javascript.mootools/jquery/extjs/whatever

why? because you havent built it yet. wicketstuff is open for
participation, feel free.

-igor

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



example application for spring wicket hibernate

2008-11-02 Thread miro

are there any  examples for spring, wicket and hibernate ?
-- 
View this message in context: 
http://www.nabble.com/example-application-for-spring-wicket-hibernate-tp20293119p20293119.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]



Re: Are there any open-source webapplications based on Wicket?

2008-11-02 Thread Erik van Oosten

http://cwiki.apache.org/WICKET/sites-using-wicket.html



So far I have not found a single Wicket-based "website" or project.

Is there none so far or just hidden somewhere on the net ?




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



Re: testing borders with WicketTester

2008-11-02 Thread Igor Vaynberg
self contained in that the page and panel has everything they need to
render themselves. a border is meant to be embedded in a page or
panel, not work independently. anyways, its really easy to create a
generic panel to facilitate the testing of borders.

-igor

On Sun, Nov 2, 2008 at 2:57 AM, Daniel Lipski
<[EMAIL PROTECTED]> wrote:
>
> Sorry, but I dont get your point...
> What do you mean self contained (in terms of Wicket API) ?
>
> Im sure there is a lot of user created border components which contain a lot
> of surrounding markup and components and it is very desireble(at least for
> me :)) to be able to 'unit' test such components with Wicket tester,
> regardles (i.e with empty) to border body.
> Does method Im looking for was not provided because of technical problems ?
> If so what is the simplest way to test border components (surrounding markup
> and components) with i.e empty body ?
>
> Regards
> Daniel Lipski
>
>
> igor.vaynberg wrote:
>>
>> borders are not meant to be self-contained like panels. they are meant
>> to be used within something that contains markup, eg page or panel.
>>
>> -igor
>>
>> On Fri, Oct 31, 2008 at 8:14 AM, dlipski <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Hi
>>>
>>> Is it possible (if not why?) to test Border components in a way similar
>>> to
>>> testing Panels ?  -WicketTester.startPanel(TestPanelSource) ? Its strange
>>> but I cant find corresponding method for Borders.
>>>
>>> Thanks in advance.
>>>
>>> Daniel Lipski
>>> --
>>> View this message in context:
>>> http://www.nabble.com/testing-borders-with-WicketTester-tp20268028p20268028.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/testing-borders-with-WicketTester-tp20268028p20288374.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: JavaScript Framework Dependencies

2008-11-02 Thread Sven Meier

Hi Uwe,

this is exactly the reason why we have wicketstuff-prototype:

   
http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-prototype


IMHO we could use something similar for mootools.

Sven

Uwe Schäfer schrieb:

hi

forgive me, if this topic is a dead horse already, but it really bugs 
me that this does not seem to be sorted out.
i´m just wondering why there isn´t a project like 
org.wicketstuff.javascript.mootools/jquery/extjs/whatever


the story: i was just implementing some mini behaviour using mootools 
when i found, that after packaging it nicely in a seperate project, it 
broke another mootools based behaviour used on a page that combined 
the two.
no suprise there, as they use different versions of mootools. the 
obvious solution is: ripping the dependency out in a seperate project 
and make both use this one. (assuming backward compatibility is reliable)


so, what do i learn from that? there should be *one single* source for 
mootools-header-contributions that any behaviour implementor is 
invited to use in order to prevent scripts form being loaded more than 
once on a single page (due to coming from different resources) and to 
give the user (or his maven or whatever he uses for dependency 
resolution) of these behaviours a chance of choosing the version.


yes, i know... maintaining could be work, but it is bearable to at 
least have all major versions of the bigger JS toolkits bundled 
together with a simple class defining resources to use those things.


to make it crystal clear: this is just about providing a single access 
point for using these scripts, not wrapping them with wicket components.


bad idea?

cu uwe

-
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: Are there any open-source webapplications based on Wicket?

2008-11-02 Thread Martijn Dashorst
hippo, ehour, jtrac, artifactory, sakai to name a few.

Martijn

On Sun, Nov 2, 2008 at 8:51 AM, Toby78 <[EMAIL PROTECTED]> wrote:
>
> In PHP, many open-source applications exist, such as Drupal, PHPBB...and
> thousands of other scripts.
> So far I have not found a single Wicket-based "website" or project.
>
> Is there none so far or just hidden somewhere on the net ?
> --
> View this message in context: 
> http://www.nabble.com/Are-there-any-open-source-webapplications-based-on-Wicket--tp20290455p20290455.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]
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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



Re: Refresh parent page from an iframe

2008-11-02 Thread Bert van Heukelom
There is an example Implementation of a file upload, that is contained in an
iFrame (
http://www.demay-fr.net/blog/index.php/2007/12/07/93-simulate-ajax-file-upload-with-wicket).
The Author wanted pretty much the same as you do: Alter the containing
(parent) page. He uses a javascript call to the parent page. I'm not really
sure if I can get all necessary steps together but here are some hints:

1) Add an AbstractDefaultAjaxBehavior to your parent page. Alter the
"getCallback" method in a way that it makes a call to wicketAjaxGet and
appends parameters to the query string to identify which iframe triggered
the action. Take the query parameters from the current javascript scope.

2) Generate a method into the parent page that executes the getCallback
script of the behavior and takes the parameters needed as function
parameters.

3) append javascript to the submit button/whatever of the iframe that calls
the javascript method in the parent page and pass the parameters that
identify the calling iframe (maybe markup id?).

4) put java code that modifies your parent page into the
AbstractDefaultAjaxBehavior's onResponse method and alter the page.

That is the idea. Hope you can follow me. I'd advise you to take a closer
look at the example by Monsieur Demay. Even though it contains some errors.
There is a corrected version somewhere on the web.

I'd say that there is no direct way using only java to solve your problem.
But I've started using wicket 6 weeks ago so there might be a more clever
answer :)

Cheers

Bert


2008/11/2 itayh <[EMAIL PROTECTED]>

>
> Hi,
>
> I have a page that contains several iframes with some actions in each
> iframe. When I press on some of the actions I want the parent page to be
> updated (since the actions affect the whole parent page with the iframes).
> But every attempt to update the page is actually updating the iframe only.
> What actually happen is that the whole page get render again inside the
> iframe. I use setResponsePage(parent) within the iframe. Thats probably the
> problem but I don't know what else to use.
> I try to do as it written
> here:http://www.nabble.com/modal-window-navigation--td18551902.html but it
> does not work.
>
> Any idea's?
>
> Thanks in advance,
>  Itay
>
> --
> View this message in context:
> http://www.nabble.com/Refresh-parent-page-from-an-iframe-tp20290367p20290367.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]
>
>


Re: Moving from Tapestry to Wicket?

2008-11-02 Thread GK1971

Hi Eelco,

You are correct - right now my main worry is about development cost.
Hardware cost is cheaper IMHO than having developers struggle with a hard
framework and spending too much time trying to maintain and write code based
around a hard framework. 

Honestly in our application (we have a roadmap for scalability) we are
likely to get several hundred concurrent sessions per server with a few kb
of state stored in the HTTPSession. Its not that much. What I was more
concerned about was Page storage and storage that I can't control (for
example, if I couldn't control IModel storage I would be concerned). 

We are unlikely to have spikes of traffic, but we are more likely to have
dribs and drabs of users who potentially keep sessions open for perhaps
minutes to hours.

For our initial scaling the client will have an affinity to a specific
server. We can control the number of users that we have on a server. We can
then scale our servers horizontally if we hit a scaling issue on one of the
servers. I'm starting not to worry about it too much.

Honestly - I really face the same issues with Tapestry. What I don't face
with Wicket is the development cost because it appears to be (I played with
it yesterday) a very intelligent architecture. I was happy playing yesterday
and even migrated our login page over very quickly. Of course I have to
figure out how to handle my 'remember me' cookie and hit the database, but
it all seems rather nice.

Cheers, Graeme.


Eelco Hillenius wrote:
> 
>>> I have a complex table and many links on the page that are not
>>> book-markable. Will that be a problem in terms of too much session
>>> information?
> 
> The default session store in Wicket saves history in some temp files
> and only holds the current page in memory (well, the current page of
> any page map in case you use more). Say that's a very heavy page,
> taking up to 100K. And say you run a VM with 1 GB of dedicated memory.
> You can support close to 10,000 concurrent sessions (close, because
> obviously, you'll use memory for other things than just sessions).
> Changes are that you run into bottlenecks with processors and database
> utilization long before you run out of memory for one box.
> 
> The only kind of web sites I probably wouldn't recommend Wicket as
> used by default for are sites like Google, Yahoo and CNN etc, where
> you can have enormous spikes in traffic that are very short lived.
> But... the good news with Wicket then again is that you can build your
> app entirely using bookmarkable pages (even stateless if you want, so
> that you can avoid *any* memory usage) so that clustering will be easy
> and cheap. On top of that, you can plug in your own implementations of
> things like session store so that you can decide when/ how/ where
> state should be kept.
> 
> You have to weigh the benefits of the stateful programming model
> against your technical requirements. But you can use Wicket for most
> use cases if you give it a bit of thought.
> 
>>> Would it be conceptually easy for me to write Javascript/AJAX and hook
>>> them into Wicket in a simple way?
> 
> Yeah, that's fairly simple. You can either write snippets that are
> used by components/ behaviors that integrate with our regular AJAX
> engine, or you can even plugin your own engine if you'd prefer that.
> 
>>> Its all about cost.
> 
> The funny thing is that in most discussions out there people focus on
> the cost of servers/ memory/ etc. While probably for most people -
> basically for anything that doesn't have the size of Google -
> development and maintenance cost is often the highest component. So a
> good development model makes sense.
> 
>>> we have absolute faith that it will have a lot of users according to our
>>> business plan.
> 
> May I ask what you think is a lot (say hits per second and concurrent
> sessions)? Thousands? Tens of thousands? Hundred of thousands? Even
> millions? If you're talking about really large numbers, you need to be
> aware of the choices you make in your app, not only for Wicket
> obviously, and test for scalability from the start. Though if you're
> talking about thousands up to maybe a few thousands, Wicket should be
> able to handle it fine without you having to worry about using
> stateful components.
> 
> Eelco
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Moving-from-Tapestry-to-Wicket--tp20254394p20291214.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]



Re: OnChangeAjaxBehavior receives only first input character

2008-11-02 Thread Daniele Dellafiore
I fixed it. The problem is that the copmponent I want to update was
outside the form.

On Tue, Oct 28, 2008 at 3:51 PM, Nino Saturnino Martinez Vazquez Wael
<[EMAIL PROTECTED]> wrote:
> Hi Daniele
>
> Provide your code, java and html cutout, it's clearly not similar then it
> would work..
>
> Daniele Dellafiore wrote:
>>
>> Hi all.
>>
>> I am using an OnChangeAjaxBehavior on a textField to filter contents
>> of a table.
>> My code is very similar to this example:
>> http://www.wicket-library.com/wicket-examples/ajax/on-change-ajax-behavior
>>
>> The problem I have is that the first input character is received and I
>> can get it in the onUpdate method of the Behavior. Then it stops
>> sending event, the wicket ajax debug console confirm that nothing is
>> sent anymore. If I remove and give the focus back to the field, I
>> receive a new character, and only one again.
>>
>> Here is the debug console output for the first char I receive.
>>
>> INFO: focus removed from
>> INFO: focus set on filter5
>> INFO:
>> INFO: Initiating Ajax POST request on
>>
>> ?wicket:interface=:2:authorSearch:form:filter::IBehaviorListener:0:&random=0.08630731350941423
>> INFO: Invoking pre-call handler(s)...
>> INFO: Received ajax response (261 characters)
>> INFO:
>> > id="authors6" >
>> INFO: Response parsed. Now invoking steps...
>> INFO: Response processed successfully.
>> INFO: Invoking post-call handler(s)...
>> INFO: Calling focus on filter5
>> INFO: focus removed from filter5
>>
>>
>
> --
> -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]
>
>



-- 
Daniele Dellafiore
http://blog.ildella.net/

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



Are there any open-source webapplications based on Wicket?

2008-11-02 Thread Toby78

In PHP, many open-source applications exist, such as Drupal, PHPBB...and
thousands of other scripts.
So far I have not found a single Wicket-based "website" or project.

Is there none so far or just hidden somewhere on the net ?
-- 
View this message in context: 
http://www.nabble.com/Are-there-any-open-source-webapplications-based-on-Wicket--tp20290455p20290455.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]



Refresh parent page from an iframe

2008-11-02 Thread itayh

Hi,

I have a page that contains several iframes with some actions in each
iframe. When I press on some of the actions I want the parent page to be
updated (since the actions affect the whole parent page with the iframes).
But every attempt to update the page is actually updating the iframe only.
What actually happen is that the whole page get render again inside the
iframe. I use setResponsePage(parent) within the iframe. Thats probably the
problem but I don't know what else to use.  
I try to do as it written
here:http://www.nabble.com/modal-window-navigation--td18551902.html but it
does not work.

Any idea's?

Thanks in advance,
  Itay

-- 
View this message in context: 
http://www.nabble.com/Refresh-parent-page-from-an-iframe-tp20290367p20290367.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]



JavaScript Framework Dependencies

2008-11-02 Thread Uwe Schäfer

hi

forgive me, if this topic is a dead horse already, but it really bugs me 
that this does not seem to be sorted out.
i´m just wondering why there isn´t a project like 
org.wicketstuff.javascript.mootools/jquery/extjs/whatever


the story: i was just implementing some mini behaviour using mootools 
when i found, that after packaging it nicely in a seperate project, it 
broke another mootools based behaviour used on a page that combined the two.
no suprise there, as they use different versions of mootools. the 
obvious solution is: ripping the dependency out in a seperate project 
and make both use this one. (assuming backward compatibility is reliable)


so, what do i learn from that? there should be *one single* source for 
mootools-header-contributions that any behaviour implementor is invited 
to use in order to prevent scripts form being loaded more than once on a 
single page (due to coming from different resources) and to give the 
user (or his maven or whatever he uses for dependency resolution) of 
these behaviours a chance of choosing the version.


yes, i know... maintaining could be work, but it is bearable to at least 
have all major versions of the bigger JS toolkits bundled together with 
a simple class defining resources to use those things.


to make it crystal clear: this is just about providing a single access 
point for using these scripts, not wrapping them with wicket components.


bad idea?

cu uwe

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



Re: testing borders with WicketTester

2008-11-02 Thread James Carman
Are you sure you don't want to use markup inheritance rather than borders?

On Sun, Nov 2, 2008 at 5:57 AM, Daniel Lipski
<[EMAIL PROTECTED]> wrote:
>
> Sorry, but I dont get your point...
> What do you mean self contained (in terms of Wicket API) ?
>
> Im sure there is a lot of user created border components which contain a lot
> of surrounding markup and components and it is very desireble(at least for
> me :)) to be able to 'unit' test such components with Wicket tester,
> regardles (i.e with empty) to border body.
> Does method Im looking for was not provided because of technical problems ?
> If so what is the simplest way to test border components (surrounding markup
> and components) with i.e empty body ?
>
> Regards
> Daniel Lipski
>
>
> igor.vaynberg wrote:
>>
>> borders are not meant to be self-contained like panels. they are meant
>> to be used within something that contains markup, eg page or panel.
>>
>> -igor
>>
>> On Fri, Oct 31, 2008 at 8:14 AM, dlipski <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Hi
>>>
>>> Is it possible (if not why?) to test Border components in a way similar
>>> to
>>> testing Panels ?  -WicketTester.startPanel(TestPanelSource) ? Its strange
>>> but I cant find corresponding method for Borders.
>>>
>>> Thanks in advance.
>>>
>>> Daniel Lipski
>>> --
>>> View this message in context:
>>> http://www.nabble.com/testing-borders-with-WicketTester-tp20268028p20268028.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/testing-borders-with-WicketTester-tp20268028p20288374.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: Handling runtime exceptions in ajax request

2008-11-02 Thread Alex Objelean

I'm interested in this subject too. Anyone?


Daniel Stoch-2 wrote:
> 
> Hi,
> 
> In Wicket by default IRequestCycleProcessor.respond(RuntimeException,
> RequestCycle) method is called to handle runtime exceptions. In
> AbstractRequestCycleProcessor this method throws
> RestartResponseException (or RestartResponseAtInterceptPageException)
> and then the other page is shown (eg. ExceptionErrorPage or other page
> specified in RequestCycle.onRuntimeException()).
> 
> In ajax requests I want to avoid loading another page when runtime
> exception is thrown. I want to show a proper exception message within
> the current page.
> I have prepared a small draft solution how to do this (by extending
> AjaxRequestTarget and WebRequestCycleProcessor classes), but firstly I
> want to ask you is it any "standard" way to handle runtime exception
> within ajax request, without rendering another page?
> 
> --
> Daniel
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Handling-runtime-exceptions-in-ajax-request-tp18927900p20289107.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]



Re: testing borders with WicketTester

2008-11-02 Thread Daniel Lipski

Sorry, but I dont get your point...
What do you mean self contained (in terms of Wicket API) ?

Im sure there is a lot of user created border components which contain a lot
of surrounding markup and components and it is very desireble(at least for
me :)) to be able to 'unit' test such components with Wicket tester,
regardles (i.e with empty) to border body. 
Does method Im looking for was not provided because of technical problems ?
If so what is the simplest way to test border components (surrounding markup
and components) with i.e empty body ?

Regards
Daniel Lipski


igor.vaynberg wrote:
> 
> borders are not meant to be self-contained like panels. they are meant
> to be used within something that contains markup, eg page or panel.
> 
> -igor
> 
> On Fri, Oct 31, 2008 at 8:14 AM, dlipski <[EMAIL PROTECTED]>
> wrote:
>>
>> Hi
>>
>> Is it possible (if not why?) to test Border components in a way similar
>> to
>> testing Panels ?  -WicketTester.startPanel(TestPanelSource) ? Its strange
>> but I cant find corresponding method for Borders.
>>
>> Thanks in advance.
>>
>> Daniel Lipski
>> --
>> View this message in context:
>> http://www.nabble.com/testing-borders-with-WicketTester-tp20268028p20268028.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/testing-borders-with-WicketTester-tp20268028p20288374.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]



Re: Different size of Modal Window in IE and Firefox

2008-11-02 Thread Tomasz Dziurko
Ok, problem solved. I had old cookies with changed size placed in one
browser. When I cleared cookies size of modal windows in both browsers
are equal.

Regards
-- 
Tomasz Dziurko

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



How can I format feedback messages?

2008-11-02 Thread Martin Makundi
Hi!

How can I (centrally / per component) format the Numbers and Dates in
feedback messages?

I found some discussion about it, but no solution yet:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00736.html

**
Martin

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



Re: Should/Could ServletWebRequest.isAjax be cached?

2008-11-02 Thread Martin Makundi
The profiler shows that for a (large) page, 40% of the effort (20
seconds per such particular page) goes into just parsing the tags and
does not seem to process any logic.

So, some streamlining might be in order there, even after this particular issue.

Jira issue created with attached profiler screenshot:
https://issues.apache.org/jira/browse/WICKET-1910

**
Martin

2008/11/1 Matej Knopp <[EMAIL PROTECTED]>:
> Sure this is valid but i can't imagine why this would be a bottleneck.
> Unless the webserver does something very weird while retrieving the
> header.
>
> -Matej
>
> On Sat, Nov 1, 2008 at 6:01 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>> looks good, please create a jira issue.
>>
>> -igor
>>
>> On Sat, Nov 1, 2008 at 5:11 AM, Martin Makundi
>> <[EMAIL PROTECTED]> wrote:
>>> Hi!
>>>
>>> I was profiling my Wicket application and noticed that Jetty's
>>> getHeader method was hit quite often.
>>>
>>> It turns out the ServletWebRequest.isAjax method is hit quite often by
>>> each of the page elements (I am generating a large HTML report page).
>>> Since the Servlet container may not have optimal design for processing
>>> the getHeader method, I wonder if the ServletWebRequest.isAjax -method
>>> could/should be cached within wicket.
>>>
>>> I made the following modification to the ServletWebRequest.isAjax
>>> method, and measured a notable increase in performance:
>>>
>>>  public boolean isAjax() {
>>>if (ajax == null) {
>>>  ajax = false;
>>>
>>>  String ajaxHeader = httpServletRequest.getHeader("Wicket-Ajax");
>>>  if (Strings.isEmpty(ajaxHeader) == false)
>>>  {
>>>try
>>>{
>>>  ajax = Strings.isTrue(ajaxHeader);
>>>}
>>>catch (StringValueConversionException e)
>>>{
>>>  // We are not interested in this exception but we log it anyway
>>>  log.debug("Couldn't convert the Wicket-Ajax header: " + 
>>> ajaxHeader);
>>>}
>>>  }
>>>}
>>>
>>>return ajax;
>>>  }
>>>
>>>
>>> However, my question remains: is this a valid optimization or does it
>>> break the Wicket framework? Should it somehow be incorporated in the
>>> next releases?
>>>
>>> **
>>> Martin
>>>
>>>
>>> -
>>> 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]
>
>

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