On Fri, 22 Feb 2002 17:05:13 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> > I think that the addition of Actions can attest to that. Lets take
> > Cocoon and instead of a web application platform lets place it in the
> > light of a web services platform (all XML all the time).
>
> [snipped discussion on web services platform built on top of cocoon]
>
> The more I think about it, the more I think Actions don't belong to the
> sitemap... but to be entirely honest with you, I don't have a clear view
> of where we should lead the semantics to.
>
> I see great promises in Ovidiu's work on Schecoon... but we also need a
> way to make the two things (flowmaps and sitemaps) interoperate yet
> keeping concerns separated and keep the number of contracts the smallest
> possible.
>
> And this is *not* an easy architectural task :/
The way I intend to hook-up the flow control layer into the system is
by having the sitemap invoke flow functions or continuations.
If you look in the sitemap of Schecoon right now, you'll see the
following things:
- how flow scripts are made available to the system:
<map:resource type="flow">
<map:script src="/example.scm" language="scheme"/>
</map:resource>
This tells the sitemap to use the example.scm file from the current
webapp as flow definitions (written in Scheme). In the near future,
you'll be able to also specify:
<map:resource type="flow">
<map:script src="/example.flow"/>
</map:resource>
where example.flow is written in the flow language.
- how the sitemap invokes a top level flow function:
<map:match pattern="function/(.*)">
<map:call function="{1}">
<map:param name="a" value="1"/>
<map:param name="b" value="2"/>
<map:param name="c" value="3"/>
</map:call>
</map:match>
In the flow language a function will be defined like this:
function my-function(a, b)
{
...
}
The calling convention for function allows passing arguments using
either the well-known positional rule, or using named parameters. E.g.
my-function(1, 2)
in my-function the value of 'a' is 1, and the value of 'b' is 2.
my-function(a = 1, b = 2)
where 'a' is 1, and 'b' is 2.
my-function(b = 2, a = 1, c = 3)
In this example 'c' is ignored, no warning is issued.
- how the sitemap invokes a stored continuation:
<map:match pattern="kont/(.*)">
<map:call function="schecoon:handle-continuation">
<map:param name="kont-id" value="{1}"/>
</map:call>
</map:match>
Continuation ids are passed in the URL in this example, but they can
be obtained from a parameter of the request, or anything you like,
as we discussed in a previous thread.
The function that handles continuations is a function written in the
flow language. One is provided by default, but developers can write
their own functions to customize the system as they wish. This is an
advanced feature which will probably be used seldom.
The above things are working fine right now, although I don't have a
good example to demonstrate it. Since the flow would be written in
Scheme, I figured not many people would be interested in it. But
please let me know if there's interest to see a complete example using
the flow layer written in Scheme.
There are two things I've been looking at this past two weeks. The
first one is how to separate the business logic, flow control and
content generation.
Right now with XSP, JSP or any other template system there's no clear
separation between all these layers. What I've been thinking to do to
separate them is to have the flow layer drive the business logic
layer.
The business logic layer produces objects which need then to be used
by the content generation phase. The flow control layer obtains these
objects and passes them to the content generation phase, using either
dictionaries or by passing them directly. The content generation (and
the presentation transformation layer) are invoked using the
'send-page' function:
send-page(sitemap-pipeline-resource, arguments for the pipeline resource,
business objects);
For example in the sitemap I have the following pipeline resource:
<map:resource name="xsp">
<map:generate src="{source}" type="serverpages"/>
<map:serialize/>
</map:resource>
In the flow layer I can call this pipeline:
send-page("xsp", {"source" = "xsp/example.xsp"}, business-object);
or
send-page("xsp", {"source" = "xsp/example.xsp"},
{"abc" = object1, "def" = object2, etc.});
The third argument can be either an business object obtained directly
from the business logic, or a hash table of such objects.
Then the content generation phase can obtain these objects using a
simple XPath-based syntax. The document that's walked on are in fact
Java objects, and an element name is an object's property. I'm using a
Jakarta commons library to do this, which internally works using the
Xalan XPath implementation.
I've written a simple logicsheet, jpath.xsl, which allows object
properties to be inserted in the generated output page. The following
elements are currently understood by the logicsheet (modeled after
XSLT):
- <jpath:if test="...">
tests if a property exists or has a given value
- <jpath:value-of select="...">
obtain the value of an object's property
- <jpath:for-each select="...">
iterate over object properties
One is supposed to use only the JPath logicsheet in his/her XSPs. With
this approach, the content generation layer is now clean, no logic
processing ever happens here. A similar set of taglibs can be
implemented for JSP.
The second thing is the flow language itself. I have some thoughts on
it, and I'll try to come up with a grammar for it over this
week-end. I'll explain more of concepts its concepts at that time.
And now to conclude Berin's question about Actions, I believe in the
new model they are no longer necessary. They were a substitute for a
true flow control layer. However Nicola I believe, pointed out they
might be useful for other things.
So I'd like to hear your comments on
1)the sitemap/flow control layer integration,
2) flow control, business logic and content generation separation I
described above,
3) whether actions are still meaningful in the context of flow
control.
Best 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]
