4 Jan
2010
4 Jan
'10
7:39 p.m.
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
5 Jan
5 Jan
5:22 a.m.
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).
- How will I be able to bind my action to a particular URL pattern? (like
download, view, edit actions we have right now)
- Is there a way to resolve conflicts when resolving actions? (when two
action components have bindings to the same URL pattern).
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 <
calebdelisle(a)lavabit.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:36 a.m.
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 <
calebdelisle(a)lavabit.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10 Jan
10 Jan
10:18 a.m.
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 <
calebdelisle(a)lavabit.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5363
days inactive
5369
days old
3 comments
2 participants
participants (2)
-
Asiri Rathnayake -
Caleb James DeLisle