cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <pati_giac...@yahoo.com>
Subject RE: [C2]Action proposal (long)
Date Thu, 09 Nov 2000 16:22:21 GMT

--- "Timm, Sean" <STimm@mailgo.com> wrote:
> Giacomo Pati [mailto:pati_giacomo@yahoo.com] wrote:
> <snip/>
> > 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:

As I've said in an earlier mail "I'm not good in naming things!". So
any better names are good for me.

> delegator-->delegate
> conveyor-->convey
> relayer-->relay (I don't think relayer is a word).
> processor-->process

Stefano once mentioned somthing like 
   sensor-->sense
> 
> 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.
> 
> <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. The <pipeline> element cannot ensure it is choosen to be the
execution unit for a request. Usually you have some implicit session
management action executed prior to every other action to secure your
app on which you will select the appropriate further components (i.e
sending a "deny" resource to the client).

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

How would you integrate the concept of implicit and expliciy actions
then? Would you mind sticking one single action into an action-chain
(i.e session-management action). I know the example above sucks :)
because some of it is still foggy to me. But this is why I'd like to
discuss it here to come up with a solution to have a "how to use
actions". 

> > 
> >     <!-- 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).  :)

Yes, please! It could help (especially myself) to see how actions may
be used :)

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

Have you read the xdocs/drafts/sitemap-working-draft.xmap? :)

Giacomo


=====
--
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one Place.
http://shopping.yahoo.com/

Mime
View raw message