Reinhard Pötz wrote:
From: Christopher Oliver
<snip />
Even so, I really don't like your names. <map:call> made perfect sense when calling a continuation or function (since they are actually callable). I don't quite get what "calling" a "state" means.
I would be interested in this too because I'm wondering what can you do with a plain Java controller what Actions can't do for you? Or do you _only_ want to make a shift away from actions?
maybe we should separate out some ideas in this paragraph:
[_only_]
- no it is not _only_ about stateless controllers, it is also about the 'second approach' (dubbed for now: 'InteractionState') and it touches on webcontinuations as well, that is why the thread and the wiki talk about 'generalizing'
- as such it is about finding an umbrella API to accomodate for all of them by focusing on the similarities while leaving room for the differences in the specialized implementations
(like Sylvains example: XSLT is a great and often used stereotypical example of what a transformer can do, we would however have a hard time looking at all the transformers in the cocoon cvs as being stylesheets... mind that the dedicated XSLT hardcore believer would probably even succeed at writing down all of them as XSLT stylesheets! (even if that would require him to write custom extensions))
- see also Bertrand's message praising the 'interfaces': it realy is _ONLY_ about generalizing some common aspects between the different web app programming models we identified into a common approach...
- the OO textbook says that this 'generalization' should accomodate for higher level of reuse. In this case hoped for are:
- common sitemap semantix on the one side
- reusing complete publishing pipes (but more importantly: the knowledge to build those)
- (more socio-engineering level) a general mindset for all webapps in Cocoon
[actions]
- there is this (nasty) bit in the wiki (on purpose) on this very issue:
6. faq
Q: Why don't we just use Actions for the stateless flow control?
A very good question indeed. In fact looking at it from the
> WebContinuations angle there is quite little distinction to > be made between
<map:call function="fn_name" /> and <map:act type="start-flow" src="fn_name" /> or even <map:call continuation="{1}" /> and <map:act type="cont-flow" src="{1}" />
Actions however have been quite largely seen as 'bad', a stigma
> they probably got while the community extended the original > Action interface so it could be a havenfor 'arbitrary control > logic'. > Having said that, we believe that current webapps still have > room for a more classic 'stateless flow control'. > If we now try to hook in arbitrary logic for the FlowControl, > we should envision it having a simple mechanism for doing > stateless stuff.
Rather then wanting us to write up the flow with the map:act
> equivalent we would hope for a flow-umbrella API that allows > for stateless implementations as well. Small changes in the > wording of the sitemap-elements and attributes could > achieve a lot:
- you can do anything with Actions (even start and continue the flow), and that is probably why a lot of us don't really like them: they don't feel like the correct 'generalization' of the issue.
- the proposal hopes to do a better job.
[inverting the proposition]
- history is what it is, but I like this thought-experiment anyway: what if InteractionState was in cvs now, and someone came along with an other way of addressing the web app flow issue and called that new thing 'webcontinuations'
How should we react?
Probably not by proposing: hook it up in the start-flow/continue-flow actions, right? :-)
Cheers, Reinhard
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
