15 Mar
2013
15 Mar
'13
2:06 p.m.
On Mar 15, 2013, at 2:00 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Mar 15, 2013 at 1:45 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I don't exactly see that in http://markmail.org/message/mv7psxctupfjkcu2 ;)
Indeed, my preference was for l10n (for the length reason) but I didn't express it.
Don't recall why. Maybe I didn't want to block anything seeing that everyone
agreed with localization ;)
Thanks
-Vincent
Hi,
On Mar 15, 2013, at 1:21 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs