Ovidiu Predescu wrote:
> The way I intend to hook-up the flow control layer into the system is
> by having the sitemap invoke flow functions or continuations.
Ok.
> 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.
Ok, cool, time to take a serious look at it.
> - 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.
why isn't simple and friendly positional syntax good enough? (remember:
I'm going to ask you to remove half of the things, and then half again,
until everything that's there *has* to be there, I'll be your anti-FS
nightmare :)
> - 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.
nice and elegant, I like this *very much*!
> 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.
yes, but as long as users aren't bugged with this feature, I say it's
safe to leave it there for power users.
> 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.
Yes, I am. Definately. In order to provide a syntax, one has to
understand the semantics. Without a detailed example, I think I might
not be able to grasp the entire concepts that the syntax should
describe.
> 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.
Yes, that's the very serious issue that remains: how to apply MVC on
such a weird artificially statefull system. (note: MVC was invented on
the client side and assumed statefullness, it has *not* obvious to think
that MVC works *AS IS* on a web environment)
In fact, MVC isn't nothing but an 'instance' of a well designed SoC: the
question we should ask now is: do these concerns islands have a direct
parallel on server side?
Almost *all* web application frameworks (ranging from JSP model 2,
Struts, Turbine, etc...) think so.
I'm personally not that sure.
> 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.
Ok.
> The business logic layer produces objects which need then to be used
> by the content generation phase.
Yes, I agree that this is a must. It's a simple approach and clearly
separates concerns.
> 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.
Sounds *very* similar to what Velocity implements.
Do you think that it would be possible to use Velocity for this? I'm
sure this would ease collaboration between us and many jakarta folks
incredibly.
> 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.
Ok.
> And now to conclude Berin's question about Actions, I believe in the
> new model they are no longer necessary.
Awesome!!!
> They were a substitute for a
> true flow control layer. However Nicola I believe, pointed out they
> might be useful for other things.
For sure we can't remove them since *many* people rely on them, so my
suggestion would be to make them cohexist as much as possible and decide
later on if it makes sense or not to deprecate them.
But even if Schecoon would be ready to be merged in the main trunk, I
would not deprecate actions at that time.
> So I'd like to hear your comments on
>
> 1)the sitemap/flow control layer integration,
I like it.
> 2) flow control, business logic and content generation separation I
> described above,
I like the concept, yes, and the fact that reminds me a lot of Velocity
tells me that we are on the right track (and might be a great political
move to *finally* allow convergence of Cocoon and some jakarta folks)
> 3) whether actions are still meaningful in the context of flow
> control.
I honestly don't know, but for sure we can't remove them and deprecate
them would be a bad move for many.
Moreover, we must understand that as soon as books start to come out, we
*must* support technologies for longer cycles, even if this sacrifices
elegance and architectural beauty.
I'm sure Carsten and Matthew agree with me here :)
At the same time, if flowmaps and actions create pitfalls, we'll
deprecate them or change them accordingly.
What I'm saying is that Cocoon is finally becoming mainstream and has
the potential to become *the* way of building XML applications. While
this is awesome, it also places lots of pressure on back compatibility
and support for our user community, which is our real value.
At the same time, I don't want Cocoon to stop innovating and researching
new solutions... just consider that these new solutions (Schecoon being
one of them) will have to provide an *easy* migration path.
For this reason, I think we should add a "deprecated" log channel
(turned on by default), where we output things that are deprecated.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
