You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ke...@bredex.com on 2002/02/22 22:27:10 UTC
Re: [Schecoon] flow control layer
Ovidiu and Stefano,
First, I'm new to cocoon, but not the methodology.
I'm in the process of prototyping a conversion from a home grown (Flow
based) framework to Cocoon 2. I was hoping to discover that it was
included. I had put a small amount of effort in defining an XML syntax,
because the existing syntax is compiled into java objects...but I decided
it would be in the best interest of the company to jump into a well
supported project such as Cocoon.
Here are my thoughts and requirements for our system:
- web service or xml-rpc based interaction
- multiple web service invokations based on dynamic request parameters (per
request)
- web service request message creation (inline transformation) based on
request xml (I think I can already create xml inline for delivery as a
request to a web service)
- content aggregation and inline transformation (already in C2) for either
web service request delivery or response
I have defined Flow and FlowOperation as the primary concepts in the
system. A Flow has one to many flow operations. A flow operation can do
anything you can do with java, as long as you create a Controller to handle
it. The flow is invoked as something like:
http://mycompany.com/RootController.jsp?flow=ViewPerson&id=128282722.
Forms post to flows, and all links reference flows. You can then add,
remove, or modify flowOperations without the tight coupling of the UI.
With that said, since I'm very new to C2, I'll stick to just giving
feedback on how I want to use C2. I'm unclear on what is exactly already
present in the project, but I see a great deal of potential.
I would be extremely interested in contributing to the development of a
Flow control layer with C2....because we are looking to convert our system
right now. I'm ready to start today, but I'll definitely need a guiding
light to get started.
I will say that I'm interested only in an xml-based flow syntax, possibly a
much simpler version of one I was considering for the home grown version.
Please let me know if I can help, or if you can point me in a direction
where Cocoon 2 already fulfills my needs.
Kevin Ross
================== Flow Config ==========================
<?xml version="1.0" encoding="UTF-8"?>
<site>
<flowOperationRegistry>
<flowOperation default="true" classname="
com.iverticalleap.presentation.flow.FlowOperation"/>
<flowOperation name="loadSubjectListXML">
<delegate>/jsp/FilterFormController.jsp</delegate>
</flowOperation>
<flowOperation name="xsltDisplayTransformation" classname="
com.iverticalleap.presentation.flow.XsltTransformationDisplayFlowOperation
">
<delegate>/jsp/TransformationController.jsp</delegate>
</flowOperation>
<flowOperation name="xsltContentTransformation" classname="
com.iverticalleap.presentation.flow.XsltTransformationContentFlowOperation
">
<delegate>/jsp/TransformationController.jsp</delegate>
</flowOperation>
<flowOperation name="reflectionContentFlowOperation" classname="
com.iverticalleap.presentation.flow.ReflectionContentFlowOperation">
<delegate>/jsp/ReflectionController.jsp</delegate>
</flowOperation>
</flowOperationRegistry>
<flowList>
<!-- the following are the ideas i've come up with -->
<!-- 1 (basic) -->
<flow name="DisplayCreateStudentFlow">
<flowOperation refname="loadSubjectListXML"/>
<flowOperation refname="loadClassListXML"/>
<flowOperation refname="xsltDisplayTransformation">
<propertyList>
<property name="xsltUrl">/jsp/admin/createPerson.xslt</property>
</propertyList>
</flowOperation>
</flow>
<!-- 2 (same thing but with reflection so you don't have to create the
controller -->
<flow name="DisplayCreateStudentFlow">
<reflectionFlowOperation name="loadSubjectListXML">
<invoke methodName="getSomeObject" className="
com.iverticalleap.service.SomeService">
<parameter name="identity">
<value><!-- value is dynamically derived from posted variables
-->
<invoke methodName="getParameter" className="
java.servlet.http.HttpServletRequest"> <!-- also thought about calling this
an <implicitObjectInvokation name="request"> -->
<parameter name="parameterName">
<value>PersonIdentity</value> <!-- html form variable
name -->
</parameter>
</invoke>
</value>
</parameter>
</invoke>
</reflectionFlowOperation>
<flowOperation refname="loadClassListXML"/>
<flowOperation refname="xsltDisplayTransformation">
<propertyList>
<property name="xsltUrl">/jsp/admin/createPerson.xslt</property>
</propertyList>
</flowOperation>
</flow>
</flowList>
</site>
Ovidiu
Predescu To: Stefano Mazzocchi <st...@apache.org>
<ovidiu@cup.hp cc: cocoon-dev@xml.apache.org
.com> Subject: [Schecoon] flow control layer (WAS Re: [RT] Sources and Drains (long response))
Sent by:
ovidiu@orion.r
gv.hp.com
02/22/2002
02:12 PM
Please respond
to cocoon-dev
On Fri, 22 Feb 2002 17:05:13 +0100, Stefano Mazzocchi <st...@apache.org>
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 <ov...@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other
stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org