Eelco Hillenius wrote:
/The/ big difference between a component/ event based framework like
Wicket and a (web) continuations framework is that with Wicket your
focus should be what's on your pages and how it reacts to user input,
using different pages to address different areas of functionality,
while with a continuations framework you focus on the flow of the
application (think in flows and have things like 'processAndWait' as
transition marks). There is no 'better' approach imo. For the kind of
applications I am usually involved in making, Wicket is a better fit,
and in my experience analysts are usually more focussed on direct
interaction/ domain functionality than on flow. Might be different for
you though.
This sounds like an apology ;-)
But there is no reason to apologize. I consider Wicket the best choice
in java web frameworks for most applications.
It lacks tutorials and and third party libraries to compete with Struts
and other more wide spread frameworks, but it is obviously technically
superior. Especially when compared to Struts :-)
Back on topic:
I understand your argument that "[wicket] does the same thing as
the original definition [of continuations]". You said that even though
implementation may differ, the net effect is the same.
Of course that is true. From your linked page on common-lisp.net:
"Continuations in web apps do not allow you to do anything which can't
be done without them, though i'd argue that there are certain user
interactions which are too complex to manage (for a developer's point
of view) without them."
There is no native support for continuations in Java, so it is
neccessary to emulate their behaviour to allow for flow oriented
programming. Sure, Wicket is not incompatible with such an emulation of
continuations, but there is no determined support for flow oriented
programming as well.
Is support for flow oriented programming necesary? I think it is highly
desirable. With abstractions of data objects and editors (in the spirit
of the Code generator / Prototype generator thread), you can concentrate
on the most important part of most applications: the flow. If you don't
have to spread your business logic and work flow over several classes
and layers, you will simply increase the code quality.
I have had a quick look at RIFE/Continuations, and it looks usable.
There is a presentation that gives an immediate impression:
https://rife.dev.java.net/files/documents/204/3120/rife_fosdem_2004.pdf
(page 5 to 8 are the interesting ones)*.
Timo
* I find the term "web continuations" irritating. Either you have native
continuation support or an emulation.
Eelco
On 10/5/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
That was part of my point earlier on. There is a difference between
the 'normal' continuations concept and how it is applied to web
frameworks though. There are people working on 'native' continuations
support.
Here's a must-read on the topicus, which discusses a lot of points
that are relevant to Wicket as well (like I said, the way Wicket and
web continuations work doesn't differ that much imo):
http://common-lisp.net/project/ucw/docs/html/rest/rest.html
Eelco
On 10/5/05, Justin Lee <[EMAIL PROTECTED]> wrote:
Actually, rife supports continuations in java. https://rife.dev.java.net/
Timo Stamm wrote:
Eelco Hillenius wrote:
Actually, when you look closer to the whole continuation thing,
continuations are not so incompattible with how Wicket works now.
I guess the problem is that continuations are not really compatible with
java. An elegant implementation of continuations in java seems to be
impossible.
The
original idea of continuations is to never return a value, but pass a
context object (continuation) to the next function call. That idea
translated to webapplications seems to be to have a 'wait-for-input'
concept, so that you can model a flow like a couple of linear steps
that conceptually 'pause'/ wait for input before it moves to the next
step. As Wicket has a current state and does not work with return
values for flow, I think we could defend that we do the same thing as
the original definition, though with a slightly different flavor. At
least it has the same net effect. And... if you want to do the web
variant of continuations... that's easy... just create a mini
framework that handles the flow and - I think - you're done.
That would just be a state machine.
Or... maybe I don't get the idea of continuations just yet. Please
correct me if that is the case :)
Have a look at this article:
http://www-128.ibm.com/developerworks/library/j-contin.html
Jetty 6 is going to have continuation support. Are there any plans of
supporting jetty continuations?
http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html
Timo
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Justin Lee
http://www.antwerkz.com
AIM : evan chooly
720.299.0101
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
