Hi Uli,
On Sat, 6 Apr 2002 00:00:57 +0200 (MEST), Uli Mayring <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Apr 2002, Jason Foster wrote:
>
> [... other frameworks ...]
>
> > Cocoon
> > - you code your *logic* in a procedural language and the runtime handles
> > "continuations"
> > - you code your *presentation* as individual web pages created using
> > transformations and/or embedded scripting
> > - the logic can make use of the presentation, which in turn can continue
> > the logic
>
> Wow, this sounds deep. Reminds me of when I coded in Prolog (a declarative
> logic programming language), I never knew which object could in which
> circumstances call which other object - and just as I thought I understood
> the flow, the Runtime was up to something on its own :)
>
> I have spent the last couple of days thinking about the following problem.
> Suppose in an XSP page you have this flow control code:
>
> if (test==true) {
> <foo>bar</foo>
> }
> else {
> <bar>foo</bar>
> }
>
> Rewrite this procedural code in a declarative way. After much fiddling
> about I came to the conclusion that there is no elegant and practical
> solution. But perhaps you guys can solve this problem on a higher level,
> one advantage of Cocoon is that there are plenty of higher levels :)
I think what you want to describe in the XSP page example above is
what needs to appear in the generated output only, it's not control
flow.
I believe the accepted definition of control flow for Cocoon refers to
how a Cocoon application describes the flow of pages generated as
response. I'll briefly describe below some of my thoughts on how
things fit together in Schecoon.
The control flow is a separate layer in Schecoon. Its introduction
promotes a model-view-controller programming paradigm for Web
applications. The model is the business logic, usually written in
Java; the view is represented by the sitemap which describes how to
generate the response; the controller is the control flow layer.
As you notice, this is a very different approach than the one promoted
so far by ASP, JSP, XSP and other markup technologies. These
technologies allow you to mix business logic with the markup, which
promotes page oriented programming. This IMO is very bad, because is
hard to reuse the business logic embedded in these pages in other
contexts.
With the new approach, in the XSP page you only put tags which extract
data passed to the page by the control flow layer. This data is
synthesized by the control flow layer (the controller) from the
business layer (the model). The data is extracted using simple XPath
expressions which work across Java objects instead of XML
documents. To be able to have markup conditionally generated as in the
example above, you have simple XSLT-like constructs that allow you to
do this. Check out the jpath.xsl in Schecoon to see what is available,
and also look at the calculator example in Schecoon:
http://cvs.apache.org/viewcvs/xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/markup/xsp/jpath.xsl?rev=1.7&content-type=text/vnd.viewcvs-markup
http://cvs.apache.org/viewcvs/xml-cocoon2/src/scratchpad/schecoon/webapp/examples/calc/
The calculator sample doesn't use any of the control instructions in
JPath, but I think you get an idea of how things work.
Does this answer any of your questions, or was I completely off track?
Regards,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
