> Moreover, now that we clearly identified the SoC between > syntax/semantics and many examples showed that the same semantics could > be equally expressed with different syntaxes, it's good that we now > concentrate on the semantics and let the syntax be the last of our > concerns. > > In theory, if one likes, we could make the syntax wrapper pluggable, so > that you could write your flow-driving code with the syntax you like the > most (or it best fits your favorite IDE)
An (IMHO) equally valid "theory" is that we could also make the semantics pluggable. A little while back I sent in a message that tried to raise the issue of what aspects of Cocoon should be rigidly specified and what aspects should be open. So far there have been no replies, but I'd like to re-raise the issue anyways. As things stand Cocoon appears to define the following conceptual invariants: - Requests and Responses - Pipelines - Generators - Transformers - Serializers The sitemap (which I consider separate from the core aspects of Cocoon, but please don't hold that against me) also defines at least one other concept: - Views Everything else is implementation ;) The current discussion of flows and resources is important (and fun!) but it seems to be moving very quickly towards implementation without having resolved some key conceptual issues. I can't wait to see how the "implicit" approach to defining a webapp works (Prolog! Prolog!), but I would also like to make sure that we have a common vision of what webapps, flow, resources, etc. actually are and what we're trying to accomplish. For example a webapp could be seen as: - a "standard" event-driven, object-oriented application where web requests are translated to method invocations (WebObjects) - a continuation-based application where the choice of continuation is based on a request parameter - a FSM - a set of web pages hooked together manually by a developer who manages session and persistance aspects manually - a test for provability given axioms and theorems Should Cocoon provide a formal definition of a webapp? Personally I don't think so. My (not terribly well informed) opinion is that Cocoon should add one more concept, the "Controller", which is an implementation of the GoF strategy pattern, and that is responsible for controlling the response to requests. Different controllers would embody different models of webapps. Comments? I don't think I'm out to lunch, but you never know... Jason --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
