cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Olsen <...@sanderman.com>
Subject RE: [C2]Action proposal (long)
Date Thu, 09 Nov 2000 11:36:53 GMT


> From: Timm, Sean [mailto:STimm@mailgo.com]
> 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:
> 
> delegator-->delegate
> conveyor-->convey
> relayer-->relay (I don't think relayer is a word).
> processor-->process
> 
> Any other ideas?
I also thing the word action not really incapsulate what it is meant to do.


<snip/>
> > 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.
> 
+1 I like this to. It also underlines the fact that actions are as important
a feature as the matcher.


> >   <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.
It depends on what an action does. Since interaction communication is very
loose (as all intercomponent Communication in Cocooon is) there will rise
the need to make actions that
simply extract data from the environment objects and make them available as
variables in the sitemap. The map returned from the actiondoes this.

<snip/>
> 
> 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).  :)
You are not completely off your rocker, yet ;)
It all depends on how a fail in the chain is handled. I personally would
like to be able to act differently depending on wich action in the chain
failed.
Deny access in case of unauthorized person, but I dont want this to happen
when the user
just made a typeerror.
 


-Disclaimer
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.



Mime
View raw message