Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-Id: <200202270317.g1R3Hhe15141@orion.rgv.hp.com>
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Stefano Mazzocchi <stefano@apache.org>
Cc: cocoon-dev@xml.apache.org
Subject: Re: [Schecoon] flow control layer 
In-Reply-To: Your message of "Sat, 23 Feb 2002 13:27:34 +0100."
             <3C778AB6.BC156AD0@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 26 Feb 2002 19:17:43 -0800
Sender: ovidiu@orion.rgv.hp.com

Sorry I'm so late with my response, I was busy with an approaching
deadline...

On Sat, 23 Feb 2002 13:27:34 +0100, Stefano Mazzocchi <stefano@apache.org> wrote:

> > - 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 :)

Fair enough ;-)

I guess I'm a little bit biased by languages like Python and Common
Lisp, where you can actually do this. It's a very nice feature and
very easy to implement. It also opens the road to functions with
variable number of arguments, something which I badly miss in Java.

> > - 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*!

All right!

> >   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.

Yep. The system will allow it, but not force you to do it.

> > 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.

The more I think about it, the more I realize that writing a complete
sample in Scheme will scare the people away. So I think I'll postpone
this little exercise until I have some rudimentary implementation of
the flow language. I just hope to find the time to write the
translator...

> > 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?

I think so. And I believe we should be able to implement this once the
control flow is implemented. What I just described in the previous
message is exactly an implementation of the MVC pattern.

> > 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.

It should definitely be possible. I am thinking to implement a JSP
taglib, besides the XSP logicsheet I've alreay written. As I become
more familiar with Velocity, I will get some more insights on this can
be implemented.

> > They [actions] 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.

I'm not saying we should remove actions. Schecoon is implemented right
now as yet another Processor (read sitemap) implementation. In theory
at least, it should be possible to mount a Schecoon sitemap from a
compiled sitemap, or from Sylvain's interpreted sitemap. So parts of
the application can be implemented using various technologies, as the
developer feels comfortable.

> > So I'd like to hear your comments on
> > 
> > 1)the sitemap/flow control layer integration,
> 
> I like it.

Good ;-) Just wanted to see if I'm on the right track here.

> > 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)

I hope that too!

> > 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 :)

Yes, we should support them, and although Schecoon will probably not
support them directly, they can be used with the rest of Cocoon. If
practice shows that actions and the flow layer make sense, I'll think
about supporting them directly in Schecoon.

> At the same time, if flowmaps and actions create pitfalls, we'll
> deprecate them or change them accordingly.

Agree.

> 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.

I cannot agree more!

> For this reason, I think we should add a "deprecated" log channel
> (turned on by default), where we output things that are deprecated.

Yes. The hardest part is having users read that log and understand
what are the alternatives to the deprecated things.

Regards,
-- 
Ovidiu Predescu <ovidiu@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