olingo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sklev...@apache.org
Subject svn commit: r1530640 - /incubator/olingo/site/trunk/content/doc/tutorials/read_media-resource.mdtext
Date Wed, 09 Oct 2013 14:41:58 GMT
Author: sklevenz
Date: Wed Oct  9 14:41:57 2013
New Revision: 1530640

URL: http://svn.apache.org/r1530640
Log:
CMS commit to olingo by sklevenz

Modified:
    incubator/olingo/site/trunk/content/doc/tutorials/read_media-resource.mdtext

Modified: incubator/olingo/site/trunk/content/doc/tutorials/read_media-resource.mdtext
URL: http://svn.apache.org/viewvc/incubator/olingo/site/trunk/content/doc/tutorials/read_media-resource.mdtext?rev=1530640&r1=1530639&r2=1530640&view=diff
==============================================================================
--- incubator/olingo/site/trunk/content/doc/tutorials/read_media-resource.mdtext (original)
+++ incubator/olingo/site/trunk/content/doc/tutorials/read_media-resource.mdtext Wed Oct 
9 14:41:57 2013
@@ -68,7 +68,7 @@ Additional and in conclusion with the `D
 To really get an image for a media resource request it is necessary to copy these images
(or create own PNG files which follows the naming schema).
 If nothing is copied/created the sample will still work but does not show an image for a
media resource request (instead a HTTP Response 404 - Entity not found is shown). 
 
-** Extend MyEdmProvider with Driver data model **
+** Extend MyEdmProvider with Driver data model **<br>
 
 First the new Driver is added in the EDM. 
 The Driver gets a Key (Id) and some properties (Name, Surname, Nickname, Updates. For simplification
currently we do not add any associations to another entities.
@@ -123,7 +123,7 @@ And at last following constants are adde
       static final String ENTITY_NAME_DRIVER = "Driver";
       private static final FullQualifiedName ENTITY_TYPE_1_3 = new FullQualifiedName(NAMESPACE,
ENTITY_NAME_DRIVER);
 
-**Extend `MyODataSingleProcessor` with `readEntityMedia(uriInfo:GetMediaResourceUriInfo,
contentType:String):ODataResponse` method**
+**Extend `MyODataSingleProcessor` with `readEntityMedia(uriInfo:GetMediaResourceUriInfo,
contentType:String):ODataResponse` method**<br>
 All requests for media resources are done via the specified $value property in the URL (e.g.
*.../MyODataSample.svc/Drivers(1)/$value*). Such a request will be dispatched to an `EntityMediaProcessor`
which is in our case the `MyODataSingleProcessor` (inherited from `ODataSingleProcessor`).
 To handle now such read requests for our media resources we override and implement the `readEntityMedia(uriInfo:GetMediaResourceUriInfo,
contentType:String):ODataResponse` method.
 For our scenario we simply have to validate the correct requested target `EntitySet`, get
the key for requesting the data from our `DataStore` (which contains the binary data of our
media resource), use the `EntityProvider` to write the data and at last build the `ODataResponse`.
@@ -151,7 +151,7 @@ Seems a lot but in code this are only th
 
 With these extension it is possible to read the media resource, but for access to the Driver
`EntitySet` and `Entity` the according read methods have to be extended.
 
-** Extend existing `readEntitySet(...)` and `readEntity(...)` methods in `MyODataSingleProcessor`
methods **
+** Extend existing `readEntitySet(...)` and `readEntity(...)` methods in `MyODataSingleProcessor`
methods **<br>
 For access to the Driver as `Entity` and as `EntitySet` the according `readreadEntitySet(...)`
and `readEntity(...)` methods have to be extended.
 
 But its quite the same procedure as in the basic read. Validate the requested Entity, get
the key for requesting the `DataStore` and write the result data via the `EntityProvider`.
@@ -175,15 +175,15 @@ and `readEntitySet(…)`:
         return EntityProvider.writeFeed(contentType, entitySet, dataStore.getDrivers(), 
   EntityProviderWriteProperties.serviceRoot(getContext().getPathInfo().getServiceRoot()).build());
 
 
-**Conclusion for media resource extension**
+**Conclusion for media resource extension**<br>
 After finishing all steps above the project can be built and deployed containing a Driver
type which is a media link entry with associated media resource. *Congratulations.*
 
 For a more interesting sample and to update before learned knowledge about associations and
`$expand` it is recommended to finish this HowTo with the creation of an association between
a Driver and his Car with supported `$expand`.
 
-**Extend Driver with association to Car**
+**Extend Driver with association to Car**<br>
 For a more interesting sample we now create an association between a Driver and his Car.
 
-**Extend Driver and Car in MyEdmProvider with a navigation property**
+**Extend Driver and Car in MyEdmProvider with a navigation property**<br>
 At first we introduce the necessary constants:
 
     :::java
@@ -263,7 +263,7 @@ At last the `getAssociation(…)` and
     }
 
 
-**Extend existing `readreadEntitySet(...)` and `readEntity(...)` methods in `MyODataSingleProcessor`**
+**Extend existing `readreadEntitySet(...)` and `readEntity(...)` methods in `MyODataSingleProcessor`**<br>
 For cleaner code we introduce at first following method in the `MyODataSingleProcessor` which
validate if the uri contains the expected association.
 
     :::java
@@ -305,10 +305,10 @@ The procedure should be already familiar
       throw new ODataNotFoundException(ODataNotFoundException.ENTITY);
     }
 
-**Add $expand support for Driver to/from Car association**
+**Add $expand support for Driver to/from Car association**<br>
 The last missing step is to add the `$expand` support for the new Driver to/from Car association.
 
-**Extend MyCallback for Driver and Car association**
+**Extend MyCallback for Driver and Car association**<br>
 Add first the extension in the MyCallback for each entity is done in the `retrieveEntryResult()`
method.
 The procedure is similar to the Cars - Manufacturers association. At first it is checked
for the correct association of the requested Entity, then the key for requesting the DataStore
is get as well as the data and then result data is attached to the `WriteEntryCallbackResult`.
 
@@ -338,7 +338,7 @@ The resulting method extension is:
       }
     ...
 
-**Add registration of MyCallback for Driver and Car association**
+**Add registration of MyCallback for Driver and Car association**<br>
 After extension of `MyCallback` it is necessary to register a callback within the `readEntity()`
in the `MyODataSingleProcessor`.
 
 For the Driver we add the complete callback registration (code between the comments) which
results in final code for the complete Driver Entity handling:



Mime
View raw message