You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ovidiu Predescu <ov...@apache.org> on 2002/09/06 07:22:51 UTC
[control flow] changes and new sample
Hi,
I've finally had time to finalize some changes to the control flow
layer, which should make it more usable. I've also wrote a simple
application that makes use of these changes and shows how the control
flow layer is supposed to be used. I also plan to write some real
documentation on how to use the control flow layer. Before then
however, I'll write here some quick thoughts on how this works. At some
point I'll take these and transform them into a real document.
This is a long description describing potentially important stuff for
you, so you may want to read through it with a fresh mind. So grab a
cup of strong coffee before you start.
Model-View-Controller
=====================
With the control flow architecture in place a Cocoon Web application is
split in three different conceptual layers, using the well-known
Model-View-Controller (MVC) pattern:
- Model: the business logic, e.g. Java classes which implements the
meat of your application.
- View: the collection of the XML pages and XSLT stylesheets that give
a visual representation to your business objects. In Cocoon the pages
used in the View layer can be simple XML files or XSP pages that use
the JXPath logicsheet. More on this later.
- Controller, which is coordinating the sequence of pages being sent to
the client browser, based on the actions taken by the user. In Cocoon,
the Controller is a specialized engine which uses a modified Rhino
JavaScript implementation which supports continuations as first class
objects. From a user (really a developer) perspective, the Controller
is nothing else than a collection of JavaScript files running on the
server side.
The general flow of actions in an application which uses the control
flow is as described below.
The request is received by Cocoon and passed to the sitemap for
processing. In the sitemap, you can do two things to pass the control
to the Controller layer:
- you can invoke a JavaScript top-level function to start processing a
logically grouped sequences of pages. Each time a response page is
being sent back to the client browser from this function, the
processing of the JavaScript code stops at the point the page is sent
back, and the HTTP request finishes. Through the magic of
continuations, the execution state is saved in a continuation object.
Each continuation is given a unique string id, which could be embedded
in generated page, so that you can restart the saved computation later
on.
To invoke a top level JavaScript function in the Controller, you use
the <map:call function="function-name"/> construction.
- to restart the computation of a previously stopped function, you use
the <map:continue with="..."/> construction. This restarts the
computation saved in a continuation object identified by the string
value of the "with" attribute. This value could be extracted in the
sitemap from the requested URL, from a POST or GET parameter etc. When
the computation stored in the continuation object is restarted, it
appears as if nothing happened, all the local and global variables have
exactly the same values as they had when the computation was stopped.
Once the JavaScript function in the control layer is restarted, you're
effectively inside the Controller. Here you have access to the request
parameters, and to the business logic objects. The controller script
takes the appropriate actions to invoke the business logic, usually
written in Java, creating objects, setting various values on them etc.
When the business logic is invoked, you're inside the Model. The
business logic takes whatever actions are needed, accessing a database,
making a SOAP request to a Web service etc. When this logic finishes,
the program control goes back to the Controller.
Once here, the Controller has to decide which page needs to be sent
back to the client browser. To do this, the script can invoke either
the sendPage() or the sendPageAndContinue() functions. These functions
take two parameters, the relative URL of the page to be sent back to
the client, and a context object which can be accessed inside this page
to extract various values and place them in the generated page.
The second argument to sendPage and sendPageAndContinue is a context
object, which can be a simple dictionary with values that need to be
displayed by the View. More generally any Java or JavaScript object can
be passed here, as long as the necessary get methods for the important
values are provided.
The page specified by the URL is processed by the sitemap, using the
normal sitemap rules. The simplest case is an XSP generator followed by
an XSLT transformation and a serializer. This page generation is part
of the View layer. If an XSP page is processed, you can make use of
JXPath elements to retrieve values from the context objects passed by
the Controller.
The JXPath elements mirror similar XSLT constructions, except that
instead of operating on an XML document, operate on a Java or
JavaScript object. The JXPath logicsheet has constructs like jpath:if,
jpath:choose, jpath:when, jpath:otherwise, jpath:value-of and
jpath:for-each, which know how to operate on hierarchies of nested Java
objects. Historically the namespace is called "jpath" instead of
"jxpath", we'll probably change it to the latter before the next major
release.
A special instruction, jpath:continuation returns the id of the
continuation that restarts the processing from the last point. It can
actually retrieve ids of earlier continuations, which represent
previous stopped points, but I'm not discussing about this here to keep
things simple.
Going back to the sendPage and sendPageAndContinue functions, there is
a big difference between them. The first function will send the
response back to the client browser, and will stop the processing of
the JavaScript script by saving it into a continuation object. The
other function, sendPageAndContinue will send the response, but it will
not stop the computation. This is useful for example when you need to
exit a top-level JavaScript function invoked with <map:call
function="..."/>.
The above explains how MVC could be really achieved in Cocoon with the
control flow layer. Note that there is no direct communication between
Model and View, everything is directed by the Controller by passing to
View a context object constructed from Model data. In a perfect world,
XSP should have only one logicsheet, the JXPath logicsheet. There
should be no other things in an XSP page that put logic in the page
(read View), instead of the Model. If you don't like XSP, and prefer to
use JSP or Velocity, the JXPath logicsheet equivalents should be
implemented.
Basic usage
===========
As hinted in the previous section, an application using Cocoon's MVC
approach is composed of three layers:
- a JavaScript controller which implements the interaction with the
client
- the business logic model which implements your application
- the XSP pages, which describe the content of the pages, and XSLT
stylesheets which describe the look of the content.
In more complex applications, the flow of pages can be thought of
smaller sequences of pages which are composed together. The natural
analogy is to describe these sequences in separate JavaScript
functions, which can then be called either from the sitemap, can call
each other freely.
An example of such an application is the user login and preferences
sample I've just checked in CVS:
<http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/webapp/samples/flow/
examples/prefs/>
This application is composed of four top-level JavaScript functions:
login(), registerUser(), edit() and logout().
The entry level point in the application can be any of these functions,
but in order for a user to use the application, (s)he must login first.
Once the user logs in, we want to maintain the Java User object which
represents the user between top-level function invocations.
If the script does nothing, each invocation of a top-level function
starts with fresh values for the global variables, no global state is
preserved between top-level function invocations from the sitemap. In
this sample for example, the login() function assigns to the global
variable 'user' the Java User object representing the logged in user.
The edit() function trying to operate on this object would get a null
value instead, because the value is not shared by default between these
top-level function invocations.
To solve the problem, the login() and registerUser() functions have to
call the cocoon.createSession() method, which creates a servlet session
and saves the global scope containing the global variables' value in
it. Next time the user invokes one of the four top-level functions, the
values of the global variables is restored, making sharing very easy.
Even if you don't need complex control flow in your application, you
may still choose to use the MVC pattern described above. You can have
top-level JavaScript functions which obtain the request parameters,
invoke the business logic and then call sendPageAndContinue() to
generate a response page and return from the computation. Since there's
no continuation object being created by this function, and no global
scope being saved, there's no memory resource being eaten. The approach
provides a clean way of separating logic and content, and makes things
easy to follow, since you have to look at a single script to understand
what's going on.
--
This is all I have to say for the moment on this topic.
The thing I'm going to work on next is a user feedback for
documentation which uses this MVC pattern. Jeff Turner and I are
planning to use this system as the documentation system for Anteater.
For this I want to use OJB (http://jakarta.apache.org/ojb/) to map
database tables to Java objects, so I can implement a clean Model
layer. This is a more realistic example, which will hopefully showcase
the ease of use of this MVC approach.
Future plans include writing a WikiWiki application and a Weblog tool
using the same patterns. I think these would be real killer
applications for Cocoon with MVC.
As usually, I appreciate any comments and feedback you have on the
above.
Best regards,
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Ramy Mamdouh <ra...@imkenberg.net>.
Hello
Ovidiu Predescu wrote:
> Hi Ramy,
>
> On Friday, September 6, 2002, at 11:02 AM, Ramy Mamdouh wrote:
>
>> Hello,
>>
>> Being working on a project that uses the Control Flow extensively,
>> made me a big fan of this great piece of software.
>
>
> This is great! Please do let me know if you encounter any problems
> with it.
>
>> However, I have some comments here :
>>
>> 1- sendPage() and the cocoon:/ protocol :
>>
>> As I stated before, why the enforcement of using the "cocoon:/"
>> protocol inside AbstractInterpreter.forwardTo() to make the
>> redirection??
>
>
> Sorry, I forgot about this. Thanks for reminding me about it.
>
>> ---
>> PipelinesNode.getRedirector(environment)
>> .redirect(false, "cocoon:/" + URI);
>> ---
>> This enforces any URI passed to the sendPage() to use the cocoon:/
>> protocol, which doesn't work for some situations.
>> For example, I couldn't use the Portal framework with it as far as I
>> tested.
>> And currently I've changed the above method to make the protocol
>> optional, meaning that the caller to sendPage() specify also the
>> protocol to be used in redirection, I also had to save the
>> continuation ID in session when the cocoon:/ protocol is not used.
>> So, I'm thinking that the sendPage() shouldn't enforce the use of the
>> cocoon:/ protocol, what do you think?
>
>
> Can you please explain in more detail what the problem was with the
> redirection using the cocoon:/ protocol and the Portal framework? I
> don't see where an issue could appear. You almost always want the page
> to be redirected to an internal pipeline.
In general, the problem of the cocoon:/ protocol happens when you
redirect to a complete sub-system (like Portal) where some links and
actions depend on the location of this sub-system (its URI).
I mean the cocoon:/ protocol actually retrieves the content of the
passed URI, and embed that content inside the space of the caller URI,
right?
So, if the sub-system you redirects to expects that, say, "index.html"
is the main URI where form actions and such are passed to, everything in
this sub-system will be broken.
In the portal framework, you define the main portal uri like :
<portal-uri>index</portal-uri>, where this URI contains the portal
generator responsible for getting all the coplets up and running, and
also to *receive* the coplets commands like minimize, etc.
Using the internal protocol with the portal (or any other sub-system
that behaves the same) would break the functionality of that sub-system.
>
>
> Perhaps a better solution is to remove the "cocoon:/" string from the
> AbstractInterpreter.forwardTo() method and put it in the system.js
> sendPage() function, which at least could be redefined. What do you
> think?
That's much better ofcourse, but what about making some overloaded
sendPage() methods, the default one uses the cocoon:/protocol, the other
one accepts a protocol as a parameter, sendPage(uri, prototcol) or
something like that.
One more thing, The storing of the Continuation object. I think
currently, you store it in the Environement.
I think This wouldn't work when redirecting to an external URI (not
using the cocoon:/ I mean), so maybe the other overloaded method would
be responisble for storing the Continuation object in the session.
>
>
>> 2- XSP :
>>
>> On the project I'm working on, we don't use XSP.
>> And so, we don't have any means to get the Continuation ID, thus
>> We've made a simple ContinuationTransformer and ContinuationAction
>> that makes using the Control Flow possible for not XSP based
>> applications.
>
>
> This is nice, would you care to contribute them?
Ofcourse, we gonna send them ASAP.
>
>
>> Finally, Although I consider Cocoon is a really magical thing, I do
>> think that the Flow Control is one of the most exciting stuff I've
>> seen since I knew about web programming.
>
>
> Oh, thank you very much! I'm glad you like the concept, I'll try to
> improve it even more.
>
> Best regards,
--
Ramy Mamdouh Kamel
ramy@imkenberg.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Ovidiu Predescu <ov...@apache.org>.
Hi Ramy,
On Friday, September 6, 2002, at 11:02 AM, Ramy Mamdouh wrote:
> Hello,
>
> Being working on a project that uses the Control Flow extensively,
> made me a big fan of this great piece of software.
This is great! Please do let me know if you encounter any problems with
it.
> However, I have some comments here :
>
> 1- sendPage() and the cocoon:/ protocol :
>
> As I stated before, why the enforcement of using the "cocoon:/"
> protocol inside AbstractInterpreter.forwardTo() to make the
> redirection??
Sorry, I forgot about this. Thanks for reminding me about it.
> ---
> PipelinesNode.getRedirector(environment)
> .redirect(false, "cocoon:/" + URI);
> ---
> This enforces any URI passed to the sendPage() to use the cocoon:/
> protocol, which doesn't work for some situations.
> For example, I couldn't use the Portal framework with it as far as I
> tested.
> And currently I've changed the above method to make the protocol
> optional, meaning that the caller to sendPage() specify also the
> protocol to be used in redirection, I also had to save the
> continuation ID in session when the cocoon:/ protocol is not used.
> So, I'm thinking that the sendPage() shouldn't enforce the use of the
> cocoon:/ protocol, what do you think?
Can you please explain in more detail what the problem was with the
redirection using the cocoon:/ protocol and the Portal framework? I
don't see where an issue could appear. You almost always want the page
to be redirected to an internal pipeline.
Perhaps a better solution is to remove the "cocoon:/" string from the
AbstractInterpreter.forwardTo() method and put it in the system.js
sendPage() function, which at least could be redefined. What do you
think?
> 2- XSP :
>
> On the project I'm working on, we don't use XSP.
> And so, we don't have any means to get the Continuation ID, thus We've
> made a simple ContinuationTransformer and ContinuationAction that
> makes using the Control Flow possible for not XSP based applications.
This is nice, would you care to contribute them?
> Finally, Although I consider Cocoon is a really magical thing, I do
> think that the Flow Control is one of the most exciting stuff I've
> seen since I knew about web programming.
Oh, thank you very much! I'm glad you like the concept, I'll try to
improve it even more.
Best regards,
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Ramy Mamdouh <ra...@imkenberg.net>.
Hello,
Being working on a project that uses the Control Flow extensively, made
me a big fan of this great piece of software.
However, I have some comments here :
1- sendPage() and the cocoon:/ protocol :
As I stated before, why the enforcement of using the "cocoon:/" protocol
inside AbstractInterpreter.forwardTo() to make the redirection??
---
PipelinesNode.getRedirector(environment)
.redirect(false, "cocoon:/" + URI);
---
This enforces any URI passed to the sendPage() to use the cocoon:/
protocol, which doesn't work for some situations.
For example, I couldn't use the Portal framework with it as far as I tested.
And currently I've changed the above method to make the protocol
optional, meaning that the caller to sendPage() specify also the
protocol to be used in redirection, I also had to save the continuation
ID in session when the cocoon:/ protocol is not used.
So, I'm thinking that the sendPage() shouldn't enforce the use of the
cocoon:/ protocol, what do you think?
=======
2- XSP :
On the project I'm working on, we don't use XSP.
And so, we don't have any means to get the Continuation ID, thus We've
made a simple ContinuationTransformer and ContinuationAction that makes
using the Control Flow possible for not XSP based applications.
Finally, Although I consider Cocoon is a really magical thing, I do
think that the Flow Control is one of the most exciting stuff I've seen
since I knew about web programming.
Best Regards.
Ramy Mamdouh Kamel
ramy@imkenberg.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
>Ovidiu Predescu wrote:
>
>[lots of good stuff removed]
>
>
>
>>In a perfect world,
>>XSP should have only one logicsheet, the JXPath logicsheet. There
>>should be no other things in an XSP page that put logic in the page
>>(read View), instead of the Model. If you don't like XSP, and prefer to
>>use JSP or Velocity, the JXPath logicsheet equivalents should be
>>implemented.
>>
>>
>
>I keep having the impression that using Velocity as the view layer will
>be the best choice for a number of reasons. In case you have a few spare
>cycles, please consider investing them there.
>
>
>
>>Basic usage
>>===========
>>
>>As hinted in the previous section, an application using Cocoon's MVC
>>approach is composed of three layers:
>>
>>- a JavaScript controller which implements the interaction with the
>>client
>>
>>- the business logic model which implements your application
>>
>>
>
>One comment on this part: I would remove the 'static' part from
>UserRegistry. I know this is just an example of use, but it would be
>*much* more useful to show a patter of use of the technology that could
>be adopted in other realms and if we suggest to get a hold on java
>objects via getting a static reference, we are simply dooming our users
>to a land of despair and pain later on.
>
>
>
>>- the XSP pages, which describe the content of the pages, and XSLT
>>stylesheets which describe the look of the content.
>>
>>
>
>Question: in the flow layer you are calling 'login.html' and this
>automagically becomes an html page after the execution of the XSP page
>and a XSLT transformation. But where is this set?
>
>This is very important: the concepts of sitemap and flowscripts were
>defined *exactly* to allow somebody to *understand* what's going on
>simply by looking at these central blueprints of your webapp. If
>something is made implicit (like the login.xsp -> login.html resource
>generation) we are totally loosing he concept up front. If a *.html
>matching pipeline is inherited from a sitemap above, the examples should
>make it explicit. Instead, if the XSP -> HTML pipeline has been somewhat
>hardcoded in the flow engine, *PLEASE*, consider removing it alltogether
>in favor of something more explicit.
>
>
>
>>The thing I'm going to work on next is a user feedback for
>>documentation which uses this MVC pattern. Jeff Turner and I are
>>planning to use this system as the documentation system for Anteater.
>>For this I want to use OJB (http://jakarta.apache.org/ojb/) to map
>>database tables to Java objects, so I can implement a clean Model
>>layer. This is a more realistic example, which will hopefully showcase
>>the ease of use of this MVC approach.
>>
>>Future plans include writing a WikiWiki application and a Weblog tool
>>using the same patterns. I think these would be real killer
>>applications for Cocoon with MVC.
>>
>>As usually, I appreciate any comments and feedback you have on the
>>above.
>>
>>
>
>The above is *very* cool and exiting, but I still have a few comments on
>the sitemap-flowscript integration which, IMO, should be solved before
>making a 2.1 release.
>
>
<snip/>
>3) are <map:call> and <map:continue> semantically correct?
>
>I'm not really sure. I personally like them but there is a semantic
>conflict between the use of <map:call> to call a resource but I don't
>think this is so confusing because, in fact, both indicate a jump into
>another point of the webapp.
>
>But if we can have more than one flow, we have to explicitly identify
>which one we want to call.
>
> <map:call flow="prefs" function="login"/>
>
>where it's evident that if the sitemap has only one flowscript declared,
>the call falls implicitly on that one.
>
>I have no problems for <map:continue with="...">: I also think that
>needing to explicitate the continuation-passing URI gives some more
>awareness of the 'magic' behind the thing which might be a steeper
>learning curve for new users, but might result in a more confortable
>plateaux of use later. Which follows Cocoon's style.
>
I thought we kinda agreed on
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102454393731251&w=2,
thing is nobody had enough time to make it reality.
Vadim
>Ok, I'd like to hear your comments before asking for a vote on the
>change of the sitemap markup to accomodate the issues I outlined above.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Stefano Mazzocchi <st...@apache.org>.
Ovidiu Predescu wrote:
> Christopher Oliver sent me a patch for enabling Velocity as the View
> layer. I need to get back to it one of these days. I'll post it on the
> mailing list shortly, maybe somebody else has the time to work on it.
Please do.
> As you say, this is just an example. One could replace the static call
> with anything else, JNDI lookup, Avalon component lookup etc. I don't
> think I'm going to extend this example further. Instead I'll try to
> develop some real applications; right now I'm working on an application
> to collect and display user feedback for online documentation, similar
> to what PHP has. This will have a different way to connect to the
> business logic than the above.
Ok, sounds good.
> >> - the XSP pages, which describe the content of the pages, and XSLT
> >> stylesheets which describe the look of the content.
> >
> > Question: in the flow layer you are calling 'login.html' and this
> > automagically becomes an html page after the execution of the XSP page
> > and a XSLT transformation. But where is this set?
>
> The html transformation is done in the parent sitemap, since it's
> common to all the samples. It's also a bit complex to duplicate on each
> sitemap for every example. Perhaps a note in the sample's sitemap would
> make things clearer.
Yes, most definately.
> > 1) if the flow interpretation is part of the sitemap semantics, don't
> > you think that having a flow interpreter as a component is using the
> > 'overcomponentization' anti-pattern?
> >
> > I think so. The flow interpreter is not a sitemap component, but an
> > avalon component. This means that its declaration should *NOT* reside
> > on
> > <map:components> but somewhere on cocoon.xconf.
> >
> > This makes the user have a stronger perception of integration between
> > the sitemaps (URIs) and the flows (transitions between URIs)
>
> What do you mean? The flow interpreter is an avalon component, it's
> described in cocoon.xconf. Checkout the flow.xconf file, it finds its
> way in cocoon.xconf during the build process.
My point is: since the flow engine is become part of the sitemap
semantics, I think it's wrong to need to specify <flow-interpreter> in
the <components> space.
I think 'flow' should be part of the sitemap just like <components> or
<resources>: something that cannot be removed, a first-class citizen of
the sitemap because it completes it.
> > 2) is the 'flow' really a <map:resource>?
> >
> > I don't think so. A flow is a flow. This calls for a more explicit:
> >
> > <map:flows default-language="javascript">
> > <map:flow name="prefs" src="prefs.js"/>
> > <map:flow name="something-else" src="something.scm"
> > language="scheme"/>
> > </map:flows>
> >
> > which allows:
> >
> > - to declare more scripts (this eases aggregation of different
> > webapps,
> > will be useful for blocks)
> > - to map them to different interpreting engines based on their
> > language.
>
> I remember this being discussed some time ago. I think the ability to
> describe multiple flows in one sitemap is nothing else than FS. A flow
> is usually associated with a complete application. Having multiple
> flows is a complication which may makes things harder to write and
> follow.
That's a good point.
> What I'm instead working on is a simpler setup, like this:
>
> <map:flow language="JavaScript">
> <map:script src="prefs.js"/>
> <map:script src="some-other-script.js"/>
> </map:flow>
>
> The idea here is that we have a Cocoon Web application described in the
> current sitemap, whose flow is described in multiple script files.
> Again, make no mistake, flow in this context is not a simple sequence
> of pages, but it describes the whole application. E.g. a map:flow
> element describes all the scripts that compose the Controller.
I like this approach better, I agree. +1 from me.
> > 3) are <map:call> and <map:continue> semantically correct?
> >
> > I'm not really sure. I personally like them but there is a semantic
> > conflict between the use of <map:call> to call a resource but I don't
> > think this is so confusing because, in fact, both indicate a jump into
> > another point of the webapp.
> >
> > But if we can have more than one flow, we have to explicitly identify
> > which one we want to call.
> >
> > <map:call flow="prefs" function="login"/>
> >
> > where it's evident that if the sitemap has only one flowscript
> > declared,
> > the call falls implicitly on that one.
>
> As I said, I don't think we should have the notion of multiple
> Controllers in the same sitemap. A (sub-)sitemap should define exactly
> one Cocoon Web application. Specifying the flow name as in the above
> <map:call> would make sense only when multiple flow, e.g. Controllers
> are permitted. Which smells too much of FS.
Agreed.
> > I have no problems for <map:continue with="...">: I also think that
> > needing to explicitate the continuation-passing URI gives some more
> > awareness of the 'magic' behind the thing which might be a steeper
> > learning curve for new users, but might result in a more confortable
> > plateaux of use later. Which follows Cocoon's style.
> >
> > Ok, I'd like to hear your comments before asking for a vote on the
> > change of the sitemap markup to accomodate the issues I outlined above.
>
> As Vadim noted in his reply, we already decided on this in
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102454393731251&w=2,
>
> Vadim's proposal at that time still holds, I couldn't think of a better
> alternative. It's simple enough to implement as well, so if anybody has
> some spare time to implement it, would be great.
Ok, I'll try to come up with a summary of the things to do and post them
here for a formal vote (and to show people exactly what is left to do on
this side of things).
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Giacomo Pati <gi...@apache.org>.
On Sun, 8 Sep 2002, Stefano Mazzocchi wrote:
> Per-Olof Norén wrote:
>
> > So the the controller is defined and used as the following?
> >
> > <map:controller language="JavaScript">
> > <map:script src="prefs.js"/>
> > <map:script src="some-other-script.js"/>
> > </map:controller>
> > ....
> > <map:match pattern="calc/*">
> > <map:flow function="calculator" continuation="{1}"/>
> > </map:match>
> >
> > +1 on that. Seems to me the overall usage will be the same.
>
> Call me picky, but I have a few issues with the above.
>
> 1) <map:controller> is clearly MVC-oriented. I find this incoherent with
> the rest of the sitemap semantics. It is true that 'flow' takes the role
> of a 'controller' if we apply the MVC pattern on top of cocoon, but I
> *do*not* think we should marry the MVC pattern that close. Expecially
> because there is no explicit indication of the rest of the pattern's
> concerns (what is a view in Cocoon? that's not an easy answer)
>
> My point is: Cocoon is a framework and uses separation of concerns as
> the main metapattern. Why should we restrict our semantics to only *one*
> of the possible ways of separating concerns (that is: MVC)? Expecially
> when people want to differentiate and call MVC++ or Model2 or Model2+1
> or stuff like that.
>
> My perception is that MVC is a suggestion on how to start, not the end
> of the path. Flow is a much more abstract concept than 'controller' and
> is more coherent with the rest of the sitemap semantics.
>
> My proposal is to change
>
> <map:controller language="JavaScript">
> <map:script src="prefs.js"/>
> <map:script src="some-other-script.js"/>
> </map:controller>
>
> with
>
> <map:flow language="JavaScript">
> <map:script src="prefs.js"/>
> <map:script src="some-other-script.js"/>
> </map:flow>
>
> 2) This means that we have to come up with something different to
> replace <map:flow> inside the pipelines and acts as the connection
> between the pipelines and the flow.
>
> <map:match pattern="calc/*">
> <map:??? function="calculator" continuation="{1}"/>
> </map:match>
>
> Here there is something to note:
>
> a) the tags inside the pipelines indicate an action (generate,
> transform, serialize, match, select, act, read). The question becomes:
> what action is the above unknown tag performs?
>
> Verbosely, the above line is 'passing control to the flow layer'.
> Unfortunately, something like
>
> <map:match pattern="calc/*">
> <map:control function="calculator" continuation="{1}"/>
> </map:match>
>
> would not make the action so self-evident (and will conflict with the
> 'controller' semi-pattern again)
>
> "flow" is useless if used as an action. I would be -1 on its use in this
> context.
>
> "call" might be one of the best choices:
>
> <map:match pattern="calc/*">
> <map:call function="calculator" continuation="{1}"/>
> </map:match>
>
> which is still much different from
>
> <map:match pattern="calc/*">
> <map:call resource="blah"/>
> </map:match>
>
> "delegate-to" is meaningful but it clearly sucks.
>
> Hmmm, anybody with a better alternative?
<map:adapt function="..."/>
<map:work function="..."/>
<map:process function="..."/>
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Stefano Mazzocchi <st...@apache.org>.
Per-Olof Norén wrote:
> So the the controller is defined and used as the following?
>
> <map:controller language="JavaScript">
> <map:script src="prefs.js"/>
> <map:script src="some-other-script.js"/>
> </map:controller>
> ....
> <map:match pattern="calc/*">
> <map:flow function="calculator" continuation="{1}"/>
> </map:match>
>
> +1 on that. Seems to me the overall usage will be the same.
Call me picky, but I have a few issues with the above.
1) <map:controller> is clearly MVC-oriented. I find this incoherent with
the rest of the sitemap semantics. It is true that 'flow' takes the role
of a 'controller' if we apply the MVC pattern on top of cocoon, but I
*do*not* think we should marry the MVC pattern that close. Expecially
because there is no explicit indication of the rest of the pattern's
concerns (what is a view in Cocoon? that's not an easy answer)
My point is: Cocoon is a framework and uses separation of concerns as
the main metapattern. Why should we restrict our semantics to only *one*
of the possible ways of separating concerns (that is: MVC)? Expecially
when people want to differentiate and call MVC++ or Model2 or Model2+1
or stuff like that.
My perception is that MVC is a suggestion on how to start, not the end
of the path. Flow is a much more abstract concept than 'controller' and
is more coherent with the rest of the sitemap semantics.
My proposal is to change
<map:controller language="JavaScript">
<map:script src="prefs.js"/>
<map:script src="some-other-script.js"/>
</map:controller>
with
<map:flow language="JavaScript">
<map:script src="prefs.js"/>
<map:script src="some-other-script.js"/>
</map:flow>
2) This means that we have to come up with something different to
replace <map:flow> inside the pipelines and acts as the connection
between the pipelines and the flow.
<map:match pattern="calc/*">
<map:??? function="calculator" continuation="{1}"/>
</map:match>
Here there is something to note:
a) the tags inside the pipelines indicate an action (generate,
transform, serialize, match, select, act, read). The question becomes:
what action is the above unknown tag performs?
Verbosely, the above line is 'passing control to the flow layer'.
Unfortunately, something like
<map:match pattern="calc/*">
<map:control function="calculator" continuation="{1}"/>
</map:match>
would not make the action so self-evident (and will conflict with the
'controller' semi-pattern again)
"flow" is useless if used as an action. I would be -1 on its use in this
context.
"call" might be one of the best choices:
<map:match pattern="calc/*">
<map:call function="calculator" continuation="{1}"/>
</map:match>
which is still much different from
<map:match pattern="calc/*">
<map:call resource="blah"/>
</map:match>
"delegate-to" is meaningful but it clearly sucks.
Hmmm, anybody with a better alternative?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Per-Olof Norén <pe...@alma.nu>.
Ovidiu Predescu wrote:
> Stefano, Vadim,
>
> On Saturday, September 7, 2002, at 10:09 PM, Ovidiu Predescu wrote:
>
>>> 2) is the 'flow' really a <map:resource>?
>>>
>>> I don't think so. A flow is a flow. This calls for a more explicit:
>>>
>>> <map:flows default-language="javascript">
>>> <map:flow name="prefs" src="prefs.js"/>
>>> <map:flow name="something-else" src="something.scm"
>>> language="scheme"/>
>>> </map:flows>
>>>
>>> which allows:
>>>
>>> - to declare more scripts (this eases aggregation of different webapps,
>>> will be useful for blocks)
>>> - to map them to different interpreting engines based on their
>>> language.
>>
>>
>> I remember this being discussed some time ago. I think the ability to
>> describe multiple flows in one sitemap is nothing else than FS. A flow
>> is usually associated with a complete application. Having multiple
>> flows is a complication which may makes things harder to write and
>> follow.
>>
>> What I'm instead working on is a simpler setup, like this:
>>
>> <map:flow language="JavaScript">
>> <map:script src="prefs.js"/>
>> <map:script src="some-other-script.js"/>
>> </map:flow>
>>
>> The idea here is that we have a Cocoon Web application described in
>> the current sitemap, whose flow is described in multiple script files.
>> Again, make no mistake, flow in this context is not a simple sequence
>> of pages, but it describes the whole application. E.g. a map:flow
>> element describes all the scripts that compose the Controller.
>
>
> Actually I now realize that declaring flow scripts this way, interferes
> with Vadim's proposal on using <map:flow> to invoke a function or
> restart a continuation. Can we find a better name for <map:flow> in this
> context? I was thinking of <map:flow-resources>, but it's a bit too long
> for my taste. As an alternative how about <map:controller>?
So the the controller is defined and used as the following?
<map:controller language="JavaScript">
<map:script src="prefs.js"/>
<map:script src="some-other-script.js"/>
</map:controller>
....
<map:match pattern="calc/*">
<map:flow function="calculator" continuation="{1}"/>
</map:match>
+1 on that. Seems to me the overall usage will be the same.
>
> Again, Vadim's proposal in
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102454393731251&w=2,
>
> is to replace the <map:call function="..."/> and <map:continue
> with="..."/> with a single <map:flow> element, which takes as attributes
> either "function", "continuation" or both. Based on what attributes
> and/or values are present, it functions either as restarting a
> computation stored in a continuation, or calls a new function.
>
> Any thoughts?
>
> Thanks,
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Stefano Mazzocchi <st...@apache.org>.
Ovidiu Predescu wrote:
>
> On Monday, September 9, 2002, at 05:41 AM, Sylvain Wallez wrote:
>
> > Stefano Mazzocchi wrote:
> >
> > <large-snip/>
> >
> >> I know it would be easier *right now* to name it 'controller' and
> >> forget
> >> about all the above, but I ask you to think in 5 years from now, then
> >> place your vote.
> >>
> >> I vote for <map:flow>.
> >>
> >
> > Lots of good arguments, the main one being that continuations have a
> > broader usage range than simply the controller part of MVC. And we can
> > still market <map:flow> as the MVC controller as long it is a > buzzword.
> >
> > So I will abstain on <map:controller> against <map:flow>
> >
> > However, +1 for <map:call> with attributes "resource", "continuation"
> > or "function".
>
> Good, I'm glad we all agree. I'll go ahead and implement <map:flow> as
> declaration and <map:call> with its respective attributes. I like
> <map:call> because is a very simple verb, with a well understood
> meaning.
>
> I'll update later on what is the status and what still remains to be
> done.
Great.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Ovidiu Predescu <ov...@apache.org>.
On Monday, September 9, 2002, at 05:41 AM, Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
> <large-snip/>
>
>> I know it would be easier *right now* to name it 'controller' and
>> forget
>> about all the above, but I ask you to think in 5 years from now, then
>> place your vote.
>>
>> I vote for <map:flow>.
>>
>
> Lots of good arguments, the main one being that continuations have a
> broader usage range than simply the controller part of MVC. And we can
> still market <map:flow> as the MVC controller as long it is a > buzzword.
>
> So I will abstain on <map:controller> against <map:flow>
>
> However, +1 for <map:call> with attributes "resource", "continuation"
> or "function".
Good, I'm glad we all agree. I'll go ahead and implement <map:flow> as
declaration and <map:call> with its respective attributes. I like
<map:call> because is a very simple verb, with a well understood
meaning.
I'll update later on what is the status and what still remains to be
done.
Greetings,
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
<large-snip/>
>I know it would be easier *right now* to name it 'controller' and forget
>about all the above, but I ask you to think in 5 years from now, then
>place your vote.
>
>I vote for <map:flow>.
>
>
Lots of good arguments, the main one being that continuations have a
broader usage range than simply the controller part of MVC. And we can
still market <map:flow> as the MVC controller as long it is a buzzword.
So I will abstain on <map:controller> against <map:flow>
However, +1 for <map:call> with attributes "resource", "continuation" or
"function".
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Stefano Mazzocchi <st...@apache.org>.
Christian Haul wrote:
>
> On 10.Sep.2002 -- 11:19 AM, Stefano Mazzocchi wrote:
>
> > This said, I'm entirely in favor of making it as simple as possible to
> > call actions from the flow layer or viceversa (even if I don't know
> > how). Just understand that in order to have continuations, we need an
> > interpretation layer on top of the JVM. This is a fact. So we can't
> > simply attach continuations to actions and forget about the flow.
>
> (I'm still on the road and will need to read this thread again in more
> detail next week. Damn why are the interesting parts always discussed when
> I'm offline?!)
The murphy law of email discussions :)
> Stefano, you can call your action from flow as simple as
>
> result = act("action-name", { "foo" : value, "bar" : value2 });
>
> and result will contain all the values that would be available
> when this was part of the sitemap
>
> <act type="action-name">
> <map:parameter name="foo" value="{value}"/>
> <map:parameter name="bar" value="{value2}"/>
> <!-- result contains sitemap parameters set by action -->
> </act>
My point was different: Ivelin pointed out several times that, in his
opinion, it's a mistake (or at least, a waste of effort) to have such a
fundamental part of cocoon written using a scripting language.
I noted that in order to have continuations, we needed *something* in
between the flow layer and the JVM, since it doesn't offer
continuations.
This *something* can be either:
- an interpretation layer (as we have today)
- an instrumentation layer (as Brakes) [this could be based on bytecode
rewriting or source code rewriting]
Both have severe performance penalties compared to regularly executed
bytecode, but since the flow layer should not contain any business logic
(where we could suppose the heavy operations reside), I personally think
that the tradeoff between performance and ease of use (due to
continuations) makes the deal interesting.
It is true, that using Brakes, we could instrument the actions bytecode
to be 'continuation-aware', but are we sure we want that?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 10.Sep.2002 -- 11:19 AM, Stefano Mazzocchi wrote:
> This said, I'm entirely in favor of making it as simple as possible to
> call actions from the flow layer or viceversa (even if I don't know
> how). Just understand that in order to have continuations, we need an
> interpretation layer on top of the JVM. This is a fact. So we can't
> simply attach continuations to actions and forget about the flow.
(I'm still on the road and will need to read this thread again in more
detail next week. Damn why are the interesting parts always discussed when
I'm offline?!)
Stefano, you can call your action from flow as simple as
result = act("action-name", { "foo" : value, "bar" : value2 });
and result will contain all the values that would be available
when this was part of the sitemap
<act type="action-name">
<map:parameter name="foo" value="{value}"/>
<map:parameter name="bar" value="{value2}"/>
<!-- result contains sitemap parameters set by action -->
</act>
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Stefano Mazzocchi <st...@apache.org>.
Ivelin Ivanov wrote:
>
> I have been following along the thread silently trying to finally "get" the
> picture.
>
> At this point, the only reasonable question that I can ask is,
> if it is possible to consider providing the continuation capabilities within
> the Actions instead of promoting JavaScript as another language supported by
> Cocoon.
instead? no. I *want* the ability to describe the flow of my application
with a weakly typed and interpreted language.
This said, I would not be against the use of the continuation paradigm
for other parts of Cocoon, if that makes sense. Just remember that
compiled bytecode interpreted directly by the JVM can't have
continuations because java doesn't have that concept (and it's not
possible to add it without patching the JVM, which is not something we
can do).
> My reasoning is that for the size and scalability of the web applications
> that I am dealing with, I wouldn't bet too much on a loosely typed and
> non-compiled language.
These are two different things: it's entirely possible to think to have
a java 'emulation' layer that provides continuations (but I'm sure
performance would be horrible!). That would give you continuations for
your strong-typed code.
Or, we could think of a javascript compilation layer that is capable of
understanding how to save its own state as a continuation (don't ask me
how this could be done, though, I have no idea! hmmm, maybe thru
exception throwing?)
> If provided, however, I may seriously consider using
> a more sophisticated paradigm for flow control within my actions.
For sure, a most sophisticated paradigm for flow control requires some
level of indirection of your action bytecodes. And as far as performance
goes, I'm not sure that having part of the flow interpreted is going to
impact that much on performance. (note that business logic is performed
by java objects and resource creation is still performed by the normal
cocoon pipelines).
It's clear that I consider the flow layer a *much* better alternative to
actions in many senses and the performance impact of the interpretation
layer will have to be tested before using this as an argument.
This said, I'm entirely in favor of making it as simple as possible to
call actions from the flow layer or viceversa (even if I don't know
how). Just understand that in order to have continuations, we need an
interpretation layer on top of the JVM. This is a fact. So we can't
simply attach continuations to actions and forget about the flow.
I'm aware of the feeling that such a 'strange' technology provoques in
people (expecially java people that are used to live in their 100% pure
world), but please, let's try to be a little more flexible than this and
consider this just a try in an innovative direction and let's have the
community of users decide it's fate.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Maciek Kaminski <ma...@tiger.com.pl>.
On 9 Sep 2002 at 21:20, Ivelin Ivanov wrote:
> ...
> At this point, the only reasonable question that I can ask is,
> if it is possible to consider providing the continuation capabilities within
> the Actions instead of promoting JavaScript as another language supported by
> Cocoon.
> ...
I have Interpreter implementation to program flow using Continuation
Passing Style in pure Java. See:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101483194905630&w=2
Maciek Kaminski
maciejka@tiger.com.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Ivelin Ivanov <iv...@apache.org>.
I have been following along the thread silently trying to finally "get" the
picture.
At this point, the only reasonable question that I can ask is,
if it is possible to consider providing the continuation capabilities within
the Actions instead of promoting JavaScript as another language supported by
Cocoon.
My reasoning is that for the size and scalability of the web applications
that I am dealing with, I wouldn't bet too much on a loosely typed and
non-compiled language. If provided, however, I may seriously consider using
a more sophisticated paradigm for flow control within my actions.
I hope to learn more from this thread.
Cheers,
Ivelin
----- Original Message -----
From: "Simon Price" <si...@bristol.ac.uk>
To: <co...@xml.apache.org>
Sent: Monday, September 09, 2002 4:27 PM
Subject: Re: [control flow] changes and new sample
> I'm a newcomer to cocoon, but would be inclined to agree with Stefano
> that flows are more generalised concept than an mvc controller. There
> are ways of using flows that have very little to do with mvc. So,
> assuming anyone can vote on these things :-) +1 for map:flow
>
> Simon
>
> >
> > I vote for <map:flow>.
> >
> >
>
>
> --
>
> -------------------------------------------------------------------
> Simon Price
> Institute for Learning and Research Technology
> University of Bristol
> 8-10 Berkeley Square
> Bristol BS8 1HH
> United Kingdom
>
> Direct: +44 (0)7071 226 720
> Office: +44 (0)117 928 7193
> Fax: +44 (0)117 928 7112
> Simon.Price@bristol.ac.uk
> http://www.ilrt.bristol.ac.uk
>
>
> ---------------------------------------------------------------------
> 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
Re: [control flow] changes and new sample
Posted by Simon Price <si...@bristol.ac.uk>.
I'm a newcomer to cocoon, but would be inclined to agree with Stefano
that flows are more generalised concept than an mvc controller. There
are ways of using flows that have very little to do with mvc. So,
assuming anyone can vote on these things :-) +1 for map:flow
Simon
>
> I vote for <map:flow>.
>
>
--
-------------------------------------------------------------------
Simon Price
Institute for Learning and Research Technology
University of Bristol
8-10 Berkeley Square
Bristol BS8 1HH
United Kingdom
Direct: +44 (0)7071 226 720
Office: +44 (0)117 928 7193
Fax: +44 (0)117 928 7112
Simon.Price@bristol.ac.uk
http://www.ilrt.bristol.ac.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
...
> I know it would be easier *right now* to name it 'controller' and forget
> about all the above, but I ask you to think in 5 years from now, then
> place your vote.
I abstain, since I couldn't care less about the name.
Just that map:flow has *very* low semantics to programmers, while
map:control is much more meaningful.
Controller is something that controls... not necessarily tied to MVC,
although it could be a bonus ATM...
Just my 2 cents, please don't reply.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> c) the flow cannot only work as a controller but can work as a
> procedural way to map any transition-part of a FSM. This includes
> workflows and might include distributed web services.
isn't this a controller in any way?
> I know it would be easier *right now* to name it 'controller' and forget
> about all the above, but I ask you to think in 5 years from now, then
> place your vote.
I am not quite sure if there is really this big difference. Right now I'd go
for controller. Sylvain's example was very straight forward.
> I vote for <map:flow>.
I have a slight preference for controller but not enough to vote against this.
It's more a +0 for <map:controller>
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> I like very much this <map:controller> as it's the name used
> traditionnaly in the MVC pattern. Cocoon shouldn't invent a new word
> (map:flow) to designate a well-known concept. MVC is much hyped and is a
> "magic word" for many customers (see how many of them want Struts
> because it's MVC).
And how many of them will *not* want it in the future when they realize
the MVC pattern was invented for a statefull system and used by
workforces with coherent skills?
Please, people, let's try to have a little more perspective than this.
We should *not* market Cocoon directly, we should think, implement and,
hopefully, doing so, innovate.
My point is: since there is *no* explicit and one2one way to map an MVC
pattern on top of Cocoon, I see no reason why to force the 'flow' of our
application to become a 'controller'.
Think about it and try *not* to think at MVC: which is more abstract as
a concept, a flow or a controller?
You say that attaching a 'controller' label to the flow layer makes it
easier for people to understand and easier for us to market Cocoon. But
if this is true *now*, I wonder if this is going to be true tomorrow
when more and more people realize that Strust is just *a better way to
use JSP*, not a better way to write a web application.
In my view, differentiating between 'flow' and 'controller' is healthy
and possibly important even for marketing:
1) once people realize the concept of continuations, they'll start
seeing MVC as a "poor man" technology invented to make it easier to
write JSP-based applications, but the world doesn't stop at J2EE and
many are already realizing it now (see the anti-EJB riots that are
popping up everywhere). If that happens, how can we differentiate from
that if our flow layer is still called (and perceived as) the
'controller'?
2) flow is a broader concept that includes workflows. It's pretty easy
to imagine a stylesheet that transforms a 'workflow description
language' markup (already existing and many workflow-describing tools
are already exporting it) into a flow script. If we are talking about
marketing, the ability to automatically describe a flow of a web
application using a visual workflow editor is twice as killer as
marketing us as MVC.
3) Cocoon is about separations of concerns. MVC is one way of
separating concerns and was *not* invented for stateless distributed
environments.
4) Marketing should *never* drive an open technology. The need to do
the right thing should be our engine and I think that naming a new
concept with a new term is appropriate because it will become recognized
(think at 'sitemap')
So, to resume, this is my proposal.
<!-- declare the flow of this sitemap -->
<map:flow language="JavaScript">
<map:script src="blah.js"/>
</map:flow>
<!-- hand over resource flow to a script function -->
<map:call function="calc"/>
<!-- continue a the flow with the given continuation -->
<map:call continuation="{1}"/>
<!-- call a resource -->
<map:call resource="my-resource"/>
With this we gain:
a) we can still market Cocoon as MVC (or MVC++, MVC# or whatever) we
just need a document explaining the different ways that Cocoon patterns
can be used to implement the various parts of MVC.
b) when MVC degrades because it shows its limits, we are not tight to
their market because we are more abstract.
c) the flow cannot only work as a controller but can work as a
procedural way to map any transition-part of a FSM. This includes
workflows and might include distributed web services.
I know it would be easier *right now* to name it 'controller' and forget
about all the above, but I ask you to think in 5 years from now, then
place your vote.
I vote for <map:flow>.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Ovidiu Predescu wrote:
>
>> Stefano, Vadim,
...
>> Actually I now realize that declaring flow scripts this way,
>> interferes with Vadim's proposal on using <map:flow> to invoke a
>> function or restart a continuation. Can we find a better name for
>> <map:flow> in this context? I was thinking of <map:flow-resources>,
>> but it's a bit too long for my taste. As an alternative how about
>> <map:controller>?
>
>
>
> I like very much this <map:controller> as it's the name used
> traditionnaly in the MVC pattern. Cocoon shouldn't invent a new word
> (map:flow) to designate a well-known concept. MVC is much hyped and is a
> "magic word" for many customers (see how many of them want Struts
> because it's MVC).
>
> If we choose <map:controller>, then using <map:flow> to call this
> controller doesn't sound well. Something like <map:call-controller>
> sounds better, but you may find it a bit lengthy...
>
> Other thoughts ?
+1 for <map:controller>, and BTW Stefano also hinted on an interview
about the discussion we had about MVC+ ... :-D
I agree with you Sylvain, it's clear for users and "magic word", and
above all I don't see the negative sides.
> <snipped what="single element proposal which I agree with"/>
>
> Sylvain
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ovidiu Predescu wrote:
>
> On Sunday, September 8, 2002, at 01:57 PM, Sylvain Wallez wrote:
>
>> Ovidiu Predescu wrote:
>
<snip/>
>>> Actually I now realize that declaring flow scripts this way,
>>> interferes with Vadim's proposal on using <map:flow> to invoke a
>>> function or restart a continuation. Can we find a better name for
>>> <map:flow> in this context? I was thinking of <map:flow-resources>,
>>> but it's a bit too long for my taste. As an alternative how about
>>> <map:controller>?
>>
>>
>>
>> I like very much this <map:controller> as it's the name used
>> traditionnaly in the MVC pattern. Cocoon shouldn't invent a new word
>> (map:flow) to designate a well-known concept. MVC is much hyped and
>> is a "magic word" for many customers (see how many of them want
>> Struts because it's MVC).
>
>
> Good point, Sylvain! Sticking with known names is going to help us in
> user acceptance as well.
>
>> If we choose <map:controller>, then using <map:flow> to call this
>> controller doesn't sound well. Something like <map:call-controller>
>> sounds better, but you may find it a bit lengthy...
>>
>> Other thoughts ?
>
>
> How about calling it simply <map:call> instead of <map:flow>? This is
> how is called today as well, but we need to modify its semantics to
> support Vadim's proposal, and to get rid of today's <map:continue>.
<map:call> is already used to call resources. One may say that using the
same term for both resources and controller can be confusing, but I
personally think it fully makes sense : "call" means "jump somewhere
else", be it a resource or a controller-directed page.
So, to sum up things, we end up with :
<!-- declare the controller in a sitemap -->
<map:controller language="JavaScript">
<map:script src="blah.js"/>
</map:controller>
<!-- start a controller function -->
<map:call function="calc"/>
<!-- continue a controller function -->
<map:call continuation="{1}"/>
<!-- call a resource -->
<map:call resource="my-resource"/>
This now sounds good and natural. Do you like it ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Ovidiu Predescu <ov...@apache.org>.
On Sunday, September 8, 2002, at 01:57 PM, Sylvain Wallez wrote:
> Ovidiu Predescu wrote:
>
>> Stefano, Vadim,
>>
>> On Saturday, September 7, 2002, at 10:09 PM, Ovidiu Predescu wrote:
>>
>>> I remember this being discussed some time ago. I think the ability
>>> to describe multiple flows in one sitemap is nothing else than FS. A
>>> flow is usually associated with a complete application. Having
>>> multiple flows is a complication which may makes things harder to
>>> write and follow.
>>>
>>> What I'm instead working on is a simpler setup, like this:
>>>
>>> <map:flow language="JavaScript">
>>> <map:script src="prefs.js"/>
>>> <map:script src="some-other-script.js"/>
>>> </map:flow>
>>>
>>> The idea here is that we have a Cocoon Web application described in
>>> the current sitemap, whose flow is described in multiple script
>>> files. Again, make no mistake, flow in this context is not a simple
>>> sequence of pages, but it describes the whole application. E.g. a
>>> map:flow element describes all the scripts that compose the
>>> Controller.
>>
>>
>> Actually I now realize that declaring flow scripts this way,
>> interferes with Vadim's proposal on using <map:flow> to invoke a
>> function or restart a continuation. Can we find a better name for
>> <map:flow> in this context? I was thinking of <map:flow-resources>,
>> but it's a bit too long for my taste. As an alternative how about
>> <map:controller>?
>
>
> I like very much this <map:controller> as it's the name used
> traditionnaly in the MVC pattern. Cocoon shouldn't invent a new word
> (map:flow) to designate a well-known concept. MVC is much hyped and is
> a "magic word" for many customers (see how many of them want Struts
> because it's MVC).
Good point, Sylvain! Sticking with known names is going to help us in
user acceptance as well.
> If we choose <map:controller>, then using <map:flow> to call this
> controller doesn't sound well. Something like <map:call-controller>
> sounds better, but you may find it a bit lengthy...
>
> Other thoughts ?
How about calling it simply <map:call> instead of <map:flow>? This is
how is called today as well, but we need to modify its semantics to
support Vadim's proposal, and to get rid of today's <map:continue>.
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ovidiu Predescu wrote:
> Stefano, Vadim,
>
> On Saturday, September 7, 2002, at 10:09 PM, Ovidiu Predescu wrote:
>
>>> 2) is the 'flow' really a <map:resource>?
>>>
>>> I don't think so. A flow is a flow. This calls for a more explicit:
>>>
>>> <map:flows default-language="javascript">
>>> <map:flow name="prefs" src="prefs.js"/>
>>> <map:flow name="something-else" src="something.scm"
>>> language="scheme"/>
>>> </map:flows>
>>>
>>> which allows:
>>>
>>> - to declare more scripts (this eases aggregation of different
>>> webapps,
>>> will be useful for blocks)
>>> - to map them to different interpreting engines based on their
>>> language.
>>
>>
>> I remember this being discussed some time ago. I think the ability to
>> describe multiple flows in one sitemap is nothing else than FS. A
>> flow is usually associated with a complete application. Having
>> multiple flows is a complication which may makes things harder to
>> write and follow.
>>
>> What I'm instead working on is a simpler setup, like this:
>>
>> <map:flow language="JavaScript">
>> <map:script src="prefs.js"/>
>> <map:script src="some-other-script.js"/>
>> </map:flow>
>>
>> The idea here is that we have a Cocoon Web application described in
>> the current sitemap, whose flow is described in multiple script
>> files. Again, make no mistake, flow in this context is not a simple
>> sequence of pages, but it describes the whole application. E.g. a
>> map:flow element describes all the scripts that compose the Controller.
>
>
> Actually I now realize that declaring flow scripts this way,
> interferes with Vadim's proposal on using <map:flow> to invoke a
> function or restart a continuation. Can we find a better name for
> <map:flow> in this context? I was thinking of <map:flow-resources>,
> but it's a bit too long for my taste. As an alternative how about
> <map:controller>?
I like very much this <map:controller> as it's the name used
traditionnaly in the MVC pattern. Cocoon shouldn't invent a new word
(map:flow) to designate a well-known concept. MVC is much hyped and is a
"magic word" for many customers (see how many of them want Struts
because it's MVC).
If we choose <map:controller>, then using <map:flow> to call this
controller doesn't sound well. Something like <map:call-controller>
sounds better, but you may find it a bit lengthy...
Other thoughts ?
<snipped what="single element proposal which I agree with"/>
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Ovidiu Predescu <ov...@apache.org>.
Stefano, Vadim,
On Saturday, September 7, 2002, at 10:09 PM, Ovidiu Predescu wrote:
>> 2) is the 'flow' really a <map:resource>?
>>
>> I don't think so. A flow is a flow. This calls for a more explicit:
>>
>> <map:flows default-language="javascript">
>> <map:flow name="prefs" src="prefs.js"/>
>> <map:flow name="something-else" src="something.scm"
>> language="scheme"/>
>> </map:flows>
>>
>> which allows:
>>
>> - to declare more scripts (this eases aggregation of different
>> webapps,
>> will be useful for blocks)
>> - to map them to different interpreting engines based on their
>> language.
>
> I remember this being discussed some time ago. I think the ability to
> describe multiple flows in one sitemap is nothing else than FS. A flow
> is usually associated with a complete application. Having multiple
> flows is a complication which may makes things harder to write and
> follow.
>
> What I'm instead working on is a simpler setup, like this:
>
> <map:flow language="JavaScript">
> <map:script src="prefs.js"/>
> <map:script src="some-other-script.js"/>
> </map:flow>
>
> The idea here is that we have a Cocoon Web application described in
> the current sitemap, whose flow is described in multiple script files.
> Again, make no mistake, flow in this context is not a simple sequence
> of pages, but it describes the whole application. E.g. a map:flow
> element describes all the scripts that compose the Controller.
Actually I now realize that declaring flow scripts this way, interferes
with Vadim's proposal on using <map:flow> to invoke a function or
restart a continuation. Can we find a better name for <map:flow> in
this context? I was thinking of <map:flow-resources>, but it's a bit
too long for my taste. As an alternative how about <map:controller>?
Again, Vadim's proposal in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102454393731251&w=2,
is to replace the <map:call function="..."/> and <map:continue
with="..."/> with a single <map:flow> element, which takes as
attributes either "function", "continuation" or both. Based on what
attributes and/or values are present, it functions either as restarting
a computation stored in a continuation, or calls a new function.
Any thoughts?
Thanks,
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Ovidiu Predescu <ov...@apache.org>.
On Saturday, September 7, 2002, at 04:47 AM, Stefano Mazzocchi wrote:
> Ovidiu Predescu wrote:
>
> [lots of good stuff removed]
>
>> In a perfect world,
>> XSP should have only one logicsheet, the JXPath logicsheet. There
>> should be no other things in an XSP page that put logic in the page
>> (read View), instead of the Model. If you don't like XSP, and prefer
>> to
>> use JSP or Velocity, the JXPath logicsheet equivalents should be
>> implemented.
>
> I keep having the impression that using Velocity as the view layer will
> be the best choice for a number of reasons. In case you have a few
> spare
> cycles, please consider investing them there.
Christopher Oliver sent me a patch for enabling Velocity as the View
layer. I need to get back to it one of these days. I'll post it on the
mailing list shortly, maybe somebody else has the time to work on it.
>> Basic usage
>> ===========
>>
>> As hinted in the previous section, an application using Cocoon's MVC
>> approach is composed of three layers:
>>
>> - a JavaScript controller which implements the interaction with the
>> client
>>
>> - the business logic model which implements your application
>
> One comment on this part: I would remove the 'static' part from
> UserRegistry. I know this is just an example of use, but it would be
> *much* more useful to show a patter of use of the technology that could
> be adopted in other realms and if we suggest to get a hold on java
> objects via getting a static reference, we are simply dooming our users
> to a land of despair and pain later on.
As you say, this is just an example. One could replace the static call
with anything else, JNDI lookup, Avalon component lookup etc. I don't
think I'm going to extend this example further. Instead I'll try to
develop some real applications; right now I'm working on an application
to collect and display user feedback for online documentation, similar
to what PHP has. This will have a different way to connect to the
business logic than the above.
>> - the XSP pages, which describe the content of the pages, and XSLT
>> stylesheets which describe the look of the content.
>
> Question: in the flow layer you are calling 'login.html' and this
> automagically becomes an html page after the execution of the XSP page
> and a XSLT transformation. But where is this set?
The html transformation is done in the parent sitemap, since it's
common to all the samples. It's also a bit complex to duplicate on each
sitemap for every example. Perhaps a note in the sample's sitemap would
make things clearer.
> This is very important: the concepts of sitemap and flowscripts were
> defined *exactly* to allow somebody to *understand* what's going on
> simply by looking at these central blueprints of your webapp. If
> something is made implicit (like the login.xsp -> login.html resource
> generation) we are totally loosing he concept up front. If a *.html
> matching pipeline is inherited from a sitemap above, the examples
> should
> make it explicit. Instead, if the XSP -> HTML pipeline has been
> somewhat
> hardcoded in the flow engine, *PLEASE*, consider removing it
> alltogether
> in favor of something more explicit.
As I said above, there's no hardcoding whatsoever. We just need to
place a note in the subsitemap indicating where the html translation
takes place.
>> The thing I'm going to work on next is a user feedback for
>> documentation which uses this MVC pattern. Jeff Turner and I are
>> planning to use this system as the documentation system for Anteater.
>> For this I want to use OJB (http://jakarta.apache.org/ojb/) to map
>> database tables to Java objects, so I can implement a clean Model
>> layer. This is a more realistic example, which will hopefully showcase
>> the ease of use of this MVC approach.
>>
>> Future plans include writing a WikiWiki application and a Weblog tool
>> using the same patterns. I think these would be real killer
>> applications for Cocoon with MVC.
>>
>> As usually, I appreciate any comments and feedback you have on the
>> above.
>
> The above is *very* cool and exiting, but I still have a few comments
> on
> the sitemap-flowscript integration which, IMO, should be solved before
> making a 2.1 release.
>
> 1) if the flow interpretation is part of the sitemap semantics, don't
> you think that having a flow interpreter as a component is using the
> 'overcomponentization' anti-pattern?
>
> I think so. The flow interpreter is not a sitemap component, but an
> avalon component. This means that its declaration should *NOT* reside
> on
> <map:components> but somewhere on cocoon.xconf.
>
> This makes the user have a stronger perception of integration between
> the sitemaps (URIs) and the flows (transitions between URIs)
What do you mean? The flow interpreter is an avalon component, it's
described in cocoon.xconf. Checkout the flow.xconf file, it finds its
way in cocoon.xconf during the build process.
> 2) is the 'flow' really a <map:resource>?
>
> I don't think so. A flow is a flow. This calls for a more explicit:
>
> <map:flows default-language="javascript">
> <map:flow name="prefs" src="prefs.js"/>
> <map:flow name="something-else" src="something.scm"
> language="scheme"/>
> </map:flows>
>
> which allows:
>
> - to declare more scripts (this eases aggregation of different
> webapps,
> will be useful for blocks)
> - to map them to different interpreting engines based on their
> language.
I remember this being discussed some time ago. I think the ability to
describe multiple flows in one sitemap is nothing else than FS. A flow
is usually associated with a complete application. Having multiple
flows is a complication which may makes things harder to write and
follow.
What I'm instead working on is a simpler setup, like this:
<map:flow language="JavaScript">
<map:script src="prefs.js"/>
<map:script src="some-other-script.js"/>
</map:flow>
The idea here is that we have a Cocoon Web application described in the
current sitemap, whose flow is described in multiple script files.
Again, make no mistake, flow in this context is not a simple sequence
of pages, but it describes the whole application. E.g. a map:flow
element describes all the scripts that compose the Controller.
> 3) are <map:call> and <map:continue> semantically correct?
>
> I'm not really sure. I personally like them but there is a semantic
> conflict between the use of <map:call> to call a resource but I don't
> think this is so confusing because, in fact, both indicate a jump into
> another point of the webapp.
>
> But if we can have more than one flow, we have to explicitly identify
> which one we want to call.
>
> <map:call flow="prefs" function="login"/>
>
> where it's evident that if the sitemap has only one flowscript
> declared,
> the call falls implicitly on that one.
As I said, I don't think we should have the notion of multiple
Controllers in the same sitemap. A (sub-)sitemap should define exactly
one Cocoon Web application. Specifying the flow name as in the above
<map:call> would make sense only when multiple flow, e.g. Controllers
are permitted. Which smells too much of FS.
> I have no problems for <map:continue with="...">: I also think that
> needing to explicitate the continuation-passing URI gives some more
> awareness of the 'magic' behind the thing which might be a steeper
> learning curve for new users, but might result in a more confortable
> plateaux of use later. Which follows Cocoon's style.
>
> Ok, I'd like to hear your comments before asking for a vote on the
> change of the sitemap markup to accomodate the issues I outlined above.
As Vadim noted in his reply, we already decided on this in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102454393731251&w=2,
Vadim's proposal at that time still holds, I couldn't think of a better
alternative. It's simple enough to implement as well, so if anybody has
some spare time to implement it, would be great.
Best regards,
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [control flow] changes and new sample
Posted by Stefano Mazzocchi <st...@apache.org>.
Ovidiu Predescu wrote:
[lots of good stuff removed]
> In a perfect world,
> XSP should have only one logicsheet, the JXPath logicsheet. There
> should be no other things in an XSP page that put logic in the page
> (read View), instead of the Model. If you don't like XSP, and prefer to
> use JSP or Velocity, the JXPath logicsheet equivalents should be
> implemented.
I keep having the impression that using Velocity as the view layer will
be the best choice for a number of reasons. In case you have a few spare
cycles, please consider investing them there.
> Basic usage
> ===========
>
> As hinted in the previous section, an application using Cocoon's MVC
> approach is composed of three layers:
>
> - a JavaScript controller which implements the interaction with the
> client
>
> - the business logic model which implements your application
One comment on this part: I would remove the 'static' part from
UserRegistry. I know this is just an example of use, but it would be
*much* more useful to show a patter of use of the technology that could
be adopted in other realms and if we suggest to get a hold on java
objects via getting a static reference, we are simply dooming our users
to a land of despair and pain later on.
> - the XSP pages, which describe the content of the pages, and XSLT
> stylesheets which describe the look of the content.
Question: in the flow layer you are calling 'login.html' and this
automagically becomes an html page after the execution of the XSP page
and a XSLT transformation. But where is this set?
This is very important: the concepts of sitemap and flowscripts were
defined *exactly* to allow somebody to *understand* what's going on
simply by looking at these central blueprints of your webapp. If
something is made implicit (like the login.xsp -> login.html resource
generation) we are totally loosing he concept up front. If a *.html
matching pipeline is inherited from a sitemap above, the examples should
make it explicit. Instead, if the XSP -> HTML pipeline has been somewhat
hardcoded in the flow engine, *PLEASE*, consider removing it alltogether
in favor of something more explicit.
> The thing I'm going to work on next is a user feedback for
> documentation which uses this MVC pattern. Jeff Turner and I are
> planning to use this system as the documentation system for Anteater.
> For this I want to use OJB (http://jakarta.apache.org/ojb/) to map
> database tables to Java objects, so I can implement a clean Model
> layer. This is a more realistic example, which will hopefully showcase
> the ease of use of this MVC approach.
>
> Future plans include writing a WikiWiki application and a Weblog tool
> using the same patterns. I think these would be real killer
> applications for Cocoon with MVC.
>
> As usually, I appreciate any comments and feedback you have on the
> above.
The above is *very* cool and exiting, but I still have a few comments on
the sitemap-flowscript integration which, IMO, should be solved before
making a 2.1 release.
1) if the flow interpretation is part of the sitemap semantics, don't
you think that having a flow interpreter as a component is using the
'overcomponentization' anti-pattern?
I think so. The flow interpreter is not a sitemap component, but an
avalon component. This means that its declaration should *NOT* reside on
<map:components> but somewhere on cocoon.xconf.
This makes the user have a stronger perception of integration between
the sitemaps (URIs) and the flows (transitions between URIs)
2) is the 'flow' really a <map:resource>?
I don't think so. A flow is a flow. This calls for a more explicit:
<map:flows default-language="javascript">
<map:flow name="prefs" src="prefs.js"/>
<map:flow name="something-else" src="something.scm"
language="scheme"/>
</map:flows>
which allows:
- to declare more scripts (this eases aggregation of different webapps,
will be useful for blocks)
- to map them to different interpreting engines based on their
language.
3) are <map:call> and <map:continue> semantically correct?
I'm not really sure. I personally like them but there is a semantic
conflict between the use of <map:call> to call a resource but I don't
think this is so confusing because, in fact, both indicate a jump into
another point of the webapp.
But if we can have more than one flow, we have to explicitly identify
which one we want to call.
<map:call flow="prefs" function="login"/>
where it's evident that if the sitemap has only one flowscript declared,
the call falls implicitly on that one.
I have no problems for <map:continue with="...">: I also think that
needing to explicitate the continuation-passing URI gives some more
awareness of the 'magic' behind the thing which might be a steeper
learning curve for new users, but might result in a more confortable
plateaux of use later. Which follows Cocoon's style.
Ok, I'd like to hear your comments before asking for a vote on the
change of the sitemap markup to accomodate the issues I outlined above.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org