Ovidiu Predescu wrote:
>
> 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 <[EMAIL PROTECTED]> 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.
Ok, you changed my mind. I've always missed the ability to have a
variable collection of parameters to pass and I think it could be way
cool to add it.
So, go on.
> > > - 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...
Please, consider giving us more info so that you don't have to write a
translator, we reject the syntax and you have to write another one.
Trust the power of open development and trust the open-mindness of the
cocoon community.
> > > 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.
Probably, but I'm still not that sure. Time will tell.
> > > 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.
IMO, if we provide flowmap 'hooks' for all three major technologies
(xsp, jsp and velocity) nobody will ever be able to say that we don't
ease transition and give them the choice they like :)
So I think it's a must we provide all three (I'm not saying that you are
the one who should do it, but for sure we'll have to do it before
releasing the beast)
> > > 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.
This is very cool.
> > > 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.
I definately think you are.
> > > 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.
I really like this incremental approach.
> > 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.
Ok, this is a more general topic and I'll try to address this on the
mail list.
Ciao.
--
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]
