struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Struts Wiki] Update of "StrutsTi/ActionMappings" by DonBrown
Date Wed, 31 Aug 2005 05:11:09 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.

The following page has been changed by DonBrown:
http://wiki.apache.org/struts/StrutsTi/ActionMappings

The comment on the change is:
Adding action mappings discussion

New page:
#format wiki
#language en
Action mappings is a feature that will benefit greatly from a rewrite and inclusion of other
capabilities.  By !ActionMappings, I mean code that extracts from a URI the following:
 * The namespace (xwork) or module prefix (struts)
 * The action name
 * Any extra parameters

While the first two are obvious, the last isn't necessarily.  This is a feature that is currently
in development for the next version of WebWork2.  For WW2, [https://xwork.dev.java.net/source/browse/webwork/src/java/com/opensymphony/webwork/dispatcher/mapper/
ActionMapper] is an interface which allows implementations to extract the above information.
 One particular implementation, [https://xwork.dev.java.net/source/browse/webwork/src/java/com/opensymphony/webwork/dispatcher/mapper/CoolActionMapper.java?rev=1.1&view=markup
CoolActionMapper] provides greater ReST-style support by allowing parameters to be embedded
into the URL, so the framework could support the pattern:
{{{
http://HOST/ACTION_NAME/PARAM_VALUE1/PARAM_NAME2/PARAM_VALUE2
}}}
to allow url's like:
{{{
http://HOST/article/ID
}}}

There are a couple of reasons why I'd suggest copying the code rather than using it unmodified:
 1. It is tied to the servlet API and I've been trying hard to not require the core to know
about servlets
 1. It assumes one servlet mapping, and I believe we need to support multiple.  As for this
writing, the mappings can be retrieved from the !WebContext
 1. Related to above, ours would need to know about the mappings in order to recreate a URI
from and action, namespace, and servlet mapping

Implementation points:
 * Do we follow WW2 and use an !ActionMapping interface or just embed the information directly
into the web context?
 * If we create an interface, we'd have to add a "mapping" property to store the optional
servlet mapping
 * I'd assume we'd pass in a !WebContext rather than a servlet request
 * How do we integrate any extracted parameters into the !WebContext?  The request parameters
map is read-only yet we want smooth integration of the parameters to the rest of the app and
it seems cumbersome to require every piece of code to check in two places for parameters.

Design goals:
 * Again, shouldn't require servlet, although implementations certainly will
 * Support for multiple servlet mappings

==== Comment by rich on Thu Jul  7 22:59:42 2005 ====
Having this capability sounds great to me.

It does raise a general question: should we try to influence/contribute to other projects
in order to fulfill our needs?  e.g., is this something that could be abstracted and pushed
into xwork?

Some questions/comments:

 1. Why do we need to support multiple servlet mappings?
 1. I like the idea of wrapping up action information into an !ActionMapping, since it seems
like there could end up being a lot there that could get lost in the shuffle of the general
context.  Also, maybe there will be different types of !ActionMappings?  It would still hang
off the context (getActionInfo()?).
 1. Assuming we have an extension of !WebContext, can't we have this combine the underlying
parameter map with the params from the !ActionMapper?


==== Comment by mrdon on Fri Jul  8 09:17:27 2005 ====
Good point, and to that end, I've invited Jason and Patrick from WebWork/XWork to join the
discussion.  They are very interested in working together to develop solutions that meet both
our needs.  While our projects will remain separate, I'm hoping we can use common infrastructure
and ideas wherever possible.

 1. One usecase that I've run across is trying to have both an HTML and ReST interface for
the same app.  The HTML interface is fine with *.do, but the ReST is cleaner with /rest/*
 If we allowed multiple instances of Ti, I could just use two servlets, but combining them
into one lets me share data easier and takes less memory.
 1. Sure, what different types do you have in mind?
 1. Yes, and this is what WebWork2 does when it creates the !ActionContext.  Of course by
extension you mean a whole other class as we couldn't directly extend !WebContext w/o extending
all possible subclasses (servlet, faces, portlet, etc).

==== Comment by rich on Fri Jul  8 13:58:28 2005 ====
That's excellent.  The more of an integration project this is, the better, as far as I'm concerned.

 1. I see.  Mainly to support both path-mapping and extension-mapping.  I know that from a
tooling point of view, it would be much easier if we defined one extension and one path prefix.
 Is there a compelling reason to offer more flexibility than that?
 1. In Beehive there are two types of action mappings: simple actions and method-based actions.
 Simple actions either map directly to a path, or go through a script expression evaluator
to go through a set of conditions/results.  Basically, the shape of metadata is different
for the two types of actions.  Just making sure -- the !ActionMapping is still the way you'd
access an action's metadata at runtime?
 1. Oh, right.  I was talking about extending !WebContext and wrapping the underlying one,
but that's not pretty since !ServletWebContext, etc. expose properties you'd be interested
in.  I assume we should extend !ActionContext and expose !WebContext as a property, along
with our other context properties.  Sound correct?  An alternative would be to leave !WebContext
out of the !ActionContext, and ensure that our single context had everything you need... but
this would cause it to reimplement much of what Chain did.

==== Comment by mrdon on Sun Jul 10 19:14:47 2005 ====
 1. I don't mind if we suggest one prefix/extension mapping, but I'd like the internal framework
to be capable of more.  The code I just committed allows multiple servlet mappings - source:src/java/org/apache/ti/config/mapper/ServletActionMapper.java
 1. Well, !ActionMapping in this context is different than Struts 1.x.  In this case, all
an !ActionMapping does is capture and action name and namespace.  XWork's [http://www.opensymphony.com/xwork/api/com/opensymphony/xwork/config/entities/ActionConfig.html
ActionConfig] is like the !ActionConfig of Struts 1.x  As for two types of action mappings,
I was kinda hoping to just go to one type, i.e. Ruby on Rails.  If we can keep annotation/tag
overhead low, even simple actions could be a controller method.
 1. I was thinking about some sort of !ControllerContext would would use ActionContext's threadlocal
instance as storage, so it'd provide getters then try to pull them out of ActionContext's
map.

==== Comment by plightbo on Sun Jul 10 20:15:43 2005 ====
Hey guys -- Patrick Lightbody here. Just joining in on the conversation. One thing to keep
in mind is weighing between tool support and supporting flexible URLs. At this point, our
plans in WebWork are up in the air. Pasted below is a discussion I had with Don over email
about this:

------------------------------
Speaking of the ActionMapper -- I'm not done with it by any means and very open to feedback.
One of the challenges I have is not mapping from "request" -> action,  but rather action
-> "request" (url).

For example, suppose you have a form that lets you edit a person. In a RESTful design, that
would be a PUT to /people/1. Or, with the "cool" mapper, it would be a POST to /person/1`,
where 1 is the person ID. But suppose the form has a drop down form element that is a selection
of "persons" you can edit (say, it is a combobox and the textfield becomes the name of the
person). Now the <form> element needs to submit to a dynamic location (/person/1, /person/2,
etc).

Even when the URL is not dynamic, mapping a form (in WW it is <ww:form>) is not so easy.
Using a *.action extension mapping, this:
{{{
<ww:form action="updatePerson">
 <ww:hidden name="id"/>
 <ww:textfield label="Email address" name="email"/>
 ...
</ww:form>
}}}
produces this HTML (or close to it):
{{{
<form name="updatePerson" action="updatePerson.action">
<table>
 <input type="hidden" name="id" value="123"/>
 <tr>
  <td>Email address</td>
  <td><input name="email" value="plightbo@gmail.com"/>
 </tr>
 ...
</table>
</form>
}}}
So in this situation, mapping the action name ("updatePerson") to the URL ("updatePerson.action")
is very easy. But in the cool or restful way, the ActionMapper would have to know the parameters
of the form ("id" -> "123") and construct a proper HTML output:
{{{
<form name="updatePerson" action="/person/123">
<table>
 <tr>
  <td>Email address</td>
  <td><input name="email" value="plightbo@gmail.com"/>
 </tr>
 ...
</table>
</form>
}}}
---------------------------------


==== Comment by rich on Mon Jul 11 09:41:59 2005 ====
Response to Don:
 1. Sounds good -- it's easy for the runtime to be aware of multiple mappings.
 1. Having one config is OK, but I don't think we should sacrifice wholly-annotation-based
actions.  I'm all for low overhead, but we did go through a round of every-action-is-a-method
in Beehive, and it's just a pain.  Even if there were no annotations on an action method,
it's still just cleaner to do this:
 {{{@ti.simpleAction(name="begin")}}}
 1. Definitely -- sounds good.

==== Comment by rich on Mon Jul 11 09:49:46 2005 ====
Patrick/Don, I've got a basic question: what's the main case for generating HTML that accesses
actions RESTfully?  I can imagine exposing actions/flow in this way for a back-channel !XmlHttpRequest
(which doesn't have some of the form issues Patrick is raising, and which is what I'd imagine
as the main use initially), but I don't see how it would be helpful on the other side.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message