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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
