Hi,
On Mar 15, 2013, at 1:21 PM, Eduard Moraru <[email protected]> wrote:
> Are we sure we want to drop the $msg binding in the future [1]?
IMO yes, for consistency, but it's a good question to ask. It's not just about
$msg but about all bindings. If we allow "shortcut aliases for bindings" we
need to make this general and allow any services binding to offer shortcuts.
One reason we introduced $services was to keep the xcontext namespace free for
applications to use.
> Compared to other services, $services.localization would be used heavily
I had personally proposed "l10n" to make it a bit shorter but it wasn't
accepted. My proposal was: $services.l10n
> inside scripts and we would basically have 2 options:
> 1. use $services.localization.render('key') (you fall asleep writing this
> every time)
> 2. always declare a variable in your script like #set ($keys =
> $services.localization) and then do $keys.render('key')
3. Use the translation macro if you're in wiki pages: {{translation key="…"/}}
> AFAIK, we have already considered in the past that a similarly used service
> like $services.model is already becoming a bit annoying having to write the
> oh-so-very-long "$services.model.createDocumentReference(wiki,
> space,name)"; do we want to get the same effect with the new localization
> module?
@Edy, we really need to commit the auto completion feature ;)
> I understand and agree that the new localization module is more powerful
> and flexible than the XWikiMessageTool, but I feel that those new features
> are not required in day to day use and unnecessarily crowd/pollute the
> regularly used API.
You're loosing me here. I thought you were only talking about the binding name
and here you start to say that you want to go back to XWikiMessageTool?
> This transition should IMO be smoother
Smoother than what?
> and with less impact than what is
> currently being proposed. If the new localization module can provide all
> the features of the XWikiMessageTool, then I propose that we simply reuse
> the $msg binding as it is and, in the background, transform
> XWikiMessageTool into a facade (as I see we have already pretty much done
> to preserve backwards compatibility), but agree that we *keep* $msg as the
> simplified translations binding, to be used in day to day operations and,
> for more complex tasks, the dev needs to use $services.localization instead.
I don't understand what you mean. If your idea is to get $msg.get() rather than
$msg.render() which is the new API then I don't agree. If what you propose is
just to have a generic "script service alias" notion where $msg would be the
same as $services.localization then I'm more inclined to think about it :)
BTW I would not want to reuse the same name ($msg) because it's misleading.
> Basically, I`m proposing to apply the KIS(s) principle. :)
Another option is to not change anything at the level of java (i.e. no "script
service alias") but in xwikivars.vm add a velocity variable named $l10n:
#set ($l10n = $services.localization)
This is basically your option 2) above but made generic by putting it in
xwikivars.vm.
Thanks
-Vincent
> WDYT?
>
> Thanks,
> Eduard
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
