Martin Cooper wrote:
>>-----Original Message-----
>>From: Eddie Bush [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, September 23, 2002 2:19 PM
>>To: Struts Developers List
>>Subject: Re: [sub-app] Default Module
>>
>>
>>Aha! ... because the action paths are /name - and that just gets
>>slapped on the end of the path!
>>
>>Bah - I get it now <emote:smackHead/> It goes
>>http://<host:port><prefix><action>
>>
>>Ok ... so there's actually a lot of utility there. How's the
>>rest of my
>>reasoning about selecting applications? My mail is being kind of odd
>>today and I don't see several messages showing up that I sent... not
>>just to this list - sorry for anything that seems odd :-)
>>
>>Why do we even need to lookup the prefix? That seems error-prone, at
>>best. Yeah, ok, maybe we should check to be sure that what
>>we arrive at
>>for a prefix is valid, and ... throw an exception if it
>>isn't. I think
>>we should select the application differently. What I would
>>like to do is:
>>
>> - get the index of "/" (beyond the first one)
>> - if it's not there, this is the default sub-application
>> - if it's there, get the substring from the initial
>>"/" - up to,
>>but excluding, the final "/"
>> - lookup this substring in the prefix array (exact match)
>> - if it is present, we choose that sub-application
>> - if it is not present, we assume the default
>>sub-application or throw an exception
>>
>>This way, we always default to the ... default ...
>>sub-application. So,
>>if someone had a "/" in the querystring (for whatever
>>reason), we would
>>fail to find a match with our declared prefixes. The default
>>sub-application would be selected. Say we manage to get a
>>match - that
>>sub-application would be selected. Also, we have just (greatly)
>>increased the namespace for possible sub-applications -
>>compared to what
>>it is right now.
>>
>I think what you're missing here is that it is perfectly valid for the path
>*within* a module to contain more than one '/' character. In other words, I
>can define an action path like "/foo/bar", relative to my module "/baz" so
>that the context-relative URL is "/baz/foo/bar.do". If I understand you
>correctly, your algorithm would derive a module name of "/baz/foo" from this
>URL, fail to find the corresponding module, and then either throw an
>exception or pass the request to the default module.
>
Actually, I subitted a patch on this already (so did Steve). What it
does is look for multiple "/" chars in "matchPath". If they are not
present, we're obviously in the default module, so I do nothing to
"matchPath". If, however, there are multiple "/" characters in
"matchPath", I take everything from the first one - up to the second one
- and reset "matchPath" to that newly arrived at value. This should
always be able to be matched exactly to a module name.
Steve's idea is good - and I can see where folks might want to do it ---
but your having stated that a path within a module could have yet
another level (yet another slash) in it ... Am I wrong about that making
it difficult to determine with any easy solution which module we're in
with Steve's approach? It seems you'd have to make multiple passes
using different pieces of your original "matchPath".
So you'd have to do something like:
if there is more than one "/"
loop
get the substring from "/" to just before the last "/" and
assign to matchPath
try to lookup the module (loop through prefixes)
if module is found
assign prefix to be the prefix at this index
break
setup the module in the request (by calling overloaded
selectApplication; include prefix)
... no, that's not quite it. I think it may be possible to build
something intelligent to do that. Is this a good approach though?
Obviously I need to work the default module in somewhere. I suppose a
person could throw on:
else
assign prefix of "" (you can determine accurately that you are
definitely in the default module if there is only one "/" in matchPath
to start off with)
That would cinche it up.
>If you extend this to incorporate Steve D's idea of more than one '/'
>character in a module prefix, then we can end up with a URL of
>'/baz/sna/foo/bar.do", where '/baz/sna' is the module, and '/foo/bar' is the
>action path. This is why we need to walk through the defined prefixes to
>determine which one should be applied.
>
Yes. I see your point. So you're saying that allowing multi-leveled
sub-apps would be ok. I don't like the possible complications when it
comes to thinking about module inheritance though - but, then, I don't
suppose that functionality even has a slot on the TODO list ;-) I
really think it should though. If I get a chance I man get off my duff
and submit some patches for it.
>--
>Martin Cooper
>
>>How does that sound? If I should throw an exception, rather than
>>default to the ... I don't like saying default for the
>>sub-app name ...
>>rather than selecting the default sub-app, what would it be? An
>>unavailable exception wouldn't be appropriate at this point, I don't
>>think. Am I wrong? I'm open to suggestions :-) Does this
>>sound like
>>something you'd accept a patch for?
>>
--
Eddie Bush
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
