Re: [Wicket-user] Web Continuation Servers

[Andrew Berman]

That was the point I was trying to make.  The point of onSubmit/onClick handlers on each component is moot because you are already within the method which is going to do the processing.  I'm not sure if event handlers on a page would solve the issue either.  What happens when you have multiple buttons on a page that do different things?  The beauty of componentizing each button is that the developer can specify exactly what this button alone does on click.  However, with continuations, wouldn't we now have to start right away with an if statement to test which button is clicked?  I could be wrong, but this just seems to me to start getting away from the whole point of using Wicket, no?

Perhaps however, continuations would be best used in flow situations where you force the user go through a certain flow of pages/panels.  But again, I'm not sure how each individual component on each page/panel would act with continuations.  I think from the Page standpoint, as Eelco points out, that it makes sense.  But again, I'm not sure how interaction with the individual components on each Page would work.

--Andrew

On 11/26/05, Johan Compagner <[EMAIL PROTECTED]> wrote:

ahh so a program on the webserver just runs in its own thread. (every session has its own thread)
And the webserver threads are dispatchting to those threads and then getting response from them.

That doesn't look to hard to do. (the burden on the webserver would improved greatly)

If we build something like this in wicket. Where would youre code be in?
Now youre pieces of youre code is in the event/interface methods like onclick or onsubmit.
Would you then have an onClick/onSubmit on a Page? and every thing that comes in from that page
is called to there or better said it is continued there?

How would you say to wicket i want to start this part in a "continue", a special interface that a page
implements that is checked on in the response phase?

I do think this thing is not for all. Only small portions, one page. else i think you quicly get big
monolitic code again.

If i compare it to swing then i just see this continuations as the Modal Dialog...
That is the continuation in swing. You block youre current code and ask the user for something.
Then it gets back (the modal dialog is closed) and you continue.

lets think about some examples how we would do this in wicket and what would be a elegant way.

johan

On 11/26/05, Timo Stamm < [EMAIL PROTECTED]> wrote:

Andrew Berman wrote:
> I don't think continuations would fit at all in Wicket.  Components and
> continuations just don't seem to me that they would mesh at all.

Why is that? Components and Continuations work very well together.


> The
> problem is that a form component, for example, contains the logic for
> submission and you must build and add it to the page before the control is
> sent to the user.  As a result, if you had a continuation, where would you
> continue to?  You've already written the code for what is supposed to happen
> prior to the user doing anything.

That's exactly the point of continuations. Instead of continuing with an
onSubmit handler, your just continue *within the method*.


> As far as I know, RIFE is the only framework I know that uses continuations,

Cocoon has them, too. RIFE/Continuations aims to become a
general-purpose library for continuations. Jetty 6 has support for
continuations.


Timo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user