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

 #38135  by gene
 31 Aug 2014, 22:18
gene wrote:...
I will try to implement this at first for our generic server application and then do it for our bigger Oregami data model.
For the non-game-related server project I made some progress:
I added a "Language" entity, which ist also a top level object (TLO). Then I connected the available "Task" entity (TLO) to this Language.
These two TLOs can now be changed independent from each other, here an example:
  1. create a Language "english" object and save it
  2. create a Task object with "english" for the language attribute and save it
  3. change an attribute of the Task and save it again. This creates another "revision" of the Task object
  4. change the Language from step 1), e.g. change the description (imagine there was a typo in it).
  5. Now load the Task from before, and we notice that the language attribute of that task is "automatically" connected to the latest revision from the language, although we did not change the Task directly. To achieve this in the Java source code the connection from Task to Language is annotated with:
    Code: Select all
    @Audited(targetAuditMode = RelationTargetAuditMode.NOT_AUDITED)
    (explanation here)
What does that mean to the Oregami development?
For me that's a nice step forward. I can now connect the Top Level Objects and make sure that they can both be updated independently (and we have plenty TLOs in our data model - he yellow ones)
What I need to find out is how we can manage even more complex connections between two TLOs, e.g. the "GameToGameTitleConnection" seen here. I will try it! :D
 #38141  by gene
 16 Sep 2014, 20:50
I made great progress in developing an exemplary JavaScript client web application for our ToDo server application (which - in case you don't know - I created to learn as much as possible about every facet of our development components).

So in the last weeks I learned very much about realizing the JavaScript web application.
You can take a look at the new Github repository and I even have it running here on our web server.

So what are its features (up to today)? As I said above, that's a great step forwards for me.
I am now short before transforming all these things to our Oregami applications! (server & client)
 #38147  by gene
 04 Oct 2014, 07:55
I created a "next iteration" for the Oregami Web Client!

Aside from picking a new bootstrap theme which might be the first thing you will notice, I transferred a great part of my new knowledge (see previous post) to the Oregami Web Client.

Most work was done on the publication page. The underlying dat model has been expanded, and you can now edit publications! Just click one of the franchises and then click on the "edit" button. This is where the fun can now slowly begin! At the current version the complete PublicationFranchise entity is shown. That's not very comfortable of course, but I can build upon this to create a better version of the edit page.

For error handling: Try to leave the franchise name empty during an edit operation. The error message for that will be shown next to the input field, an it is available in both languages (change the language after the error occured!).

Hope you like it!

Note: This is not a "simply hacked together" state. It's based on solid technologies, data model and server application! That's what we wanted to do from the beginning: solid development, no quick shots.
 #38157  by gene
 21 Oct 2014, 20:44
I watched the youtube video "Beautiful REST & JSON APIs". It gives a great overview about JSON REST APIs !

I learned the following lessons from it:
  • resource collection URLs should be plural, not singular. So I will have to change e.g. "/publicationFranchise" to "/publicationFranchises".
  • we should use ISO 8601 as a date / time format.
  • when someone creates a resource, the HTTP return code should be 201 = CREATED, and not 200 = OK
Looking forward to implement these things (and much more of course :D ) !
 #38169  by gene
 29 Nov 2014, 23:27
Up to now I used Grunt JS as tha JavaScript build system.
I read some articles that compared Grund with Gulp JS, which is an alternative to Grunt.

Today I switched my generic ToDo Angular JS application from Grunt to Gulp.
I had some problems with Grunt, and these problems are gone with Gulp.
Will transfer this to the Oregami Client as soon as possible!

The lates news about the ToDo application:
I got the login working! Try "user1/password1" or "user2/password2" to login.
That's really great!
 #38198  by gene
 22 Jan 2015, 22:51
Login/Logout is now working in our ToDo test application.

Image

When you are logged in, you can delete tasks. When you are not logged in, you cannot delete tasks: the icon is blocked, but even if you du the HTTP request manually, it will be blocked if you don't send the required token with the request.

I have implemented the authentication with JSON Web Tokens. Yeah. No antiquated session, just REST! :D

If you want to try it: use "user1" as username and "password1" as password.
Also be sure to check the source code if you want to.
 #38199  by MZ per X
 23 Jan 2015, 21:14
gene wrote:I have implemented the authentication with JSON Web Tokens. Yeah. No antiquated session, just REST! :D
Cool to see another important milestone reached. I'm curious what you will tackle next? :)
 #38200  by gene
 27 Jan 2015, 21:54
MZ per X wrote:I'm curious what you will tackle next? :)
During the last days I tried to get end2end tests to work.
I was partly successful: I wrote some tests for protractor, a tool collection for testing AngularJS web applications. These can be executed with the command "gulp protractor" and will "remote control" a real browser (which runs locally) and check if the web application reacts in the right way.

That's great!

It would be even better if I could use Sauce Labs. They offer "remote browser testing" for many operating systems and browser versions. Imagine this: we could test automatically if our web application runs correct on all these platforms! And what's also great: they offer these services for free to open source projects!
But sadly I did not get that to work. Perhaps later, so long I can do end2end tests locally with one browser. Better than nothing.
Check out this test run. They even record screenshots or videos like this.

Followup: I did one last try and check out this video! :D :D I will try to consolidate this code and commit it to Github.
 #38201  by MZ per X
 28 Jan 2015, 21:56
Wow, it's astounding what is out there, if you know what to look for. Impressed! :D
 #38204  by gene
 16 Feb 2015, 20:56
I'm back! :wink:

I transferred the server part of the authentication mechanism to the oregami server code.

That means if you make this POST request:
url: http://test.server.oregami.org/jwt/login
Header: Content-Type=application/x-www-form-urlencoded
data: username=user1&password=password1

will return this JSON Web Token:
Code: Select all
{
   "token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJleHAiOjE0MjQxMTgyMjIsImlhdCI6MTQyNDExNjQyMiwidXNlcm5hbWUiOiJ1c2VyMSJ9.E9G4yvX-wekpJvUZyAVBAeYibcaX5CvW7r44BHTQoRaW37WE4TQj8qjA3oExwYkYlOyiitHv0GV4NvsiF6ZDtw"
}
I will do the client side during the next days!
 #38205  by hydr0x
 17 Feb 2015, 09:23
Are you storing the tokens on the server or are they created and compared on-the-fly on the server each time a request with a token comes in?

Because, as I think you were/are going for a truly RESTful API, let me quickly point out that any kind of stored token authentication is not really RESTful. RESTful means that the server is fully stateless. Which means that every request is independent of each other and should only rely on the existing resources. Tokens which are stored on the server break this principle. The server has a session-state as it somewhere stores all currently valid tokens.
 #38206  by gene
 17 Feb 2015, 19:51
Hi hydr0x, great you are still around!
hydr0x wrote:Are you storing the tokens on the server or are they created and compared on-the-fly on the server each time a request with a token comes in?
Of course the token ist not stored on the server. That's exactly what you don't want when you create a RESTful application: state on the server. Just as you said.

Check out my wiki page about our REST authentication mechanism for some details.
 #38207  by MZ per X
 18 Feb 2015, 08:55
gene wrote:Check out my wiki page about our REST authentication mechanism for some details.
(I just added a missing "yes" below "valid JSON Web Token?".) 8)
  • 1
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9