On Fri, Mar 15, 2013 at 1:45 PM, Vincent Massol <vinc...@massol.net> wrote: > Hi, > > On Mar 15, 2013, at 1:21 PM, Eduard Moraru <enygma2...@gmail.com> 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.
s/xcontext/script context/ The idea was to keep the script bindings at a minimum so that it's not a nightmare to find names for variables you want to use in your script. > >> 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 I don't exactly see that in http://markmail.org/message/mv7psxctupfjkcu2 ;) > >> 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 > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs If your "proposal" if to keep XWikiMessageTool it's a big -1 for me, it simply does not make any sense. I'm OK to vote some shortcut binding for $services.localization but that's it. -- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
