cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [C2]Action proposal (long)
Date Thu, 09 Nov 2000 23:33:45 GMT
At 12:36  9/11/00 +0100, you wrote:
>> 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.

I am curious what you think is lacking.  I guess I come from a GUI
background and see the ACtion pattern used in a lot of web based projects
as well (all turbine based ones + some of the jsp taglibs ones at Apache).
Is there a particular aspect that you don't think it covers ?

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


Yup this is already doable by "implicit" actions. You can think of implicit
action chains as one built up out of the resource requested. So if you
request myapp/part1/admin/form.xml and myapp/ has a session validator
action, myapp/* has an authentication validator action, myapp/*/admin has a
admin-role validator action and finally myapp/part1/admin/form.xml has a
form validation action then the final chain would be

1. session validator action
2. authentication validator action
3. admin-role validator action
4. form validation action


Sidenote: Anyone who hasn't had a look at hyperqbs @
http://www.hyperqbs.org really should. They have a lot of great ideas on
actions (ie action circuits) that is great for building reusable caction
components.


Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*

Mime
View raw message