Glue and HTML views about university HOT 16 CLOSED

First thanks that these lessons are back again.

Now the first question :

Are these (https://github.com/hapijs/glue/tree/master/test) good examples how to test things with glue and lab. I have to rewrite all the former test now :(

Roelof

from university.

second question:

why can the plugin not be found here :

it('composes server with an manifest', function (done) {

        var manifest = {
            connections: [
                {
                    port: 3000,
                },
         ],
            plugins: {
                authentication: {
                    version: false,
                    plugins: 'lib'
        },
            version: [
                {
                    version: false,
                    plugins: 'lib'
                }
                    ]
            }
         };

        Glue.compose(manifest, function (err, server) {

            expect(err).to.not.exist();
            expect(server.connections).length(1);
            done();
        });
});

from university.

I try to test if a server is started.

from university.

How do I start the server. Do I need to add the whole part after starting the server to start.js ?

from university.

no due date ??

from university.

@roelof1967 For the test examples, you'd better go to a repo utilizing glue rather than the Glue repo itself. See e.g. aqua

In the plugins object of the manifest, each key should be the name of the target module if it's a npm module, or the relative path to it if the module is internal to the app. That's how Glue requires them before calling register.
e.g.

var manifest = {
    connections: [
        {
            port: 5000
        }
    ],
    plugins: {
        "./version": {} //the actual key depends on where you put your plugin and which folder you decide to use as relative root. Relative root is given as an option to the compose function.
    }
}

To be able to start the server and aim for minimal refactoring, you can keep a structure very similar to what we already have, e.g. just changing the init function in index.js to take manifest and glueOptions as params, replacing the server.register part by glue.compose, then changing start.js to pass in a manifest instead of a port.

from university.

oke, so I schould not use the whole export.compose thing of the example which were pointed for a example manifest ?

from university.

The example pointed at was more for the format of the manifest. The export.compose is the actual compose function you use from Glue (and you'll have to use it). You can check at the index.js and server.js from aqua for something closer to what we aim for.

from university.

oke, I have now this : https://github.com/roelof1967/university and still not working :(

from university.

@roelof1967 I made a quick example with server starting via npm start and plugin functionality kept (tests not updated yet). You may check lib/index.js and lib/start.js on this branch https://github.com/FennNaten/hueniversity/tree/assignment/glue-and-html-views if you're stuck.

from university.

@FennNaten thanks, now the next problem. Making the test green

from university.

@FennNaten Thank you for putting up the example :-)

from university.

I have this test :

var Hapi = require('hapi');
var Code = require('code');
var Lab = require('lab');
var Composer = require('../lib/start');

// Test shortcuts

var lab = exports.lab = Lab.script();
var expect = Code.expect;
var it = lab.test;

it('starts server and returns hapi server object', function (done) {

    Composer(function (err, composedServer) {

        Code.expect(composedServer).to.be.an.object();
        done(err);
    });

}); 

But now I see this error message : function is not a object.

What went wrong this time ?

Roelof

from university.

and when I do this :

plugins: {
        './version': {},
        './private': {},
        './home': {},

    }

I get a message that private is already registered. There is something wrong with the home but I do not see it.

from university.

@roelof1967 it would probably be better for everyone if you keep the discussion about your own submission within your pull request. This is a lot of noise here which makes it hard for people to participate and keep track of what is going on. Also, a lot of this would be better done in the gitter room for this repo.

from university.

oke, I will do it that way

from university.