Open Registry of Game Information 

  • Developer's diary

  • All things about Java, JavaScript, HTML, Git, whatever is useful for developers.
All things about Java, JavaScript, HTML, Git, whatever is useful for developers.

Moderators: MZ per X, gene

 #37957  by Sidasa
 26 Feb 2014, 22:39
gene wrote:I committed the new source code and deployed it to the client and the server.
Check it out!
Working nice!

Are you saving the website-url and a timestamp?
Would be good to have that in the database and/or in the metadata of the screenshot (iptc).
 #37958  by gene
 26 Feb 2014, 22:52
Sidasa wrote:
gene wrote:I committed the new source code and deployed it to the client and the server.
Check it out!
Working nice!

Are you saving the website-url and a timestamp?
Would be good to have that in the database and/or in the metadata of the screenshot (iptc).
Yes, of course.
Try a mouseover on the preview images or this API call.

But that's all still only a technical prototype of course. Im am getting closer to the development of a "real application".
User registration and the contribution process are up next.
 #37960  by Sidasa
 26 Feb 2014, 23:39
gene wrote: Yes, of course.
Try a mouseover on the preview images or this API call.
Sorry, didn't see that. Perhaps we need to save the timezone!?
 #37961  by gene
 26 Feb 2014, 23:47
Sidasa wrote:
gene wrote: Yes, of course.
Try a mouseover on the preview images or this API call.
Sorry, didn't see that. Perhaps we need to save the timezone!?
Well, it's "Oregami API Server timezone" :D

But I must say that I don't have any experience with such problems.
How coud we handle this? Is the timezone of a website visitor known? the timestamp on the server is well defined, but a visitor from another timezone would expect to see his "own" time.
 #37963  by gene
 28 Feb 2014, 12:37
MZ per X wrote:
gene wrote:PS1: For security reasons the URLs must start with "www.oregami.org", "www.kultpower.de" or "www.mobygames.com".
I am somehow not able to shoot oregami.org pages. Why is that?
Ah, I got it:
The Server-Application runs on the same server as www.oregami.org and the lookup to the oregami.org domain seems to be broken.
In my development environment it works. Should't be a problem anyway, why should we give an oregami website as a valid source for gaming data? :D
 #37965  by MZ per X
 03 Mar 2014, 20:47
gene wrote:Should't be a problem anyway, why should we give an oregami website as a valid source for gaming data? :D
We won't, but other sites will do this in the future. ;)
 #37977  by gene
 13 Mar 2014, 22:26
I "completed" the first form to submit "new data".
Actually it is the "register form" to register as a new User. I did not (yet) concentrate on the whole "confirm your registration in the email" stuff.

My main focus was on validation of the entered data through the REST call against the server. And I wanted to be able to create error messages for every HTML input field, every one with a seperate message. And every message also localized in every available language.

The result looks like this:

Go to http://test.client.oregami.org/#/register

There you can see the HTML form. I do not use client side validation, everything is validated on the server.
So enter some values and press "submit". Ths creates a REST call against http://test.server.oregami.org/user (POST) with this JSON data:
Code: Select all
{
  "username":"test",
  "email":"test@kultpower.de",
  "password":"12345"
}
The server walks through the java code (UserResource.createUser => UserServiceImpl.registerUser => UserValidator.validateForRegister => UserValidator.validateRequiredFields) and creates a (potentially filled) List<ServiceError> packed in a ServiceResult<User>. If the List<ServiceError> contains at least one error, an HTTP status code 409 "Conflict" is returned. The body of that HTTP error contains the error list as JSON again:
Code: Select all
[
  {
    "messageName":"USER_USERNAME_TOO_SHORT",
    "context":{
      "field":"user.username"
    }
  },
  {
    "messageName":"USER_PASSWORD_TOO_SHORT",
    "context":{
      "field":"user.password"
    }
  }
]
These error values are automatically processed by the JavaScript client. The error messages are assigned the the proper input field and translated to the localized message via AngularJS language files for angular-translate. And the input fields with errors are then marked with red colors.

"It's that simple, isn't that great?" (who said this?)

PS: Yes I know that if you call (HTTP GET) http://test.server.oregami.org/user the list exposes the (hashed) password values which is not very nice. This will change of course in the future.
 #37980  by Sidasa
 23 Mar 2014, 14:39
gene wrote:
Sidasa wrote:Perhaps we need to save the timezone!?
Well, it's "Oregami API Server timezone" :D

But I must say that I don't have any experience with such problems.
How coud we handle this? Is the timezone of a website visitor known? the timestamp on the server is well defined, but a visitor from another timezone would expect to see his "own" time.

You are right. The server timezone would be the same. But only, if we have one server or multiple server in the same timezone.
Would it not be better to add the timezone for every data output?

For future project that should save us one api call to get the Oregami timezone. That could be necessary for example, if an other project use the Oregami database for the main data, but extended it with an extra data layer.
 #37982  by gene
 26 Mar 2014, 23:04
Now for something completey different...

Our JPA entities in the code have a primary key attribute. First I chose a <Long> datatype for this key, and every new entity got a new Long key (1, 2, 3, ...).
But somewhere in the web I heard "dont's use simple, ascending numbers as keys for your entities.".
Image

So I tried to create an alternative BaseEntity based on a UUID key.
The result is the class BaseEntityUUID, which uses the Hibernate UUDIGenerator.

This again results in more generic looking URLs for the entities (e.g. GameTitles).
List of GameTitle resources:
Code: Select all
  {
    "id": "ff80818145004749014500475e6b0000",
    "version": 0,
    "lastUpdate": null,
    "nativeSpelling": "The Secret of Monkey Island",
    "standardTransliteration": null,
    "language": {
      "id": 6,
      "version": 0,
      "lastUpdate": null,
      "name": "ENGLISH"
    }
  },
  {
    "id": "ff80818145004749014500475e740001",
    "version": 0,
    "lastUpdate": null,
    "nativeSpelling": "Le Secret de L'Ile aux Singes",
    "standardTransliteration": null,
    "language": {
      "id": 7,
      "version": 0,
      "lastUpdate": null,
      "name": "FRENCH"
    }
  },
...
Example URL for the first shown resource:
http://test.server.oregami.org/gameTitl ... 475e6b0000

At the moment the database column is a String. That might not be performing very well, I will be looking for a database with a native UUID type.
 #37998  by gene
 06 Apr 2014, 16:58
Sidasa wrote:
gene wrote:I switched all BaseEntity-SubClasses to BaseEntityUUID (see above).

It's working.
For the productive usage that would be reasonable. But i think for testing and prototyping it's not so good.

Links aren't easy to read and neither to remember:
http://test.server.oregami.org/gameTitl ... 59c8380032
versus
http://test.server.oregami.org/gameTitle/1
Well, that sounds reasonable at a first glance. But as my goal is to create an application with HATEOAS support anyway, the real link text should be irrelevant. With real HATEOAS even more things need not to be known in advance by the client: it interprets the hypermedia document and parses it and shows the links/forms and so on. Take a look at this or this or this for "what and why HATEOAS". I did not begin with the implementation of this part, if anybody wants to support me...

So I don't want anybody to get used to links like "/gameTitle/1" or "/game/2" 8)
 #37999  by hydr0x
 06 Apr 2014, 22:23
Don't make the mistake of only thinking in terms of the API though. You also want to serve a human-usable website and ideally, you use the same URL structure for both interfaces. Hence, it would be a mistake to "not care" about ID design just because it doesn't matter when using the API. I don't think Lez Hazlewood's stance should be taken as the ultimate answer. You have to ask yourself what you gain by using UUID. They are great when you for some reason need globally unique identifiers or want to obfuscate your actual data structures (e.g. for UserIDs). But what good are they for game identifiers? Does it matter that a user knows the ID range?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 9