Url methods of the Portal lib convert all "unknown" params properties to url parameters

[cfenzo]

Discovered that all "unknown"** properties on the input parameters object is converted to url parameters prefixed with _..

** "unknown", as in not defined as a params object property in the docs

Examples:

portal.portal.serviceUrl({
    service: 'counter',
    name: 'counter', // "unknown" property
    foo: 'bar' // "unknown" property
});
// returns '*/_/service/[application]/[service-name]?_foo=bar&_name=counter'

portal.portal.assetUrl({
    path: 'css/objects.css',
    foo: 'bar' // "unknown" property
});
// returns '/_/asset/[application]:[id]/css/objects.css?_foo=bar'

Tested with portal.assetUrl(params) and portal.serviceUrl(params), other portal.*Url(params) methods might be affected as well.

Is this a bug, or by (undocumented) design?

[sigdestad]

Hi. If you are using portal functions in javascript controllers, you are not following the spec properly: http://repo.enonic.com/public/com/enonic/xp/docs/6.11.1/docs-6.11.1-libdoc.zip!/module-portal.html#.serviceUrl

As such you should write portal.portal.serviceUrl({ service: 'counter', params: { name: 'counter', foo: 'bar' } });

[cfenzo]

Hi,

Yes, I'm aware of the params property for url parameters.

The question was, and still is: is it a bug, or by design, that any parameters passed to serviceUrl that doesn't match the properties in the docs is converted to _-prefixed parameters in the returned url?

The reason I'm asking is because we discovered this when we encountered an issue during the 201-class. The property used to identify the service was changed in 6.7.0, from name to service, but docs.enonic.com is using the name property (reported in #5646).

This caused a lot of confusion, since participants looking up service on docs.enonic.com ended up with wrong service urls like */_/service/[application]?_name=[service_name], but those using the js docs got correct urls (*/_/service/[application]/[service_name]).

[jsi]

Reopening this, since the last question from Jens Anders has not been answered.

[sigdestad]

Lets improve this so only the actually supported params are handled, otherwise it should fail!

[aro]

@sigdestad I think we should ignore the not supported parameters, just not include them in the URL.

If we make it fail when there are extra parameters we are going to break apps that have been working until now.

[GlennRicaud]

+1 for ignoring the parameters not supported