Re: Are Actions Redundant in a Flowscript world?

[Stefano Mazzocchi]

Richard In Public wrote:
Hi

I'm trying to get to grips with how the introduction of Flowscript effects
Cocoon best practices.  Some questions (half-baked, I know):
1.  Should CONTROL be handled exclusively by Flowscript?  Looking over the
examples, particularly the 'prefs' one, it seems that the script has two
responsibilities: a) move parameters between VIEW and MODEL and b) change
the VIEW.
No! Control should be (at least!) separated into two realms:

 1) flow control
 2) data control
the first should be handled entirely in the flowscript, the second 
should be handled entirely in java objects.

There is something nice about the flowscript is that using LiveConnect 
is doable but doesn't feel right.

This will be a *major* help to avoid abuse of flow.

For example, look at this pseudocode:

  <map:match pattern="sendPDFReport/*">
   <map:call function="sendPDFEmail">
     <map:parameter name="address" value="{1}"/>
   </map:call>
  </map:match>
  <map:match pattern="report.pdf">
   <map:generate type="stream">
   <map:transform src="report2fo.xslt"/>
   <map:serialize type="fo2pdf"/>
  </map:match>
then the function

  function sendPDFEmail(address) {
      var client = new javax.mail.MailClient("mail.apache.org");
      var output = client.getOutputStream();
      process("report.pdf",{},output);
      sendPage("success", { message : "The message was sent" });
  }
but if you start adding some error checking, you get

  function sendPDFEmail(address) {
      try {
          var client = new javax.mail.MailClient("mail.apache.org");
      } catch (Exception e) {
          sendPage("error", { message : "Couldn't connect to server:" + 
e.getMessage() });
      }

      try {
         var output = client.getOutputStream();
         process("report.pdf",{},output);
         sendPage("success", { message : "The message was sent 
correctly"});
      } catch (Exception e) {
         sendPage("error", { message : "There was an error: " + 
e.getMessage();
      }
  }

and as you start adding more and more control on your flow, it's pretty 
hard to completely isolate things.

But LiveConnect is your friend.

LiveConnect is what is called when you do

 new java.io.FileOutputStream()

which is, in fact, syntax sugar for

 new Packages.java.io.FileOutputStream()

WARNING: this shortcut works only for java. and javax. packages. doing 
something like

 new org.apache.cocoon.Blah()

will result in an error.

So, i think that since nobody likes to write full package names, people 
will start considering moving java code out of the flowscript as much as 
they can.

So, how do you do this?

Here are the possible alternatives:

 1) avalon components

 2) actions

 3) input modules

 4) output modules

 5) EJB

 6) your own objects

the problem is that, as we stand today, it's not as brain-dead to plug 
your own avalon components to cocoon. Blocks and more modern containers 
will allow that to happen.

in the meanwhile, the flow *ALREADY* contains a bunch of facilities for 
calling data-oriented sitemap components, for example:

// Action Support
//
// call an action from JS
function act(type, src, param);
// InputModule Support
//
// obtain value form InputModule
function inputValue(type, name);
// OutputModule Support
//
// set an attribute (starts transaction, commit or rollback required!)
function outputSet(type, name, value);
// makes attributes permanent (ends transaction)
function outputCommit(type);
// deletes attributes (ends transaction)
function outputRollback(type);