cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timm, Sean" <>
Subject RE: [C2]Action proposal (long)
Date Thu, 09 Nov 2000 00:28:27 GMT
Giacomo Pati [] wrote:
> Question: Is it suitable to implement some semantic directly into 
> the sitemap to select the right action out of an action-chain 
> because usually only one action gets posted by a client and 
> executed out of a set of explicit actions? Example:
> 	<action-chain name="database-manipulation>
> 	 <act type="insert-action" action="insert"/>
> 	 <act type="delete-action" action="delete"/>
> 	 ...
> 	</action-chain>
> The posted action is selected according to the action attribute and 
> by a TBD mechanism for the sitemap to aquire the posted action.

+1...I like this way better because it clearly delineates the action chain
as a major Cocoon feature (that I'm very happy to have, I might add...)  I
would like to see the "action" attribute changed to "name", but I also don't
like the "action" name.  It doesn't fit with all of the other component
names we have going.  An action doesn't act.  An actor does.  Of course,
actor doesn't make sense in this context, so I feel like we should use a
different word.  I tried coming up with some words, but I wasn't completely
happy with any of them...they are as follows:

relayer-->relay (I don't think relayer is a word).

Any other ideas?

> Another way could be to do "team play" between a Selector and an 
> Action as it is done with other components (i.e. selecting the
> stylesheet according to the user agent header:
> 	<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>
> This way we don't need to add semantics to the sitemap itself and 
> we can put it into a resource instead of a action-chain to achieve 
> the same verbosity reduction if we need to use the same fragment 
> from several places. This construct will obsolete the need for 
> action-chains.

Yuck (personal opinion)...I prefer adding the new semantics.

> And in the pipeline section we write
>  <pipeline>

I'd like the ability to assign an action-chain (or whatever we call it) to a
pipeline so that it occurs for all requests no matter what.  That way, you
can secure an entire site just by assigning an action-chain responsible for
security checks to the pipeline.

>   <match type="uri" pattern="myapp/**">
>    <!-- this action will parse the cookies/post/get data
>         and process them according to the specified
>         actions in the action-chain. Results of the actions
>         are set as state information in the environment 
>         objects (Request/Response/Context/Session)
>    -->
>    <act chain="secure-data-entry/">
>    <!-- this action will examine the result of the previous 
>         action and make this available by returning resource 
>         specifications in a Map which is referrable as {issue}
>    -->
>    <act type="parse-input-and-make-information-available">

Hmm...any reason why we can't just enforce that you can only specify
action-chains?  Actions only seem important (to me) in the context of a
chain of events.

>     <!-- this selector will choose among the information
>          made available in the environment objects by the previous
>          Action.
>     -->
>     <select type="action-result-checker">
>      <when test="show-index">
>       <!-- this generator is charged with the appropriate index
>            resource returned by the Action above.
>       -->
>       <generate src="myapp/{issue}/index"/>
>      </when>
>      <when test="kill-task">
>       <!-- this action kills a task that was initiated
>            previously by another action using data made
>            available by the Action above.
>       -->
>       <act type="task-killer"/>
>       <generate src="myapp/{theme}/task-killing-status-page"/>
>      </when>
>      <otherwise>
>       <generate src="myapp/deny"/>
>      </otherwise>
>     </select>
>    </act>

If you can only specify action-chains, then this information would obviously
reside within the specified action-chain.  I'd like to see only
action-chains specified, and anything you place with the action-chain node
within the pipeline would occur only if the chain had been completely run
through.  Anything outside of the action-chain node would occur no matter
what.  Am I making sense?  I can throw together an example if anyone would
like...(unless I'm completely off my rocker).  :)

Another issue that this just brought to mind...if all of the above were
contained within an action-chain, how could I access the regular expression
stuff from the original match tag (ie. "myapp/{1}" or whatever...).  How do
resources do this (or can they)?  If they can't, this makes specifying
things within an action-chain or a resource much less inviting.

>    <transform src="myapp/general.xsl"/>
>    <serialize type="html"/>
>   </match>
>   <handle-error>
>    <transform src="myapp/error-transformer.xsl"/>
>    <transform src="myapp/general.xsl"/>
>    <serialize type="html"/>
>   </handle-error>
>  </pipeline>
> We are aware of the verbosity of the sitemap we will introduce.
> To reduce that we have already implemented what we call mounting of
> sub sitemaps. This will arrange sitemaps (and thus the URI space
> Cocoon controls) in a hierachical structure.

Do we have any examples of this?  I haven't educated myself on how that all
works yet...

- Sean T.

View raw message