Developer's diary

[gene]

...
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!

[gene]

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)?

• created with the Yeoman generator for AngularJS (https://github.com/yeoman/generator-angular)
• integrated dependency managament with npm (https://www.npmjs.org/) / Bower (http://bower.io/)
• build management with Grunt (http://gruntjs.com/)
• JavaScript unit tests with Karma (http://karma-runner.github.io) (TODO: end2end tests)
• live reload (https://github.com/gruntjs/grunt-contrib-watch) of the website during development
• REST calls with Restangular (https://github.com/mgonto/restangular)
• edit task objects, including subtasks (1-n relation)
• list revisions of task objects and language objects (stored on the server via Hibernate Envers)
• automatic build & deployment on our own server and at travis-ci.

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)

[gene]

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.

[gene]

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 ) !

[gene]

I realized the possibility to create new tasks and remove existing tasks in the ToDo application.

Does not look like much work, but it was
But now it's working!

[gene]

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!

[gene]

I resumed the work on the authorization process.
Take a look at this wiki page and especially at the new diagram

[gene]

Login/Logout is now working in our ToDo test application.



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!

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.

[MZ per X]

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

Cool to see another important milestone reached. I'm curious what you will tackle next?

[gene]

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! I will try to consolidate this code and commit it to Github.

[MZ per X]

Wow, it's astounding what is out there, if you know what to look for. Impressed!

[gene]

I'm back!

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!

[hydr0x]

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.

[gene]

Hi hydr0x, great you are still around!

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.

[MZ per X]

Check out my wiki page about our REST authentication mechanism for some details.

(I just added a missing "yes" below "valid JSON Web Token?".)