You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@olingo.apache.org by mi...@apache.org on 2015/07/22 14:34:09 UTC

svn commit: r1692263 - /olingo/site/trunk/content/doc/odata4/tutorials/navigation/tutorial_navigation.mdtext

Author: mibo
Date: Wed Jul 22 12:34:09 2015
New Revision: 1692263

URL: http://svn.apache.org/r1692263
Log:
Prepared navigation tutorial for release

Modified:
    olingo/site/trunk/content/doc/odata4/tutorials/navigation/tutorial_navigation.mdtext

Modified: olingo/site/trunk/content/doc/odata4/tutorials/navigation/tutorial_navigation.mdtext
URL: http://svn.apache.org/viewvc/olingo/site/trunk/content/doc/odata4/tutorials/navigation/tutorial_navigation.mdtext?rev=1692263&r1=1692262&r2=1692263&view=diff
==============================================================================
--- olingo/site/trunk/content/doc/odata4/tutorials/navigation/tutorial_navigation.mdtext (original)
+++ olingo/site/trunk/content/doc/odata4/tutorials/navigation/tutorial_navigation.mdtext Wed Jul 22 12:34:09 2015
@@ -22,9 +22,21 @@ Notice:    Licensed to the Apache Softwa
 
 ## Introduction
 
-In the present tutorial, we’ll learn how to implement navigation between 2 Entity Types in an OData V4 service.
+In the present tutorial, we will learn how to implement navigation between 2 Entity Types in an OData V4 service.
+
+**Note**  
+
+The full implementation of the OData service as described in the present tutorial can be found in the [attached zip file](http://www.apache.org/dyn/closer.cgi/olingo/odata4/Tutorials/DemoService_Tutorial_Navigation.zip) ([md5](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_Navigation.zip.md5), [sha512](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_Navigation.zip.sha512), [pgp](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_Navigation.zip.asc)) that contains an Eclipse project that can be imported into your Eclipse workspace.
+
+
+**Disclaimer**  
+
+Again, in the present tutorial, we will focus only on the relevant implementation, in order to keep the code small and simple.
+The sample code shouldn’t be reused for advanced scenarios.
+
+
+**Background**  
 
-**Background**
 Say, we have an electronics shop and we have a lot of products which we’re selling and these products can be notebooks or monitors or organizers, which are the categories.
 We would have 3 requirements:
 
@@ -34,39 +46,32 @@ We would have 3 requirements:
   3. We want to navigate from a category to its products and perform a READ operation on one of them.
 
 **Example for navigating in a service**
+
 We open the Categories collection: <http://localhost:8080/DemoService/DemoService.svc/Categories>
 
 ![CategoryCollection](browser_categories.JPG "The Category collection")
 
 We open the details of the first Category, the “Notebooks”-category:
-http://localhost:8080/DemoService/DemoService.svc/Categories(1)
+<http://localhost:8080/DemoService/DemoService.svc/Categories(1)>
 
 ![CategoryEntity](browser_categories1.jpg "Read single Category entity")
 
 In order to display all products that are notebooks, we can navigate from the selected category to its products:
-http://localhost:8080/DemoService/DemoService.svc/Categories(1)/Products
+<http://localhost:8080/DemoService/DemoService.svc/Categories(1)/Products>
 
 ![ProductsOfCategory](browser_categories1_products.jpg "After navigating from a  Category to the related Products")
 
 In the above example we’ve executed a one-to-many navigation.
 
 As mentioned in the Background section, it is also required to navigate from a selected product to its category, which is a to-one relation, like:
-http://localhost:8080/DemoService/DemoService.svc/Products(1)/Category
+<http://localhost:8080/DemoService/DemoService.svc/Products(1)/Category>
 
 And finally, it is possible to navigate to a list of products and directly access one of them, e.g.
-http://localhost:8080/DemoService/DemoService.svc/Categories(1)/Products(1)
+<http://localhost:8080/DemoService/DemoService.svc/Categories(1)/Products(1)>
 
 All three cases are covered by the present tutorial.
 
 
-**Note**
-The full implementation of the OData service as described in the present tutorial can be found in the attached zip file that contains an Eclipse project that can be imported into your Eclipse workspace.
-
-**Disclaimer**
-Again, in the present tutorial, we’ll focus only on the relevant implementation, in order to keep the code small and simple.
-The sample code shouldn’t be reused for advanced scenarios.
-
-
 **Table of Contents**
 
   1. Prerequisites
@@ -82,23 +87,22 @@ The sample code shouldn’t be reused
   7. Appendix: code snippets
 
 
-___
+---
 
 # 1. Prerequisites
 
-Same prerequisites as in [Tutorial Part 1: Read Entity Collection](http://olingo.apache.org/doc/odata4/tutorials/read/tutorial_read.html)
- and [Tutorial Part 2: Read Entity](http://olingo.apache.org/doc/odata4/tutorials/readep/tutorial_readep.html) as well as basic knowledge about the concepts presented in both tutorials.
+Same prerequisites as in [Tutorial Part 1: Read Entity Collection](/doc/odata4/tutorials/read/tutorial_read.html) and [Tutorial Part 2: Read Entity](/doc/odata4/tutorials/readep/tutorial_readep.html) as well as basic knowledge about the concepts presented in both tutorials.
 
-___
+---
 
 # 2. Preparation
 
-Follow Tutorial Part 1: Read Entity Collection and Tutorial Part 2: Read Entity or as shortcut import the project attached to Tutorial Part 2 into your Eclipse workspace.
+Follow [Tutorial Part 1: Read Entity Collection](/doc/odata4/tutorials/read/tutorial_read.html) and [Tutorial Part 2: Read Entity](/doc/odata4/tutorials/readep/tutorial_readep.html) or as shortcut import the [project attached to Tutorial Part 2](http://www.apache.org/dyn/closer.cgi/olingo/odata4/Tutorials/DemoService_Tutorial_ReadEp.zip) ([md5](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_ReadEp.zip.md5), [sha512](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_ReadEp.zip.sha512), [pgp](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_ReadEp.zip.asc)) into your Eclipse workspace (.
 
 Afterwards do a Deploy and run: it should be working.
 
 
-___
+---
 
 
 # 3. Implementing the navigation
@@ -120,7 +124,7 @@ That way, we can keep the entity types l
 
 ## 3.1. Declare the metadata
 
-In order to declare the metadata of our OData service, we open the class _myservice.mynamespace.service.DemoEdmProvider_
+In order to declare the metadata of our OData service, we open the class myservice.mynamespace.service.DemoEdmProvider_
 
 ### 3.1.1. Extend the Entity Type “Product”
 
@@ -179,7 +183,7 @@ In our example, the metadata of our â€
      </EntityType>
 
 
-Implementation-wise we have to create and configure an object of type _CsdlNavigationProperty_:
+Implementation-wise we have to create and configure an object of type `CsdlNavigationProperty`:
 
     :::java
     CsdlNavigationProperty navProp = new CsdlNavigationProperty()
@@ -202,8 +206,8 @@ That list becomes relevant for the entit
 
 There’s one more step to consider with respect to the navigation: the entity set.
 At runtime, we need to know how to implement the navigation, when an entity set is invoked.
-For this purpose, the OData specifies the _NavigationPropertyBinding_ element, which is a child element of the entity set and should be defined for each navigation property.
-That _NavigationPropertyBinding_ has the following attributes:
+For this purpose, the OData specifies the `NavigationPropertyBinding` element, which is a child element of the entity set and should be defined for each navigation property.
+That `NavigationPropertyBinding` has the following attributes:
 
 **Path**
 Here we specify the name of the corresponding navigation property.
@@ -211,7 +215,7 @@ In our example, the navigation property
 
 **Target**
 Here we specify the entity set where we’re navigating to.
-In our example it is the entity set “Categories” (which we’ll create below)
+In our example it is the entity set “Categories” (which we will create below)
 
 In our example, the definition of our “Products” entity set looks as follows:
 
@@ -301,7 +305,7 @@ The code for the “Category” en
     }
 
 
-The _NavigationPropertyBinding_ element and its attributes for the entity set “Categories”:
+The `NavigationPropertyBinding` element and its attributes for the entity set “Categories”:
 
 **Path**
 In our example, the navigation property that we’ve defined above is named “Products”
@@ -317,7 +321,7 @@ In our example, the definition of our â
       <NavigationPropertyBinding Path="Products" Target="Products"/>
     </EntitySet>
 
-And the implementation in the _getEntitySet_ method:
+And the implementation in the `getEntitySet` method:
 
     :::java
     CsdlNavigationPropertyBinding navPropBinding = new CsdlNavigationPropertyBinding();
@@ -346,7 +350,7 @@ So the user has to check the metadata do
 This means, that he can append the navigation property name to his URL, which takes him to the set of “Products” that belong to the chosen “Category”: <http://localhost:8080/DemoService/DemoService.svc/Categories(1)/Products>
 
 From the metadata we can see that the “Type” attribute defines a collection.
-This means that the implementation has to be done in the _EntityCollectionProcessor_, since we have to provide a collection of entities.
+This means that the implementation has to be done in the `EntityCollectionProcessor`, since we have to provide a collection of entities.
 
 Open the class `myservice.mynamespace.service.DemoEntityCollectionProcessor.java`
 
@@ -359,7 +363,7 @@ We don’t support navigation from on
 For example:
 Categories(1)/Products(1)/Category
 
-Based on this assumption, in our _EntityCollectionProcessor_, we can rely on the fact that the URI can have either one or two segments.
+Based on this assumption, in our `EntityCollectionProcessor`, we can rely on the fact that the URI can have either one or two segments.
 This means: we can be called for the following kind of URLs:
 
 Example URL for one sement: <http://localhost:8080/DemoService/DemoService.svc/Categories>
@@ -403,7 +407,7 @@ Our tasks are:
   1. depending on the chosen key of the first segment, we have to compute which and how many entities exactly have to be returned. With other words, find the right data in the backend
   e.g. for the category “monitors”, we have to find the right products that are monitors
   2. find out, which entity set has to be returned (can be products, categories, etc)
-  This _EdmEntitySet_ is required in order to properly build the context URL
+  This `EdmEntitySet` is required in order to properly build the context URL
 
 The following sections explain how to do that.
 
@@ -418,17 +422,18 @@ in our example, we have to perform a rea
 **B)** get the data for the navigation
 in our example, we have to find the products that are monitors.
 
-With respect to data, remember that we're using sample data that we create in our Storage class which represents our kind of database-mock.
+With respect to data, remember that we're using sample data that we create in our `Storage` class which represents our kind of database-mock.  
 On startup of our service, we initialize some sample products and categories.
 During initialization, there’s no assignment of products to its categories.
-In our sample code, we’re doing this when requested in a hard-coded method in our _Storage_ class.
+In our sample code, we’re doing this when requested in a hard-coded method in our `Storage` class.
 
 
 **A) get the data for the first URI segment**
 
 In our example, the URL would be: <http://localhost:8080/DemoService/DemoService.svc/Categories(3)/Products>
-For this example, we would have to retrieve the Category with ID=3
-The code looks like a normal READ operation:
+
+For this example, we would have to retrieve the Category with *ID=3*.  
+The code looks like a normal `READ` operation:
 
     :::java
     List<UriParameter> keyPredicates = uriResourceEntitySet.getKeyPredicates();
@@ -439,7 +444,7 @@ In our example, the result is an entity
 
 **B) get the data for the navigation**
 
-Now we have to follow the navigation, based on the retrieved entity.
+Now we have to follow the navigation, based on the retrieved entity.  
 In our example, we have to retrieve all products that are monitors.
 
 This is backend logic, so we can directly call a helper method in our Storage class:
@@ -448,13 +453,13 @@ This is backend logic, so we can directl
     responseEntityCollection = storage.getRelatedEntityCollection(sourceEntity, targetEntityType);
 
 This helper method requires the source entity and returns the target collection.
-Additionally, the method needs the _EdmEntityType_ that corresponds to the requested target.
+Additionally, the method needs the `EdmEntityType` that corresponds to the requested target.
 In our example, we pass the “Category” (i.e. "Monitors") as source entity and the navigation target entity type, which is “Product”.
 As a result, we get the desired “Products” collection, all products that are monitors.
 
 After this step, we’re almost done, because we have the entity collection that our OData service returns in the response body.
 We only need to do some more hand work: the response entity collection has to be serialized and the serializer which is in charge of doing that has to be configured properly.
-For that we need the _EdmEntitySet_ that corresponds to the response.
+For that we need the `EdmEntitySet` that corresponds to the response.
 Since it is different in case of navigation and non-navigation, we still need to retrieve it for the case of navigation.
 
 
@@ -462,7 +467,7 @@ Since it is different in case of navigat
 
 First, we have to analyze the URI, and find out if the URI segment is used for navigation.
 As mentioned, in our simple example we assume that the second segment is used for navigation (in advanced services, a segment could as well be an action or function import, etc).
-The navigation URI segment can then be asked for the corresponding _EdmNavigationProperty_
+The navigation URI segment can then be asked for the corresponding `EdmNavigationProperty`
 
     :::java
     UriResource lastSegment = resourceParts.get(1);
@@ -471,7 +476,7 @@ The navigation URI segment can then be a
 	    EdmNavigationProperty edmNavigationProperty = uriResourceNavigation.getProperty();
 
 
-The bad news is that the _EdmNavigationProperty_ doesn’t know about the target _EdmEntitySet_.
+The bad news is that the `EdmNavigationProperty` doesn’t know about the target `EdmEntitySet`.
 This is as per design, just check the metadata:
 
     :::xml
@@ -492,12 +497,12 @@ The target entity set is defined in the
 This is where we get the information that we need.
 
 For our implementation, this means:
-  1. we need the _EdmEntiySet_ that corresponds to the first segment of the URI
+  1. we need the `EdmEntitySet` that corresponds to the first segment of the URI
   	in our example: Categories
   2. we need the navigation property that corresponds to the second segment of the URI
   	in our example: Products
 
-As shown below, from the source _EdmEntitySet_ we get the binding target, based on the navigation property.
+As shown below, from the source `EdmEntitySet` we get the binding target, based on the navigation property.
 
     :::java
     EdmBindingTarget edmBindingTarget = startEntitySet.getRelatedBindingTarget(navPropName);
@@ -506,16 +511,16 @@ As shown below, from the source _EdmEnti
 
 This target is the entity set that we need.
 
-We move the code into the utility method _Util.getNavigationTargetEntitySet(startEdmEntitySet, edmNavigationProperty)_
+We move the code into the utility method `Util.getNavigationTargetEntitySet(startEdmEntitySet, edmNavigationProperty)`
 Reason is that we'll need it again, later in this tutorial.
 
 ### 3.2.3 Remaining tasks
 
-In the previous tutorials we’ve already learned what else has to be done: transform the retrieve data into an _InputStream_ i.e. serialize the content.
+In the previous tutorials we’ve already learned what else has to be done: transform the retrieve data into an `InputStream` i.e. serialize the content.
 Furthermore, configure the response object, i.e. set the response body, the content type and the header.
 
 
-The following snippet shows the implementation of the _readEntityCollection(…)_ method.
+The following snippet shows the implementation of the `readEntityCollection(…)` method.
 
     :::java
 public void readEntityCollection(ODataRequest request, ODataResponse response, UriInfo uriInfo, ContentType responseFormat)
@@ -595,12 +600,12 @@ As per design, a product can only belong
         Partner="Products"/>
 
 So when the user follows the navigation property in order to display the product category, he expects a response that contains only one entry.
-This means that we have to do the implementation in the _EntityProcessor_.
+This means that we have to do the implementation in the `EntityProcessor`.
 
-Open the class _myservice.mynamespace.service.DemoEntityProcessor.java_
+Open the class `myservice.mynamespace.service.DemoEntityProcessor.java`
 
 As usual, we first have to analyze the URI.
-Just like we did in the _EntityCollectionProcessor_, we have to distinguish between navigation and “normal” read of an entity:
+Just like we did in the `EntityCollectionProcessor`, we have to distinguish between navigation and “normal” read of an entity:
 
     :::java
     if(segmentCount == 1){
@@ -609,10 +614,10 @@ Just like we did in the _EntityCollectio
         // this is reached in case of navigation
     }
 
-In the following section, we’ll focus on the navigation case only.
+In the following section, we will focus on the navigation case only.
 In our example, our task is to find the category of a chosen product.
 Again, we have to first fetch the chosen product (first URI segment) from our database-mock and in a second step, we have to ask our database-mock for the corresponding category.
-This final entity is then serialized and set as response body for the _readEntity_ method, which we’re implementing.
+This final entity is then serialized and set as response body for the `readEntity()` method, which we’re implementing.
 
 **A) get the data for the first URI segment**
 
@@ -634,7 +639,7 @@ Therefore, we invoke our helper method a
     :::java
     responseEntity = storage.getRelatedEntity(sourceEntity, responseEdmEntityType);
 
-Before we can serialize the _responseEntity_, we have to retrieve the _EdmEntitySet_ that corresponds to the response entity, because we need it for building the ContextURL.
+Before we can serialize the `responseEntity`, we have to retrieve the `EdmEntitySet` that corresponds to the response entity, because we need it for building the ContextURL.
 
 The procedure is the same like in the chapter above, where we treated the to-many navigation:
 
@@ -643,7 +648,7 @@ The procedure is the same like in the ch
     responseEdmEntityType = edmNavigationProperty.getType();
     responseEdmEntitySet = Util.getNavigationTargetEntitySet(startEdmEntitySet, edmNavigationProperty);
 
-In our example, the value of the variable _responseEdmEntitySet_ will be “Categories” and it will be used for building the contextURL, which will look as follows:
+In our example, the value of the variable `responseEdmEntitySet` will be “Categories” and it will be used for building the contextURL, which will look as follows:
 
     :::xml
     "$metadata#Categories/$entity"
@@ -655,7 +660,7 @@ In our example, the value of the variabl
 
 but in addition, we want to read only one of the collected products, which is directly addressed by its key:   <http://localhost:8080/DemoService/DemoService.svc/Categories(3)/Products(5)>
 
-From this URL, we can assume that the _EntityProcessor.java_ is the relevant place to handle this request in our code.
+From this URL, we can assume that the `EntityProcessor` is the relevant place to handle this request in our code.
 
 The steps to find the requested entity are:
 
@@ -670,12 +675,12 @@ The steps to find the requested entity a
 
 We can assume, that our database-mock is able to perform step 2 and 3 together.
 
-In our class _myservice.mynamespace.service.DemoEntityProcessor.java_, we’ve already added the navigation capability for to-one navigation.
+In our class `myservice.mynamespace.service.DemoEntityProcessor.java`, we’ve already added the navigation capability for to-one navigation.
 How can we find out that we aren’t called for a to-one navigation, but instead, we’re responding to a to-many navigation with key access?
 The difference is the “key predicate”.
 The necessary info about it can be obtained from the URI segment.
-In the first chapter, we’ve already learned that there’s a special interface responsible for navigation segments, the _org.apache.olingo.server.api.uri.UriResourceNavigation_
-It also provides a method _getKeyPredicates()_
+In the first chapter, we’ve already learned that there’s a special interface responsible for navigation segments, the `org.apache.olingo.server.api.uri.UriResourceNavigation`
+It also provides a method `getKeyPredicates()`
 We can make use of it in order to distinguish between “to-one navigation” and “navigation with key access”.
 If the call to
 
@@ -686,9 +691,9 @@ returns an empty list, then we can assum
 This to-one navigation has been explained in the chapter 3.3. above.
 If  the service request is like
 /Categories(3)/Products(5)
-then the method _getKeyPredicates()_ will return a list of with one element that contains ID=5
+then the method `getKeyPredicates()` will return a list of with one element that contains ID=5
 
-In our implementation of the _EntityProcessor_, we add the following code:
+In our implementation of the `EntityProcessor`, we add the following code:
 
     :::java
     List<UriParameter> navKeyPredicates = uriResourceNavigation.getKeyPredicates();
@@ -707,16 +712,13 @@ The new helper method
     :::java
     responseEntity = storage.getRelatedEntity(sourceEntity, responseEdmEntityType, navKeyPredicates);
 
-will take care of getting the collection of products (_responseEntityType_) that are in scope of the chosen category (_sourceEntity_) and will then pick the requested product, based on the given key (_navKeyPredicates_).
+will take care of getting the collection of products (`responseEntityType`) that are in scope of the chosen category (`sourceEntity`) and will then pick the requested product, based on the given key (`navKeyPredicates`).
+
+One last thing to consider:  
+As we mentioned above, the user of our service is expected to specify a key of a product that is contained in the collection of products (e.g. */Categories(3)/Products*) that is addressed by e.g. */Categories(3)/Products(5)*.
+
+But he might specify a product ID that is existing, but not valid for the addressed navigation e.g. */Categories(3)/Products(1)*.
 
-One last thing to consider:
-As we mentioned above, the user of our service is expected to specify a key of a product that is contained in the collection of products that is addressed by e.g.
-/Categories(3)/Products
-e.g.
-/Categories(3)/Products(5)
-But he might specify a product ID that is existing, but not valid for the addressed navigation.
-e.g.
-/Categories(3)/Products(1)
 With other words: it is not valid to navigate from category "Monitors" to a product like "Notebook Basic 15"
 
 If this is the case, we have to throw an appropriate exception.
@@ -739,10 +741,10 @@ As we know, Categories(3) is “Monit
 
 
 That’s it.
-We don’t need to do an additional effort to retrieve the _EdmEntitySet_ for the ContextURL, because this has already been implemented in our _DemoEntityProcessor_ in the context of the previous chapter 3.3.
+We don’t need to do an additional effort to retrieve the `EdmEntitySet` for the ContextURL, because this has already been implemented in our `DemoEntityProcessor` in the context of the previous chapter 3.3.
 
 
-So now we can finally have a look at the full implementation of the _readEntity()_ method, the covers both the cases of chapter 3.3. and 3.4.
+So now we can finally have a look at the full implementation of the `readEntity()` method, the covers both the cases of chapter 3.3. and 3.4.
 
     :::java
     public void readEntity(ODataRequest request, ODataResponse response, UriInfo uriInfo, ContentType responseFormat)
@@ -870,7 +872,7 @@ Check the *Links* section for more OData
   * Tutorial OData V4 service part 3: [Write (Create, Update, Delete Entity)](/doc/odata4/tutorials/write/tutorial_write.html) | [sample project zip](http://www.apache.org/dyn/closer.cgi/olingo/odata4/Tutorials/DemoService_Tutorial_Write.zip) ([md5](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_Write.zip.md5), [sha512](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_Write.zip.sha512), [pgp](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_Write.zip.asc))  
   * Tutorial OData V4 service, part 4: [Navigation (this page)](/doc/odata4/tutorials/navigation/tutorial_navigation.html) | [sample project zip](http://www.apache.org/dyn/closer.cgi/olingo/odata4/Tutorials/DemoService_Tutorial_Navigation.zip) ([md5](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_Navigation.zip.md5), [sha512](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_Navigation.zip.sha512), [pgp](https://dist.apache.org/repos/dist/release/olingo/odata4/Tutorials/DemoService_Tutorial_Navigation.zip.asc))
   * Tutorial OData V4 service, part 5: System Query Options  (to be announced)
-
+<!--  -->
 ### Further reading
   * OData specification: [http://odata.org/](http://odata.org/)
   * [Olingo Javadoc](/javadoc/odata4/index.html)