In Cocoon, the continuation ID is generally passed through the URL, which does not break the back button.
Additionally, a URL can represent anything you desire. you just need to hook it up correctly in the sitemap.
Continuations:Web :: Sequential/Modal:GUIs
Posted byAnonymous Userat
2003-11-23 09:09 AM
Your comment only further illustrates my point.
First, a "continuation ID" means there has to be a continuation stored on the server (or else you'd be saying "continuation state", not "continuation ID"). This is still stateful, even if the application in question doesn't always need it.
Second, the existence of a "sitemap" indicates a centralized architecture. A decentralized web object framework wouldn't have such a thing as a "site map". Take a look at this site... objects nest within objects, as is visible by their URLs. And as data is added, the trees grow and change. That's not possible with a single static "site map".
URLs should represent persistent things, or methods upon persistent things. That's what the web is. Trying to use continuations for a web application just means you don't really understand what the web is for, like a programmer who writes a highly-modal GUI, fighting the event-driven model every step of the way. Like GUIs, Web apps naturally fit to an event-driven asynchronous messaging model. Even better, they usually fit a transaction-per-event model, which makes them even easier to write than GUIs.
To me, the only legitimate use of cross-event continuations in a web application is to model the state machines of published persistent objects. For example, a web workflow object might use continuations to track the stage of the workflow instance. But, that is something that occurs behind the REST representation of the workflow instance, because the continuation is shared for everyone referencing that instance. In other words, such a continuation is not part of the UI view, it's part of the application domain model.
In Cocoon, the continuation ID is generally passed through the URL, which does not break the back button.
Additionally, a URL can represent anything you desire. you just need to hook it up correctly in the sitemap.
Your comment only further illustrates my point.
First, a "continuation ID" means there has to be a continuation stored on the server (or else you'd be saying "continuation state", not "continuation ID"). This is still stateful, even if the application in question doesn't always need it.
Second, the existence of a "sitemap" indicates a centralized architecture. A decentralized web object framework wouldn't have such a thing as a "site map". Take a look at this site... objects nest within objects, as is visible by their URLs. And as data is added, the trees grow and change. That's not possible with a single static "site map".
URLs should represent persistent things, or methods upon persistent things. That's what the web is. Trying to use continuations for a web application just means you don't really understand what the web is for, like a programmer who writes a highly-modal GUI, fighting the event-driven model every step of the way. Like GUIs, Web apps naturally fit to an event-driven asynchronous messaging model. Even better, they usually fit a transaction-per-event model, which makes them even easier to write than GUIs.
To me, the only legitimate use of cross-event continuations in a web application is to model the state machines of published persistent objects. For example, a web workflow object might use continuations to track the stage of the workflow instance. But, that is something that occurs behind the REST representation of the workflow instance, because the continuation is shared for everyone referencing that instance. In other words, such a continuation is not part of the UI view, it's part of the application domain model.
Replies to this comment