I would like to use ActionManager for implementing captchas. I have a possible interface for actions:
Response execute(Response output) throws ActionException; Response execute(Response output, Object additionalData) throws ActionException; the Response parameter (output) will be the real Response however the execute methods return a Response so they can chained as with FilterOutputStream Sample use case: 1. ActionManager gets Response from container, calls GZIPAction with response. 2. GZIPAction takes OutputStream from Response, seeing gzip is acceptable in Request which is gotten from container, GZIPAction sets encoding to gzip in the Response and constructs a GZIPOutputStream and constructs new Response with it, This Response is returned. 3. ActionManager sees that returned Response is not null, calls next Action in hierarchy which gets web page and puts it to the OutputStream. It passes through the GZIPOutputStream and goes to the ServletOutputStream. This action returns null which signals ActionManager that it is not a filter, and no more Actions need be called. If the GZIPAction sees that gzip is not supported or the configuration disallows compression for the given URL (image), it returns the same response which was given to it. Getting this working will take some effort, but I would like to see the ActionManager running even if chaining of actions is not yet supported and I think this interface will give us what we need to get chaining of Actions working in the future. What do you think? Caleb James DeLisle Caleb James DeLisle wrote: > Everything is very much subject to change but as it stands: > > Asiri Rathnayake wrote: >> Hi Caleb, >> >> If I understand correctly, I would be able to add a new action by >> implementing an "Action" component with this approach (hope I'm correct). > Yes, and you can piggyback off of other actions (to be written) for caching > gzip support and the like. >> - How will I be able to bind my action to a particular URL pattern? (like >> download, view, edit actions we have right now) > As it stands yes, the component "hint" is part of the URL. >> - Is there a way to resolve conflicts when resolving actions? (when two >> action components have bindings to the same URL pattern). > It will behave as with any other collision of components with the same hint. >> I'm not sure if these questions are premature. But let's find out :P >> >> - Asiri >> >> On Tue, Jan 5, 2010 at 12:09 AM, Caleb James DeLisle < >> [email protected]> wrote: >> >>> This has been discussed on IRC but I wanted to send out an email before >>> creating a design proposal and JIRA issue. >>> >>> Summary: >>> Actions need to be ported out of the old core into their own components. >>> It is important that the new Action model be in place so that newly added >>> actions do not have to be ported as well. >>> >>> Current Situation: >>> There is an Action interface, an ActionManager, and an XWikiServlet which >>> work but design is not finished. >>> >>> Use cases: >>> 1. When a browser supports gzip compression, the response should be passed >>> through a discrete gzip Action component. However if the requested material >>> is already compressed (images), it should not be gzip'd. >>> >>> 2. If the user is not logged in and the action they are requesting does not >>> alter the database (Registration) the request should be passed to a cache >>> Action. >>> If the cache contains the desired page then it is returned, otherwise it is >>> passed >>> on to the requested action and when returned it is added to the cache. >>> >>> 3. If desired, a filter Action may catch requests depending on user agent, >>> ip >>> address etc. And reroute the request. Banned! >>> >>> I'd love to hear more use cases, I'll post this to the design proposal page >>> after I go for a walk. >>> >>> Caleb James DeLisle >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
