On Fri, 5 Apr 2002, Ovidiu Predescu wrote:
> 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.
This is just a simple example, I could also have written:
if (test==true) {
something happens...
}
else {
something else happens...
}
In a declarative model something like <foo/> is equivalent to "something
may be triggered at a later stage".
> 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.
As I wrote I just spent several days thinking about logic in web apps. I
found different types of logic and two of them are:
1) External Flow Control. That is what you concern yourself with, you
describe the flow control *between* components (here: XML pages).
2) Internal Flow Control. That is what the above example shows: flow
control *within* a component (here: an XSP page).
My thought simply was that, if it is next to impossible to convert such a
simple procedural example into a declarative model, how hard will it be
for external flow control? You concern yourself with very complex
components, that can play with each other in strange ways.
Maybe, and this is just a very random thought, maybe procedural and
declarative semantics are incompatible. Mathematically they're equivalent
and both semantics can be wrapped in the other, but this usually results
in very impractical solutions.
> 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.
You can always write the business logic in Java classes and in the XSP
taglib you just use the class - like you would use it in other
applications. You can also do it the other way - long live freedom of
choice :)
> 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.
Let us rethink my simple example in your model. Since you do only external
flow control, we'd have to take my XSP page apart into two components, one
for the if-case and one for the else-case. Then you have a central
service, the control flow layer, that switches between the new components.
Two thoughts:
1) The number of components increases. For every possible path through the
application, each node on this path needs to be a component. Previously
our components were cluttered with internal flow control, now we moved
the clutter into the filesystem and/or into the flowmap.
2) Many components will contain largely redundant code, which affects
re-usability. Suppose you have a large switch/case statement with 20
cases, then you end up with 21 components (the 21st for exception
handling), which will be 99% identical. If some of the common code
changes, you have to change it in 21 components.
> Does this answer any of your questions, or was I completely off track?
I don't know, but am I completely off track here? :)
cheers,
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
