Re: [Wicket-user] Typical use case problem

2005-10-04 Thread Gwyn Evans
I think that's the trick, in that if you use IDEA's Debug rather than Run, it'll try & hotswap for you. /Gwyn On 03/10/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > just make use of the Hotswap function the JVM of sun has now for quite some > time. > (use a good debugger) > > > On 10/3/05, Ni

Re: [Wicket-user] Typical use case problem

2005-10-03 Thread Johan Compagner
just make use of the Hotswap function the JVM of sun has now for quite some time. (use a good debugger)On 10/3/05, Nick Heudecker <[EMAIL PROTECTED]> wrote: Yeah, that's what I'm getting at.  I usually write a lot of code for the Page and then make lots of little tweaks.  Redploying within IDEA eac

Re: [Wicket-user] Typical use case problem

2005-10-03 Thread Nick Heudecker
Yeah, that's what I'm getting at.  I usually write a lot of code for the Page and then make lots of little tweaks.  Redploying within IDEA each time is tiring.On 10/3/05, Gwyn Evans <[EMAIL PROTECTED]> wrote: If you mean having the Servlet engine detect changes to .java files &reload them, I haven'

Re: [Wicket-user] Typical use case problem

2005-10-03 Thread Gwyn Evans
If you mean having the Servlet engine detect changes to .java files & reload them, I haven't done it for Wicket, but I used to use Resin to do that in the past... On 02/10/05, Nick Heudecker <[EMAIL PROTECTED]> wrote: > Any thoughts about putting in a compiling class loader to save time when > dev

Re: [Wicket-user] Typical use case problem

2005-10-02 Thread Eelco Hillenius
Not sure what you mean. Eelco On 10/2/05, Nick Heudecker <[EMAIL PROTECTED]> wrote: > Any thoughts about putting in a compiling class loader to save time when > developing? That's also Rails-esque. > > > On 10/2/05, Eelco Hillenius < [EMAIL PROTECTED]> wrote: > > > > Yeah. Something like that wo

Re: [Wicket-user] Typical use case problem

2005-10-02 Thread Nick Heudecker
Any thoughts about putting in a compiling class loader to save time when developing?  That's also Rails-esque. On 10/2/05, Eelco Hillenius < [EMAIL PROTECTED]> wrote:Yeah. Something like that would be really good to have. EelcoOn 9/30/05, Dan Gould <[EMAIL PROTECTED]> wrote:> On 9/30/05, Dorel Vaid

Re: [Wicket-user] Typical use case problem

2005-10-02 Thread Eelco Hillenius
Yeah. Something like that would be really good to have. Eelco On 9/30/05, Dan Gould <[EMAIL PROTECTED]> wrote: > On 9/30/05, Dorel Vaida <[EMAIL PROTECTED]> wrote: > > I don't know about dojo but some java ajax implementations (DWR) > > propagate the exceptions back to the client. Wouldn't be tha

Re: [Wicket-user] Typical use case problem

2005-10-02 Thread Dan Gould
On 9/30/05, Dorel Vaida <[EMAIL PROTECTED]> wrote: I don't know about dojo but some java ajax implementations (DWR) propagate the exceptions back to the client. Wouldn't be that acceptable for a validation error for example ? I know that that dojo.bind lets you bind an error handler dojo.io.bi

Re: [Wicket-user] Typical use case problem

2005-09-30 Thread Eelco Hillenius
I think DWR is great for using with frameworks that do not have native ajax support/ are not component based. In fact you can use DWR with Wicket today if you don't care about your code being integration. The trick we want to do however, is to integrate ajax with our component concept. In that sens

Re: [Wicket-user] Typical use case problem

2005-09-30 Thread Dorel Vaida
Eelco Hillenius wrote: Now, that would be a great feature of our Ajax support. DWR is a framework that is complete in the sense that it provides a framework for server and client side. Libs like Dojo and Scriptaculous are client side only. But maybe they have some error reporting capabilities t

Re: [Wicket-user] Typical use case problem

2005-09-29 Thread Eelco Hillenius
Now, that would be a great feature of our Ajax support. DWR is a framework that is complete in the sense that it provides a framework for server and client side. Libs like Dojo and Scriptaculous are client side only. But maybe they have some error reporting capabilities too. Otherwise we should im

Re: [Wicket-user] Typical use case problem

2005-09-29 Thread Dorel Vaida
Eelco Hillenius wrote: Martijn is working on an app that has similar requirements. Maybe he'll want to comment on this too. What I do for an app I'm working on now, is to use ajax components for the fields that allways need to be current. In my case these usually are checkboxes. I committed an

Re: [Wicket-user] Typical use case problem

2005-09-29 Thread Eelco Hillenius
Yep, that's what I meant. Eelco On 9/29/05, Timo Stamm <[EMAIL PROTECTED]> wrote: > Eelco Hillenius wrote: > > Martijn is working on an app that has similar requirements. Maybe > > he'll want to comment on this too. > > > > What I do for an app I'm working on now, is to use ajax components for >

Re: [Wicket-user] Typical use case problem

2005-09-29 Thread Timo Stamm
Eelco Hillenius wrote: Martijn is working on an app that has similar requirements. Maybe he'll want to comment on this too. What I do for an app I'm working on now, is to use ajax components for the fields that allways need to be current. I am absolutely new to wicket, but can't you just pass

Re: [Wicket-user] Typical use case problem

2005-09-29 Thread Eelco Hillenius
Martijn is working on an app that has similar requirements. Maybe he'll want to comment on this too. What I do for an app I'm working on now, is to use ajax components for the fields that allways need to be current. In my case these usually are checkboxes. I committed an 'ImmediateCheckbox' in the

[Wicket-user] Typical use case problem

2005-09-28 Thread Denzel , Jürgen
Hi, I was wondering if Wicket provides any build in support for the following problem. The user edits data in a tabbed pane component, the data is kept in a model bean and will be stored in the database when the user presses the save button. In this context he can switch back and forth between ta