[xwiki-devs] Convention for class property hints ?
Hello, Right now class property hints are not supported right in the core of XWiki (though it's been mentioned as a possible future item of the roadmap for AWM, see http://markmail.org/message/ltuphlj7bnnso2yb ). Once this will be implemented, it will rely on i18n message keys so that hints are localizables (same strategy as for class property pretty names) I'd like to start the discussion and see if we can agree on a convention that would be used in the future when this module is implemented. The reason for this is I'm starting to work on a LDAP admin UI, and I find that their field pretty names are not self-explanatory. It's not a matter of expression, it's just the fact that what they describe needs more explanation than what the pretty name can offer). In this light, I'm planning on displaying such longer hints in this admin section. Right now the format for a pretty name is : Space.Class_property=Pretty name The format for a hint could be something like : Space.Class_property.xHint=Hint This would need escaping rules I think, since I believe "property.xHint" is a valid property name Note that I use "xHint" and not "hint" to be consistent with the form standards class names. This can be discussed though. WDYT ? Do you have other ideas ? Jerome. -- Jérôme Velociter Winesquare http://www.winesquare.net/
On Thu, Feb 9, 2012 at 7:21 PM, Jerome Velociter <jerome@winesquare.net> wrote:
Hello,
Right now class property hints are not supported right in the core of XWiki (though it's been mentioned as a possible future item of the roadmap for AWM, see http://markmail.org/message/ltuphlj7bnnso2yb ). Once this will be implemented, it will rely on i18n message keys so that hints are localizables (same strategy as for class property pretty names) I'd like to start the discussion and see if we can agree on a convention that would be used in the future when this module is implemented. The reason for this is I'm starting to work on a LDAP admin UI, and I find that their field pretty names are not self-explanatory. It's not a matter of expression, it's just the fact that what they describe needs more explanation than what the pretty name can offer). In this light, I'm planning on displaying such longer hints in this admin section.
Right now the format for a pretty name is : Space.Class_property=Pretty name
The format for a hint could be something like : Space.Class_property.xHint=Hint
+1
This would need escaping rules I think, since I believe "property.xHint" is a valid property name
I don't think we need escaping because the translation key is never parsed. We just compute it from the class and property name. 'Space.Class_property.xHint.xHint' is a valid key for 'property.xHint'.
Note that I use "xHint" and not "hint" to be consistent with the form standards class names. This can be discussed though.
I prefer hint. Thanks, Marius
WDYT ? Do you have other ideas ?
Jerome.
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Feb 15, 2012 at 8:43 AM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
On Thu, Feb 9, 2012 at 7:21 PM, Jerome Velociter <jerome@winesquare.net> wrote:
Hello,
Right now class property hints are not supported right in the core of XWiki (though it's been mentioned as a possible future item of the roadmap for AWM, see http://markmail.org/message/ltuphlj7bnnso2yb ). Once this will be implemented, it will rely on i18n message keys so that hints are localizables (same strategy as for class property pretty names) I'd like to start the discussion and see if we can agree on a convention that would be used in the future when this module is implemented. The reason for this is I'm starting to work on a LDAP admin UI, and I find that their field pretty names are not self-explanatory. It's not a matter of expression, it's just the fact that what they describe needs more explanation than what the pretty name can offer). In this light, I'm planning on displaying such longer hints in this admin section.
Right now the format for a pretty name is : Space.Class_property=Pretty name
The format for a hint could be something like : Space.Class_property.xHint=Hint
+1
This would need escaping rules I think, since I believe "property.xHint" is a valid property name
I don't think we need escaping because the translation key is never parsed. We just compute it from the class and property name. 'Space.Class_property.xHint.xHint' is a valid key for 'property.xHint'.
Right
Note that I use "xHint" and not "hint" to be consistent with the form standards class names. This can be discussed though.
I prefer hint.
I do too Jerome
Thanks, Marius
WDYT ? Do you have other ideas ?
Jerome.
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
Hi, As I have come to see with the user profile section name [1], relying on translation key conventions as the only mechanism of specifying a label/hint/string is not a clean and productive solution at all. This is why I suggest that we add a new metadata for class properties called 'hint' where we can enter either a static string or a call to the message tool with the key we wish to use. See [2] for more details. Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XWIKI-7690 [2] http://jira.xwiki.org/browse/XWIKI-7783 On Wed, Feb 15, 2012 at 3:24 PM, Jerome Velociter <jerome@winesquare.net>wrote:
On Wed, Feb 15, 2012 at 8:43 AM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
On Thu, Feb 9, 2012 at 7:21 PM, Jerome Velociter <jerome@winesquare.net> wrote:
Hello,
Right now class property hints are not supported right in the core of XWiki (though it's been mentioned as a possible future item of the roadmap for AWM, see http://markmail.org/message/ltuphlj7bnnso2yb ). Once this will be implemented, it will rely on i18n message keys so that hints are localizables (same strategy as for class property pretty names) I'd like to start the discussion and see if we can agree on a convention that would be used in the future when this module is implemented. The reason for this is I'm starting to work on a LDAP admin UI, and I find that their field pretty names are not self-explanatory. It's not a matter of expression, it's just the fact that what they describe needs more explanation than what the pretty name can offer). In this light, I'm planning on displaying such longer hints in this admin section.
Right now the format for a pretty name is : Space.Class_property=Pretty name
The format for a hint could be something like : Space.Class_property.xHint=Hint
+1
This would need escaping rules I think, since I believe "property.xHint" is a valid property name
I don't think we need escaping because the translation key is never parsed. We just compute it from the class and property name. 'Space.Class_property.xHint.xHint' is a valid key for 'property.xHint'.
Right
Note that I use "xHint" and not "hint" to be consistent with the form standards class names. This can be discussed though.
I prefer hint.
I do too
Jerome
Thanks, Marius
WDYT ? Do you have other ideas ?
Jerome.
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Fri, May 4, 2012 at 4:13 PM, Eduard Moraru <enygma2002@gmail.com> wrote:
Hi,
As I have come to see with the user profile section name [1], relying on translation key conventions as the only mechanism of specifying a label/hint/string is not a clean and productive solution at all.
Could you elaborate a bit, and explain why ? (I am asking since I use for my commercial product translation key conventions for data units, table headers, etc... and I have found them really clean and productive.)
This is why I suggest that we add a new metadata for class properties called 'hint' where we can enter either a static string or a call to the message tool with the key we wish to use. See [2] for more details.
Thanks, Eduard
---------- [1] http://jira.xwiki.org/browse/XWIKI-7690 [2] http://jira.xwiki.org/browse/XWIKI-7783
On Wed, Feb 15, 2012 at 3:24 PM, Jerome Velociter <jerome@winesquare.net
wrote:
On Wed, Feb 15, 2012 at 8:43 AM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
On Thu, Feb 9, 2012 at 7:21 PM, Jerome Velociter < jerome@winesquare.net> wrote:
Hello,
Right now class property hints are not supported right in the core of XWiki (though it's been mentioned as a possible future item of the roadmap for AWM, see http://markmail.org/message/ltuphlj7bnnso2yb ). Once this will be implemented, it will rely on i18n message keys so that hints are localizables (same strategy as for class property pretty names) I'd like to start the discussion and see if we can agree on a convention that would be used in the future when this module is implemented. The reason for this is I'm starting to work on a LDAP admin UI, and I find that their field pretty names are not self-explanatory. It's not a matter of expression, it's just the fact that what they describe needs more explanation than what the pretty name can offer). In this light, I'm planning on displaying such longer hints in this admin section.
Right now the format for a pretty name is : Space.Class_property=Pretty name
The format for a hint could be something like : Space.Class_property.xHint=Hint
+1
This would need escaping rules I think, since I believe "property.xHint" is a valid property name
I don't think we need escaping because the translation key is never parsed. We just compute it from the class and property name. 'Space.Class_property.xHint.xHint' is a valid key for 'property.xHint'.
Right
Note that I use "xHint" and not "hint" to be consistent with the form standards class names. This can be discussed though.
I prefer hint.
I do too
Jerome
Thanks, Marius
WDYT ? Do you have other ideas ?
Jerome.
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Why not both ? As in livetables, if you specify "displayName" for a column, it will use it, if not it will use a default-ly built message key to find the display name. Vertical forms would use the hint hard-coded in class properties (if any), or use the message tool with the key you propose if not - or you can call $msg.get('myname') from class properties if you want another key than the default. -- View this message in context: http://xwiki.475771.n2.nabble.com/Convention-for-class-property-hints-tp7269... Sent from the XWiki- Dev mailing list archive at Nabble.com.
On Wed, May 9, 2012 at 12:50 PM, jerem <jeremie.bousquet@gmail.com> wrote:
Why not both ? As in livetables, if you specify "displayName" for a column, it will use it, if not it will use a default-ly built message key to find the display name. Vertical forms would use the hint hard-coded in class properties (if any), or use the message tool with the key you propose if not - or you can call $msg.get('myname') from class properties if you want another key than the default.
That's what I was saying. You need to be able to: 1) Specify your own String from the UI OR 2) (optionally) Specify your own translation key from the UI OR 3) Fall back on a default translation key convention 4) (optionally) Make up your own translation key convention When talking about class property hints, right now we only have options 3) and 4) which work fine if you are an admin and are ok with editing ApplicationResources.properties or with going into Adminsitration and registering a new translations bundle. However, if you are a regular user that wants to create a class/application, you are *forced* to statically write your hints in the actual code, for each property individually, since you have no API for retrieving the hints dynamically (translations is not an option since you can`t register translation keys). Also, if you want to make a second display page, you have to statically write the hints in the code *again*, because the class itself does not allow you to specify property hints, just like you can do with pretty names. We already do something very similar for the class property pretty names (1, 3 and 4), so why wouldn`t we do it for hints as well? (With the extra ability to call $msg for a specific translation key - 2) Thanks, Eduard
-- View this message in context: http://xwiki.475771.n2.nabble.com/Convention-for-class-property-hints-tp7269... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi, FTR, we`ve eventually started using "hint", as exemplified in http://dev.xwiki.org/xwiki/bin/view/Community/L10N+Conventions Thanks, Eduard On Mon, May 14, 2012 at 1:31 PM, Eduard Moraru <enygma2002@gmail.com> wrote:
On Wed, May 9, 2012 at 12:50 PM, jerem <jeremie.bousquet@gmail.com> wrote:
Why not both ? As in livetables, if you specify "displayName" for a column, it will use it, if not it will use a default-ly built message key to find the display name. Vertical forms would use the hint hard-coded in class properties (if any), or use the message tool with the key you propose if not - or you can call $msg.get('myname') from class properties if you want another key than the default.
That's what I was saying.
You need to be able to: 1) Specify your own String from the UI OR 2) (optionally) Specify your own translation key from the UI OR 3) Fall back on a default translation key convention 4) (optionally) Make up your own translation key convention
When talking about class property hints, right now we only have options 3) and 4) which work fine if you are an admin and are ok with editing ApplicationResources.properties or with going into Adminsitration and registering a new translations bundle.
However, if you are a regular user that wants to create a class/application, you are *forced* to statically write your hints in the actual code, for each property individually, since you have no API for retrieving the hints dynamically (translations is not an option since you can`t register translation keys). Also, if you want to make a second display page, you have to statically write the hints in the code *again*, because the class itself does not allow you to specify property hints, just like you can do with pretty names.
We already do something very similar for the class property pretty names (1, 3 and 4), so why wouldn`t we do it for hints as well? (With the extra ability to call $msg for a specific translation key - 2)
Thanks, Eduard
-- View this message in context: http://xwiki.475771.n2.nabble.com/Convention-for-class-property-hints-tp7269... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Denis Gervalle -
Eduard Moraru -
jerem -
Jerome Velociter -
Marius Dumitru Florea