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

Access current bindingContext in filters - is it possible to do this? #27

Open
helmut-hoffer-von-ankershoffen opened this issue Aug 23, 2014 · 1 comment

Comments

@helmut-hoffer-von-ankershoffen

Background: we built a "trans" (translation) filter - that actually uses translation messages of a Symfony2 backend - and can be used e.g. like so:

{{ 'translate-this' | trans : 'translation-domain' }}

We want to be able to set the default translation domain like so
{{# transDefaultDomain: 'whatever' }}
{{ 'translate-this' | trans }}
{{ 'and-this' | trans }}
{{/ transDefaultDomain }}

so that for multiple translations the domain has not to be given per element ...

Therefore our trans-filter needs to access the current binding context ...

Best Regards

P.S.: We love your extension.

@mbest
Copy link
Owner

mbest commented Aug 25, 2014

I'm hesitant to pass in the binding context or any other fixed parameters mainly because I'd like to keep the filter interface simple.

Another idea that could help is to support a per-filter preprocesor. Then you could set up something like the following:

ko.filter.trans.preprocess = function (arguments) {
    return arguments || "$context.domain";
}

For now, you can add a preprocessor function to the text binding that adds the parameter:

ko.punches.utils.addBindingPreprocessor('text', function (input) {
    return input.replace(/\| *trans/, "| trans:$context.domain");
});

(My example isn't very robust. It'll break instances of a filter that begins with "trans" or where "trans" is specified with an argument.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants