Hi,
I'm trying to figure out what the handler url is in the handler class or to be more precise add is added to the handler url. When I add a handler I create a mapping, for example:
/ping --> PingWebHandler
If I use IWebRequest:PathInfo then the /ping part is included as well. But I'm interested in what is *added* to /ping, since within the Handler I cannot make any assumptions about what the "mount point" is.
thanks.
Well, not entirely. I'm trying to make a generic WebHandler which can mounted to any handler url. So /ping can be /foo or /foor/bar or whatever. Let's say I want to create a RestWebHandler. Inside the webhandler I want to be able to program something for /customer of /order of /customer/order. But since I have only the IWebRequest:PathInfo I don't know upfront if the RestWebHandler is mounted with /rest or /rest/web or /foor/bar. Imho, the handler url part shouldn't be in the PathInfo property (or there should another property).
There is a default web handler in the mapping file. Change that to be your class and all requests will come to your web handler. I am not sure if you will need to edit the mapping file or if you can do that through PDSOE.
Thanks
Shelley
So to clarify a bit more, inside the webhandler I want program something like:
case requestPath:
when "/customer" then ...
when "/order" then ...
otherwise ...
end case.
Now, how do I get requestPath? The only info I have is (afaik) PathInfo, but this includes the handler url part as well. What do I do if I don't want to force anyone to use a specific handler url?
Here's the deal. I make the following call:
<hostname>:10000/app1/web/ping/bla/bla2?test=hoppa
WebAppPath: /app1
TransportPath: /web
PathInfo: /ping/bla/bla2
This last one because I said the /ping is handled by my PingWebHandler class. But I can say that /foo is handled by my PingWebHandler as well. In that case the PathInfo would be /foo/bla/bla2. To make things generic I'm not interesting in either the /ping of /foo part (this can be anything since it's a configuration thing), but in the /bla/bla2 part.
edit: rewrote the URL because a link was made out of it.
In such cases where different URL's goes to same method, I generally use this code
poRequest:URI:TOSTRING () matches "*<stringname*"
based on the condition, I call a method that would do appropriate action by passing the poRequest to that method
That would be a solution, albeit an error prone one.
I think it would have been better solution if there was another property (in IWebRequest) called HandlerUrl en that the HandlerUrl part was *not* in PathInfo. A bit like express in node.js works. This way it would have been much easier to make generic code.
This last one because I said the /ping is handled by my PingWebHandler class. But I can say that /foo is handled by my PingWebHandler as well. In that case the PathInfo would be /foo/bla/bla2. To make things generic I'm not interesting in either the /ping of /foo part (this can be anything since it's a configuration thing), but in the /bla/bla2 part.
Thanks Peter, I will submit an enhancement request.
Answer to the original question: it is possible via workarounds, but not generically (yet). At least one workaround below in this thread.
EDIT: Mike Banks came up with the solution for my question. Above statement is no longer true.
Yes! This is exactly what I'm looking for!
request:GetContextValue("URI_FINAL_MATCH_GROUP") is the correct answer. Thanks.
is this documented anywhere?
I'm afraid it may not be documented.
When a request is matched by the URI template in openedge.properties, the URI_FINAL_MATCH_GROUP contains the remaining parts of the URI that were not explicitly matched.
IMHO: the contents of URI_FINAL_MATCH_GROUP deserve a place in a) the documentation and b) IWebRequest.
What I noticed the in the PathParameterNames is name of URI_FINAL_MATCH_GROUP appears as URI_FINAL_MATCH_GROUPFINAL_MATCH_GROUP, for which I logged an issue with techsupport. In ContextNames the name correctly is URI_FINAL_MATCH_GROUP. Speaking of which, what is the difference between PathParameterNames and ContextNames? They appear to be the same (apart from URI_FINAL_MATCH_GROUP).
You should be able to get the path parameter without the URI prefix. For example, GetPathParameter( "custnum" ) instead of GetContextValue( "URI_CUSTNUM" ). The difference is that the path parameter names should be as defined in the URI template and the ones in the context have a URI prefix to set them apart from other context values.