Details
-
Bug
-
Status: Closed
-
Should
-
Resolution: Fixed
-
None
-
None
-
Low
Description
This appears to be a case of dueling designs. The CustomRepresentation object appears to be based on a specification which describes the representation and is processed inside the CustomRepresentation; this processing was never written. The custom representation is invoked by ?v=custom:<specification>. The NamedRepresentation object appears to be based on a new representation which is coded in the resource in the same way a standard representation would be. There is no way to invoke a named representation.
I hijacked the code for custom to use it to involke named by adding the following after line 48 in RestServiceImpl.getRepresentation:
} else if (requested.startsWith(RestConstants.REPRESENTATION_CUSTOM_PREFIX)) { return new NamedRepresentation(requested.replace(RestConstants.REPRESENTATION_CUSTOM_PREFIX, ""));
I then added the following code to LocationResource.getRepresentationDescription after line 100:
else if (rep instanceof NamedRepresentation) { NamedRepresentation nrep = (NamedRepresentation) rep; if (nrep.getRepresentation().equals("TATER")) { DelegatingResourceDescription description = new DelegatingResourceDescription(); description.addProperty("uuid"); description.addProperty("display", findMethod("getDisplayString")); description.addProperty("tags", Representation.DEFAULT); description.addProperty("parentLocation", Representation.FULL); description.addProperty("childLocations", Representation.REF); description.addSelfLink(); return description; } }
I then invoked the named representation by doing a get to a location with ?v=custom:TATER. It worked as expected.
I suggest that this be fixed by creating a new prefix "named:" which would enable the creation of named representations as above and leave the "custom:" prefix available for a run-time-specified representation description such as contemplated by the design.