15 Apr
2013
15 Apr
'13
7:24 p.m.
On Mon, Apr 15, 2013 at 7:14 PM, Anca Luca <lucaa(a)xwiki.com> wrote:
Hi all,
a bit late to the party, I just found out today that $msg.get is now
deprecated.
On 03/15/2013 01:45 PM, Vincent Massol wrote:
Of course we want to remove $xwiki and $xcontext, first because we
want to get rid of XWikiContext/Context and stop use that crappy all
in one XWiki class and second because yes we want to go trough
services.
The main use cases remaining for theses two bindings should be covered
by a script service coming with the new model.
Hi,
On Mar 15, 2013, at 1:21 PM, Eduard Moraru<enygma2002(a)gmail.com> wrote:
Well... it's complicated. We would also remove $xwiki in the future? maybe
$xcontext as well? it will all be prefixed with $services? 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.
I think that while it's a good idea for code beauty reasons, it's highly
impractical. Script authors are already used with $msg.get(), the new
$services.localization.render() does at least the same thing as $msg.get (or
doesn't it?), it's longer to write **and to read** ("services" itself
is
longer than "msg.get" so no matter what you put after, it's already
longer)
, and it will generate tons and tons and tons and tons and tons (I cannot
emphasize this enough) of logs saying that script X is using a deprecated
function, until you change all your scripts and all the extensions on
extensions.xwiki.org so that when you install something your logs are still
readable (or maybe we can disable these logs?)
I think what Edi means, and I agree with him, is that he doesn't really
understand why can't we just have the old $msg.get function call the new
localization service and be done with it?
See above.
if that set could be
#set($msg.get = $services.localization.render)
then sure, I agree with this solution.
Thanks,
Anca
--
Thomas Mortagne
One reason we introduced $services was to keep the xcontext namespace free
for applications to use.
This is, imho, a little quarter of a solution. In practice, html macro with
wiki=false is used far more than we'd like.
Now, sure, we can choose to ignore that, but that would be another
discussion.
Also, the problem of all 3 solutions above is that they require refactoring
of a lot of code (I for one use a lot the localization tool, not only for
localization, but also to make it easy for people that don't know code to
decide what the interface of the application should say).
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.
Why would that be misleading? Isn't the new localization service an
improvement of the old one? It's a new tool?
Since I contribute less and less, I am now more a user of the xwiki platform
than a developer of it, and honestly, as a user, I perceive the work that
was done on localization as an improvement of what was there before and I
don't like the idea that for an improvement of the platform I use I need to
rewrite all my code, and use a new, longer, function call, and learn new
function names et all: as a script author, I'm actually doing the same thing
but now I shuld change my whole code to do the same thing in a different
way, because the platform was improved.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs WDYT?
Thanks,
Eduard
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs