Changes for page Your First Rest Project

Last modified by Steve Peery on 2013/09/06 11:02

From version 35.1
edited by franc
on 2012/02/27 16:47
Change comment: replaced left > right
To version 36.1
edited by pauldlynch
on 2012/05/28 04:09
Change comment: Minor spelling, and make method names in text match code.

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.franc
1 +XWiki.pauldlynch
Content
... ... @@ -77,7 +77,7 @@
77 77  
78 78  If you did everything well, the list of attributes should look like this:
79 79  
80 -You will notice that the attributes have a column with a lock in it. When a lock is present, it will use the value of that attribute for //UPDATE ... WHERE attribute = ''// statement. This is to do optimistic locking, aka to prevent data conflict when the data object was modified by two different users. Using timestamps for optimistic locking is not a good idea because for certain RDBMS, the value can be different because of milliseconds, so remove the locks on the **lastModified** and **creationDate** attributes. The final list should look like this:
80 +You will notice that the attributes have a column with a lock in it. When a lock is present, it will use the value of that attribute for //UPDATE ... WHERE attribute = ''// statement. This is to do optimistic locking, aka to prevent data conflict when the data object was modified by two different users. Using timestamps for optimistic locking is not a good idea because for certain RDBMS, the value can be different because of milliseconds, so remove the locks on the **creationDate** attribute. The final list should look like this:
81 81  
82 82  Next step is to create the **Author** entity. Create a new entity with **Author** at its name (and also as the table name), and for the class name, use **your.app.model.Author**. The attributes for this entity are:
83 83  
... ... @@ -88,7 +88,7 @@
88 88  
89 89  Final list of attributes should look like this:
90 90  
91 -Now, it's time to link the two entities together. A Author can have multiple blog entries, and a BlogEntry can only have one author. To create the relationship (the join), right-click on **Author** and select **New Relationship**. On your right, select **BlogEntry** in the list. On your left, select **to many BlogEntries**, and on your right, select **to one Author**. Now, in BlogEntry, we need to store the primary key of the author so that we can make the join. The relationship builder allow us to add that attribute, so make sure **and a new foreign key named** is checked (it is checked by default). The **Create Relationship** pane should look like this:
91 +Now, it's time to link the two entities together. An Author can have multiple blog entries, and a BlogEntry can only have one author. To create the relationship (the join), right-click on **Author** and select **New Relationship**. On your right, select **BlogEntry** in the list. On your left, select **to many BlogEntries**, and on your right, select **to one Author**. Now, in BlogEntry, we need to store the primary key of the author so that we can make the join. The relationship builder allow us to add that attribute, so make sure **and a new foreign key named** is checked (it is checked by default). The **Create Relationship** pane should look like this:
92 92  
93 93  If you check in the **Outline** tab, you should see that **Author** now have a **blogEntries** relationship, and **BlogEntry** have a **author** relationship.
94 94  
... ... @@ -124,7 +124,7 @@
124 124  
125 125  == Using migrations ==
126 126  
127 -Migrations allow you to create the tables and columns (and some types of constraint). **Entity Modeler** have support to generate the code for the first migration, which is called "migration 0". To do that, open the EOModel (**BlogModel EOModel** in the **Resources** folder), right-click on the model name and select **Generate Migration**.
127 +Migrations allow you to create the tables and columns (and some types of constraint). **Entity Modeler** has support to generate the code for the first migration, which is called "migration 0". To do that, open the EOModel (**BlogModel EOModel** in the **Resources** folder), right-click on the model name and select **Generate Migration**.
128 128  
129 129  Copy the generated code in the clipboard. Close **Entity Modeler** and in the main Eclipse window, right-click on **Sources**, select **New** and select **Class**.
130 130  
... ... @@ -206,7 +206,7 @@
206 206  In Project Wonder, *Action* at the end of a method is a convention for REST and Direct Actions, when you call those methods from certain components, you don't need to add the *Action* part.
207 207  {{/info}}
208 208  
209 -For this tutorial, we will implement the **createAction** and **showAction** methods. But first, we need to create a key filter. A key filter will... filter the input and the output of REST request so that you don't have to send all attributes for a blog entry. For example, we want to show the details for an author, but we don't want to show the password for the author (in real-life, the password would be encrypted)
209 +For this tutorial, we will implement the **createAction** and **indexAction** methods. But first, we need to create a key filter. A key filter will... filter the input and the output of REST request so that you don't have to send all attributes for a blog entry. For example, we want to show the details for an author, but we don't want to show the password for the author (in real-life, the password would be encrypted)
210 210  
211 211  Add this method in **BlogEntryController**:
212 212  
... ... @@ -225,7 +225,7 @@
225 225  
226 226  {{/code}}
227 227  
228 -Now, let's implement the **creationAction** method:
228 +Now, let's implement the **createAction** method:
229 229  
230 230  {{code}}
231 231  
... ... @@ -239,7 +239,7 @@
239 239  
240 240  In 3 lines of code, you can create an object based on the request, save the new object to the database and return the new object in the response. Not bad, eh?
241 241  
242 -Last step in the controller: implementing the **showAction** method. Again, the code is simple:
242 +Last step in the controller: implementing the **indexAction** method. Again, the code is simple:
243 243  
244 244  {{code}}
245 245  
... ... @@ -319,7 +319,7 @@
319 319  
320 320  Switching the return value of this method says that we will follow a certain convention for HTML components. The convention for automatic HTML routing is that the component should be named <EntityName><Action>Page.wo. So in our case, the component will be **BlogEntryIndexPage**. Right-click on the project name in Eclipse and select **New** > **WOComponent**. Change the name to **BlogEntryIndexPage** and check the **Create HTML contents** button. Click **Finish**.
321 321  
322 -The next step to get it to work is to make **BlogEntryIndexPage** to implements the **er.rest.routes.IERXRouteComponent** interface.
322 +The next step to get it to work is to make **BlogEntryIndexPage** to implement the **er.rest.routes.IERXRouteComponent** interface.
323 323  
324 324  {{code}}
325 325  
... ... @@ -373,7 +373,7 @@
373 373  
374 374  Now that we have a list of blog entries, let's make a page to show the content of a blog entry. Create a new component named **BlogEntryShowPage**.
375 375  
376 -Open **BlogEntryShowPage.java** and make sure the class extends from **er.rest.routes.IERXRouteComponent**.
376 +Open **BlogEntryShowPage.java** and make sure the class implements&nbsp;**er.rest.routes.IERXRouteComponent**.
377 377  
378 378  {{code}}
379 379