Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set plugin prefix in the plugin itself #2667

Closed
AdriVanHoudt opened this issue Jul 28, 2015 · 17 comments
Closed

Set plugin prefix in the plugin itself #2667

AdriVanHoudt opened this issue Jul 28, 2015 · 17 comments
Assignees
Labels
feature New functionality or improvement

Comments

@AdriVanHoudt
Copy link
Contributor

Atm you can pass a plugin prefix with the options on server.register. I would like to define a 'global' (at plugin level) prefix as well so the plugin also has control over the prefix.
I would still allow the prefix to be passed by the options.
This would result into route = options.prefix + plugin.attributes.prefix + route.path

Would you accept a PR for this?

@mtharrison
Copy link
Contributor

Not sure if it's exactly what you're looking for but you could append to the prefix inside the register function?

index.js

var Hapi = require('hapi');

var server = new Hapi.Server();
server.connection({ port: 8080 });

server.register(require('./plugin'),
    {
        routes: {
            prefix: '/outside'
        }
    }, 
function () {

    server.start();
});

plugin.js

exports.register = function (server, options, next) {

    server.realm.modifiers.route.prefix += '/inside';

    server.route({
        path: '/path',
        method: 'GET',
        handler: function (request, reply) {

            reply('ok');
        }
    });

    next();
};

exports.register.attributes = {
    name: 'plugin'
}

The route is then GET /outside/inside/path

@AdriVanHoudt
Copy link
Contributor Author

Yeah that is want to avoid. I want to give the plugin the responsibility of setting its own prefix like I have a user plugin and it prefixes all it routes with /user/. I want it to be some option in register.attributes or something rather than setting it in the server registration logic

@mtharrison
Copy link
Contributor

The plugin does have the responsibility in my example though. It's modifying the prefix internally. Are you just looking for a way to do the same in config instead?

@AdriVanHoudt
Copy link
Contributor Author

oh wow totally missed that line 😮 and yeah that works but config would look cleaner and it will be 1 line of code from the looks of it then

@hueniverse
Copy link
Contributor

I am not a fan of messing with the realm config this way. Config should be treated as read-only (and will probably become const at some point).

The right way to accomplish this is with a utility that simply adds a prefix before calls to route() are called. Basically this sounds like a shortcut, not a core feature.

@hueniverse hueniverse self-assigned this Jul 29, 2015
@AdriVanHoudt
Copy link
Contributor Author

Is there a way to come between the route calls? Because then I could make an easy plugin

@hueniverse
Copy link
Contributor

You can decorate the server with your own version of adding a route function.

@devinivy
Copy link
Member

That's a good solution to a problem closely related to a question/proposition I posed over at #2566.

@AdriVanHoudt
Copy link
Contributor Author

@hueniverse like overriding the function or decorating with server.decorate/method(don't know the right one from the top of my head)
@devinivy this is about startup not about during lifecycle stuff

@devinivy
Copy link
Member

Ugh, sorry @AdriVanHoudt – I linked to the wrong issue. Try #2650. I assume that he meant to decorate server with a method that wraps server.route.

@AdriVanHoudt
Copy link
Contributor Author

I am not fully following your explanation in the issue and yeah something like

Var oldRoute = server. Route()
Server.route = function () {
    My stuff
}

(Programming on phone :P)

@devinivy
Copy link
Member

See docs for server.decorate: http://hapijs.com/api/8.8.0#serverdecoratetype-property-method.

Ex.

var specialRoute = function (definition) {

    // Transform or glean info from definition then...
    server.route(definition);
}

server.decorate('server', 'specialRoute', specialRoute);

server.specialRoute({/* Route definition */});

@mtharrison
Copy link
Contributor

@AdriVanHoudt You could have a plugin that does this:

server.decorate('server', 'routePrefix', function (prefix) {

    var originalRoute = this.route;

    return function (options) {

        options = [].concat(options);

        for (var i = 0; i < options.length; ++i) {
            options[i].path = prefix + options[i].path;
        }

        return originalRoute.call(server, options);
    };
});

And then use it like this:

var route = server.routePrefix('/adri');

route({
    method: 'GET',
    path: '/path',
    handler: function (request, reply) {

        reply('hello');
    }
});

route([{
    method: 'GET',
    path: '/path2',
    handler: function (request, reply) {

        reply('hello');
    }
}, {
    method: 'GET',
    path: '/path3',
    handler: function (request, reply) {

        reply('hello');
    }
}]);

Each route is then prefixed with /adri

@AdriVanHoudt
Copy link
Contributor Author

can I do server.decorate('server', 'route', myRoute); so that I don't have to change the calls but the implementation is just different?

@mtharrison
Copy link
Contributor

No, you'll get an error:

Error: Cannot override the built-in server interface method: route

@AdriVanHoudt
Copy link
Contributor Author

😞
Could I force it by not using decorate but just doing:

var old = server.route;
server.route = function() {
    // my own stuff...
    old();
};

@Marsup Marsup added feature New functionality or improvement and removed request labels Sep 20, 2019
@lock
Copy link

lock bot commented Jan 9, 2020

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature New functionality or improvement
Projects
None yet
Development

No branches or pull requests

5 participants