> -----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.
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.
--
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?
>
> Martin Cooper wrote:
>
> >The empty prefix for the default module is the source of backwards
> >compatibility with Struts 1.0 apps. If you take a 1.0 app
> and drop it into
> >1.1, it "just works" because it becomes the default module,
> with no defined
> >prefix.
> >
> >Again, assuming you're working on the hierarchical thing,
> what I did (for a
> >variety of reasons) was have a (very small) number of
> special cases, in my
> >code that overrides Struts code, where it maps from empty prefix to
> >"common". Then the rest of my code doesn't have to care much
> about whether
> >or not there's really a prefix.
> >
> >--
> >Martin Cooper
> >
>
> --
> Eddie Bush
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
