The situation is actually even a little more complicated...
I would have sworn before that you could include a query string when you
called ActionMapping.findForward(), but you cannot... after the fact I
remembered that you have to play some games with adding it to the path
on the returned forward.
So, the code needs to be altered to even allow that in the first place.
I haven't yet verified whether you can have an anchor and a query
string, although I suspect you can. I'm toying with this stuff right now...
Frank
Frank W. Zammetti wrote:
Laurie Harper wrote:
The only thing that occurs to me is: are anchors guaranteed to be at
the end of the URL? I.e. is this valid:
http://.../myAction.do#anchor?query=...
That's a good point, I don't know the answer off the top of my head...
have to do some looking around...
Come to think of it, it may not make any difference; is the 'name'
argument to findForward pre-processed to strip request parameters?
Nope, wouldn't appear to be... findForward() in ActionMapping calls
findForwardConfig() in ActionConfig, and that simply does a get() on the
forwards collection (a HashMap). So, at least that part of it isn't a
problem.
The first question is interesting though... I'd be willing to bet you
can have parameters after an anchor (or maybe the other way around, not
sure)... lemme see what I can dig up, unless anyone reading this knows
for sure?
Wouldn't be a big hassle to deal with it if it is possible.
Frank
L.
Frank W. Zammetti wrote:
Moved to the dev list, I think it's more appropriate there now...
Hmm... interesting... seems like there might be more than one related
issue here.
Trying to tackle just the issue of being able to do in an Action:
mapping.findForward("myForward#myAnchor");
I can't seem to check out from SVN from my current location, so I can't
test any of this... here's what I *think* could be done to allow this
though...
(1) In ActionMapping, change the findForward() method to this:
public ActionForward findForward(String name) {
String anchor = "";
int hashLoc = name.indexOf("#");
if (name != null && hashLoc != -1) {
anchor = name.substring(hashLoc, name.length());
name = name.substring(0, hashLoc);
}
ForwardConfig config = findForwardConfig(name);
if (config == null) {
config = getModuleConfig().findForwardConfig(name);
}
if (config == null) {
if (log.isWarnEnabled()) {
log.warn("Unable to find '" + name + "' forward.");
}
}
ActionForward af = null;
if (config != null) {
ActionForward af = new ActionForward((ActionForward)config);
if (name != null}{
af.setAnchor(anchor);
}
}
return af;
}
(2) In RequestProcessor, right before the line:
if (forward.getRedirect()) {
... in the processForwardConfig() method, add:
uri += ((ActionForward)forward).getAnchor();
(3) In ActionForward, add the following:
private String anchor;
public void setAnchor(String anchor) {
this.anchor = anchor;
}
public String getAnchor() {
return this.anchor;
}
Quick explanation:
In ActionMapping.findForward(), we check if there is a hash mark in the
requested forward name. If there is we grab everything to the right of
it, which is the named anchor, and we set the name to everything to the
left of it, which is the forward name. The forward should then be found
correctly.
Then, we essentially make a clone of the ForwardConfig we found so
that we
can call setAnchor() on it without affecting anything outside the
current
request (ForwardConfigs are shared and generally immutable after
creation).
Lastly, in RequestProcessor, we tack the anchor on to the URI before
forwarding or redirecting. If there was no anchor, no harm is done.
Can anyone check me on this? Does it look reasonable? If anyone could
even test-compile, that'd be fantastic, otherwise I'll do it when I get
home and have access. I'll submit the patch tonight unless anyone
sees an
insurmountable problem that I've missed.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
