Johan Compagner 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)
Yes, the load on the webserver would increase.
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?
My opinion on implementation in Wicket lacks a lot of insight - I don't
have time to really dig into wicket interna until next year.
I guess there are similarities to the handling of AJAX requests at a low
level. Maybe there is a chance to generalize this and add all kinds of
request handlers.
Where to add a hook for the user? Continuations would be used for flow
control, so they would be part of the Control layer of the MVC paradigm.
If Wicket Components are the View, they should not need to know about
Continuations.
I am thinking of an Object that takes over control from a certain
starting point. For example, you would have a button labeled "start",
whose onClick handler creates an instance of the Control Object and
passes the context on (if necessary).
The Control Object should have a method to send a Page to the client
(i.e. set the Response Page) and wait for the next Request for a Page.
I do think this thing is not for all. Only small portions, one page. else i
think you quicly get big
monolitic code again.
Yes, continuations certainly don't make sense for every kind of application.
I think that continuations would be very convenient for some
well-defined workflows, but it does not make sense to use them
everywhere for the reasons you mention.
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.
Yes, this is the idea. Just like the JavaScript alert(), confirm() and
prompt() functions.
lets think about some examples how we would do this in wicket and what would
be a elegant way.
Let's say we have the Control Object mentioned above. The most important
public method would be:
WebPage sendAndWait(WebPage p);
(This method hides all the dirty work from the user, add a Request
handler, etc.)
I think it would be convenient to provide methods for common tasks:
void alert(String message);
boolean confirm(String question);
String prompt(String question);
These methods send a default AlertPage, ConfirmPage or PromptPage,
evaluate the result after sendAndWait() returns and return a proper value.
An extension of the Control Object could provide methods for simple
creation of Dialogues. Example:
DialogueModel ask(DialogueModel d);
Usage:
DialogueModel userInfo = new DialogueModel();
userInfo.addStringInput("name", "What is your name?");
userInfo.addStringInput("color", "What is your favorite color?");
while (userInfo.hasEmptyInputs()) {
ask(userInfo);
}
You don't have to care about the view at all at this level of
abstraction. You just work with the model.
Any comments are welcome,
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
