Thank you Mathieu! Yeah, I forgot the site-conf.xsd, now I reverted it in rev. 1835043.
-----邮件原件----- 发件人: Mathieu Lirzin [mailto:[email protected]] 发送时间: 2018年7月4日 0:06 收件人: [email protected] 主题: Add ‘method’ attribute to ‘request-map’ elements Hello, Following revert of rev 1834917, I want to “properly” propose adding a ‘method’ attribute to ‘request-map’ elements. I am currently working on adding REST based Web APIs to OFBiz [1]. In order to do that, it is important for the HTTP controller to handle various HTTP methods differently, meaning allowing a different request handler to be called depending on the method of the HTTP request. Syntactically I am proposing the following: <request-map uri="examples" method="get"> <security https="true" auth="true"/> <event type="java" path="ExamplesHandlers" invoke="getExamples"/> <response name="success" type="view" value="..."/> <response name="error" type="view" value="..."/> </request-map> <request-map uri="examples" method="post"> <security https="true" auth="true"/> <event type="java" path="ExamplesHandlers" invoke="postExamples"/> <response name="success" type="view" value="..."/> <response name="error" type="view" value="..."/> </request-map> Here ‘method’ is an optional attribute which defaults to "all" and/or "". Currently the patch supports both but I would be in favour of handling only one for the sake of simplicity. The semantic of that default is that it mimics the current behavior, meaning it handles every methods. Attached you will find a serie of 3 patches (meant to be applied in order) implementing the described change: - The first one handles the parsing of the XML (the change in the xsd file has not been reverted). - The second is a simple refactoring to agglomerate the read of the XML file in one place. This is done to ease the implementation and tests in the third patch. - The third patch implements the segregation of ‘request-map’ elements based on the actual request method. In order to associate a request to an event handler we now need to dispatch both on the URI and on the method. To achieve that, I have decided to keep using the URI as a key but associate it to a List of ‘request-map’ (one for each method) instead of a single one. In term of implementation a ‘MultivaluedMap’ has been used. The list of candidates for a particular URI is then filtered to keep only the best matching one. The ‘request-map’ Map concrete type was a MapContext which is a stack of Maps (to handle includes), The ‘MultivaluedMapContext’ implementation is an adaptation of MapContext to MultivaluedMaps. Since ‘ControllerConfig::getRequestMapMap’ is used at multiple places I have kept it temporarily and replaced its code with an adapter to the new ‘ControllerConfig::getRequestMapMultiMap’ method.
