dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi Morten

On 28 October 2012 13:18, Morten Olav Hansen <mortenoh@xxxxxxxxx> wrote:
> Hi Bob
>
> This should be as easy as adding another method.. we already have
> getObjectList (I think thats the name.. ) in our ABC. What you will need to
> do, is to add another method in DataSetController, maybe call it
> getDataSetsDSD (or something similar). And have a request-mapping that
> points to both dataSets and dataSets.dsd, this together with the consumed =
> mimetype option, should give you a unique combination (spring mvc will
> complain if two requestmappings point to the same method)

This is all what I figured.  Estimated 2 hours work and 2 days later
:-)  So I have a method in DataSetController with a signature like:

@RequestMapping( value = DataSetController.RESOURCE_PATH + ".dsd",
produces = "application/dsd+xml" )
    public void getStructure( @RequestParam Map<String, String>
parameters, HttpServletResponse response )

Which is I think like you say (other than produces rather than
consumes).  But all I get is the "Aw snap" page with nothing in the
logs whatsoever which makes this really difficult to debug.  (I don't
know if you have any tips for efficient debugging, but currently my
edit-compile-test cycle is also very unfriendly, going into many
minutes).

I *think* (and I feel I am no expert on this), that the getObjectList
in abstract controller is catching ALL get requests to dataSets.  I
had originally thought that providing a more precise match to the
request in the dataSets class would trump the more general match in
the abstract controller (you will recognize xslt as having dominated
my thinking on this matching business).  Anyway it looks like it
doesn't work like this.  If two controller methods are an ambiguous
match, spring seems to just go pop.

Thats ok, but if it is the case, then either we would have to make
specific exclusions to the abstract controller match (which could get
ugly as it is used for much more than datasets), or move back away
from /api/dataSets to something like /api/dsd.

Can you confirm that I am reading this correctly.

Bob



>
> Try it... if its not working, I will try and add it for you
>
> --
> Morten
>
>
>
> On Sat, Oct 27, 2012 at 6:54 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> Hi Morten
>>
>> I am struggling to grasp something (well actually to do something)
>> which I thought would be fairly simple, and probably even is if only I
>> knew how ...
>>
>> It has to do with where you have been clever with the
>> AbstractCrudController in the web api.
>>
>> Something like DataSetController extends this.
>>
>> Currently /api/dataSets returns you the full list of datasets
>> formatted in html.  And using either the extension (.xml or .json) or
>> accept headers we can get xml or json renditions of the same.
>>
>> But I want to return an alternative xml description of the structure
>> of the datasets (lets call it as data structure definition or DSD).
>> Is there any way to map a request which uses either an extension (eg
>> dataSets.dsd) or accept header (eg application/dsd+xml) which DOES NOT
>> get routed through the getObjectList method of AbstractCrudController?
>>
>> Bob
>
>