[xwiki-devs] [Discussion] Why drop the $msg script binding in the future?
Are we sure we want to drop the $msg binding in the future [1]? Compared to other services, $services.localization would be used heavily 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') 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? 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. This transition should IMO be smoother 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. Basically, I`m proposing to apply the KIS(s) principle. :) WDYT? Thanks, Eduard ---------- [1] http://markmail.org/message/atrshzt3mlscfedc
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
On Fri, Mar 15, 2013 at 1:45 PM, Vincent Massol <[email protected]> wrote:
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.
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 [email protected] 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
On Mar 15, 2013, at 2:00 PM, Thomas Mortagne <[email protected]> wrote:
On Fri, Mar 15, 2013 at 1:45 PM, Vincent Massol <[email protected]> wrote:
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.
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 ;)
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
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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
The proposal about XWikiMessageTool was just a thought on how we could preserve the current behaviour. Practically, there are 2 main aspects to consider: 1) Ease of use: Internationalization is a key aspect in the platform, not just another service that may or may not be important, so I think that in the past, when using $msg, it was given the proper importance and ease of use. We must not lose that to flexibility. Also, consider the fact that non-technical users are already confused by the $msg.get() calls in a document's title and content, seeing a longer technical string won't help them much. Scripting also needs to be quick an fun. Over-engineering it throws people away. 2) Semantics: I am not fond of the render() method when it concerns translation keys. I, as a regular dev that wants to script something, do not care about the fact that the XDOM is involved and that the translation is first retrieved and then rendered and all that mumbo-jumbo. For me, a translation is something that is retrieved by providing a key, in a more or less Map(/Hashtable) oriented manner, with a get() action. I understand that when you add translation parameters and choices in the translation's content things could get a bit funkier, but IMO we don`t need to get that technical for no reason. IMO render is a bit confusing and, since a "public Translation get(String key)" method exists on the service, it will be the cause for many useless errors. Anyway, these are my concerns. If they are not shared, then I guess we`ll just let time decide if they were justified or not. Thanks, Eduard On Fri, Mar 15, 2013 at 3:00 PM, Thomas Mortagne <[email protected]>wrote:
On Fri, Mar 15, 2013 at 1:45 PM, Vincent Massol <[email protected]> wrote:
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.
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 [email protected] 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
You seems to forget an important thing here: it's not all about velocity. We used to have to use velocity to display translations but it's not true anymore and you should always use the macro as much as possible because it's a lot safer and also a bit better for performances. On Fri, Mar 15, 2013 at 2:23 PM, Eduard Moraru <[email protected]> wrote:
The proposal about XWikiMessageTool was just a thought on how we could preserve the current behaviour.
Practically, there are 2 main aspects to consider:
1) Ease of use: Internationalization is a key aspect in the platform, not just another service that may or may not be important, so I think that in the past, when using $msg, it was given the proper importance and ease of use. We must not lose that to flexibility. Also, consider the fact that non-technical users are already confused by the $msg.get() calls in a document's title and content, seeing a longer technical string won't help them much. Scripting also needs to be quick an fun. Over-engineering it throws people away.
2) Semantics: I am not fond of the render() method when it concerns translation keys. I, as a regular dev that wants to script something, do not care about the fact that the XDOM is involved and that the translation is first retrieved and then rendered and all that mumbo-jumbo. For me, a translation is something that is retrieved by providing a key, in a more or less Map(/Hashtable) oriented manner, with a get() action. I understand that when you add translation parameters and choices in the translation's content things could get a bit funkier, but IMO we don`t need to get that technical for no reason. IMO render is a bit confusing and, since a "public Translation get(String key)" method exists on the service, it will be the cause for many useless errors.
Anyway, these are my concerns. If they are not shared, then I guess we`ll just let time decide if they were justified or not.
Thanks, Eduard
On Fri, Mar 15, 2013 at 3:00 PM, Thomas Mortagne <[email protected]>wrote:
On Fri, Mar 15, 2013 at 1:45 PM, Vincent Massol <[email protected]> wrote:
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.
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 [email protected] 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mar 15, 2013, at 2:23 PM, Eduard Moraru <[email protected]> wrote:
The proposal about XWikiMessageTool was just a thought on how we could preserve the current behaviour.
Practically, there are 2 main aspects to consider:
1) Ease of use: Internationalization is a key aspect in the platform, not just another service that may or may not be important, so I think that in the past, when using $msg, it was given the proper importance and ease of use. We must not lose that to flexibility. Also, consider the fact that non-technical users are already confused by the $msg.get() calls in a document's title and content, seeing a longer technical string won't help them much.
Again that's why we have the translation macro…
Scripting also needs to be quick an fun. Over-engineering it throws people away.
I wouldn't call clear variable naming over-engineering...
2) Semantics: I am not fond of the render() method when it concerns translation keys. I, as a regular dev that wants to script something, do not care about the fact that the XDOM is involved and that the translation is first retrieved and then rendered and all that mumbo-jumbo. For me, a translation is something that is retrieved by providing a key, in a more or less Map(/Hashtable) oriented manner, with a get() action. I understand that when you add translation parameters and choices in the translation's content things could get a bit funkier, but IMO we don`t need to get that technical for no reason. IMO render is a bit confusing and, since a "public Translation get(String key)" method exists on the service, it will be the cause for many useless errors.
TBH I was also a bit thrown off by the render() method when I saw it. Thanks -Vincent
Anyway, these are my concerns. If they are not shared, then I guess we`ll just let time decide if they were justified or not.
Thanks, Eduard
On Fri, Mar 15, 2013 at 3:00 PM, Thomas Mortagne <[email protected]>wrote:
On Fri, Mar 15, 2013 at 1:45 PM, Vincent Massol <[email protected]> wrote:
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.
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
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: > 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. Well... it's complicated. We would also remove $xwiki in the future? maybe $xcontext as well? it will all be prefixed with $services? 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?) > > 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="…"/}} 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). > >> 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? 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? > >> 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 :) See above. > > 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) if that set could be #set($msg.get = $services.localization.render) then sure, I agree with this solution. Thanks, Anca > > 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
On Mon, Apr 15, 2013 at 7:14 PM, Anca Luca <[email protected]> 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:
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.
Well... it's complicated. We would also remove $xwiki in the future? maybe $xcontext as well? it will all be prefixed with $services?
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.
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?)
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="…"/}}
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).
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?
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?
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 :)
See above.
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)
if that set could be #set($msg.get = $services.localization.render) then sure, I agree with this solution.
Thanks, Anca
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (4)
-
Anca Luca -
Eduard Moraru -
Thomas Mortagne -
Vincent Massol