Are Actions Redundant in a Flowscript world?

[Richard In Public <ed...@blueyonder.co.uk>]

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.

2.  If this is the case, then I am left wondering about ACTIONS: would one
still want to use, for example, database actions in the sitemap, rather than
calling a persistence layer from within the flowscript?

3.  What principles should I use to determine what is best handled in the
Sitemap?  For example, the 'prefs' sitemap uses controls the invocation of
Flowscript functions.  But the Flowscript itself could just as easily handle
this functionality, which seems to be CONTROL anyway.

Regards,

Richard Hoberman

Re: Are Actions Redundant in a Flowscript world?

[Stefano Mazzocchi <st...@apache.org>]

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

Re: Are Actions Redundant in a Flowscript world?

[Stefano Mazzocchi <st...@apache.org>]

Tony Collen wrote:
> On Fri, 4 Apr 2003, Richard In Public wrote:
> 
> 
>>2.  If this is the case, then I am left wondering about ACTIONS: would one
>>still want to use, for example, database actions in the sitemap, rather than
>>calling a persistence layer from within the flowscript?
> 
> 
> 
> Funny, I was just contemplating accessing a database from the Flow, but
> I'm not sure if it's not implemented for a reason, or what.  Any
> suggestions would be helpful.

Chris implemented database connection directly into the flow object 
model in the scratchpad. checkout the petstore example.

I personally think that adding more stuff to the flow object model is 
dangerous, since javascript doesn't really shine on its object 
orientation (compared to java, anyway) as it doesn't have direct 
polymorphism. (you have to use the *.prototype object which is not as 
easy to use and can be abused a lot).

I would suggest to reuse more and more the tons of components that 
cocoon already has. actions, input and output modules, for example, or 
even a collection of generally useful avalon components.

for example user storage, database store, and so on. Avalon already 
includes a bunch of them to be used in phoenix.

But first of all we should release 2.1 and make the flow available for 
people to work with it.

*then* we will have enough first-hand information on how is best to move on.

-- 
Stefano.

Re: Are Actions Redundant in a Flowscript world?

[Tony Collen <tc...@neuagency.com>]

On Fri, 4 Apr 2003, Richard In Public wrote:

> 2.  If this is the case, then I am left wondering about ACTIONS: would one
> still want to use, for example, database actions in the sitemap, rather than
> calling a persistence layer from within the flowscript?


Funny, I was just contemplating accessing a database from the Flow, but
I'm not sure if it's not implemented for a reason, or what.  Any
suggestions would be helpful.

Tony

--
Tony Collen
ICQ: 12410567
--
Cocoon: Internet Glue (A Cocoon Weblog)
http://manero.org/weblog/
--