cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Olsen <>
Subject RE: [C2]Action proposal (long)
Date Tue, 28 Nov 2000 10:46:53 GMT

> -----Original Message-----
> From: Giacomo Pati []
> Sent: Saturday, November 25, 2000 12:09 AM
> To:
> Subject: Re: [C2]Action proposal (long)

> We had several proposals. The first was:

>         <select type="action-selector">
>          <when test="insert">
>           <act type="insert-action"/>
>          </when>
>          <when test="delete">
>           <act type="delete-action"/>
>          </when>
>        ...
>          <otherwise>
>           <act type="unknown-action"/>
>          </otherwise>
>         </select>

> In my oppinion this would eliminate the need for an action-chain but
> wouldn't allow for collecting elegantly returned values from the actions
> in a chain to use in resource specifications in a src attribute for a
> generator like 

I don't think we should eliminate action-chains entirely. As I see it there
2 kinds of action-chains in your original proposal one is the above where
action-chains are used to select a specific action the other are for
stacking actions that are dependant on the sucessfull completion of other
actions (eg "save-form" action depends on "validate-form" below).
   <action-chain name="secure-data-entry">
    <act type="session-validator"/>
    <act type="admin-authorizer"/>
    <act type="validate-form">
     <parameter name="schema" 
    <act type="save-form"/>

I was only against making dbl-semantics for when using the action-chain as
an action selector and not as a stack. I am actually considering changing my
vote (if that is possible :) since I thought of your argument of reduced
verbosity when using action-chains over using action & selector. My reason
for being against dbl-semantic is that I from previous projects have
experienced that to much dbl-semantic actually increase the verbosity
instead of reducing it as was the plan. (Principle of KISS :)

> There has also been a suggestion for handling exception thrown by
> actions as like: 


> In my oppinion this is a selector approach on exceptions, so why not

> 	<act type="secure-data-entry">
> 	  <act type="parse-input-and-make-information-available">
> 	    ...
> 	  </act>
> 	  <select type="action-result">
> 	    <when test="invalid-user">
> 	      <generate src="..."/>
> 	    </when>
> 	    <when test="no-database-connection">
> 	      <generate src="..."/>
> 	    </when>
>           </select>
> 	  ...
> 	</act>

I also made a sugestion for handling errors, on Thu 14 Nov. around 10:52 am,
wich I didn't really get any response to.
Here is the important stuff extracted:

  I sugest that we add a error tag for use inside the "act" tag. This error
  tag is used only when the special error handling is required. Otherwise an
  exception is thrown giving control to the handle-error tag.
  This tag i sugest has 2 ways of usage. Either the tag carries out the
  inclosed commands and breaks or it stores the action type of the action
  failed in one of the environment objects and continues.

  An action-chain like the following:
    <action-chain name="secure-data-entry">
      <act type="session-validator"/>
      <act type="admin-authorizer"/>
      <act type="validate-form">
       <parameter name="schema" 
      <act type="save-form"/>

  Could be called like this with the error-handling
  <act chain="secure-data-entry">
    <error name="admin-authorizer" break>
       <act name="TempFormStorage"/>
       <generate src="login.xml"/>
       <transform type="xslt" src="login.xsl"/>
       <serializer type="html"/>   
    <error name="validate-form" continue/>

  When the error does not stop the normal way through the sitemap access to
  the error is gained using an action/selector pair as shown below.
   <act type="ActionErrorParser">
     <param name="Chain" value="secure-data-entry">
   <select type="ActionErrorSelector"/>
     <when test="validate-form">
       <generate src="retryform.xml"/>

Hope that this small contribution is worthy of being posted to this list ;-)

Best regards

The information in this e-mail message is intended only for the
addressee. Disclosure or use by others is prohibited. Due to the
electronic transmission of the message, no legal rights can be
obtained from the content.

View raw message