9 Feb
2012
9 Feb
'12
6:21 p.m.
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/
15 Feb
15 Feb
8:43 a.m.
On Thu, Feb 9, 2012 at 7:21 PM, Jerome Velociter <jerome(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:24 p.m.
On Wed, Feb 15, 2012 at 8:43 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
I do too
Jerome
On Thu, Feb 9, 2012 at 7:21 PM, Jerome Velociter
<jerome(a)winesquare.net> wrote:
Right
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
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
WDYT ? Do you have other ideas ?
Jerome.
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
4 May
4 May
4:13 p.m.
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(a)winesquare.net>wrote;wrote:
On Wed, Feb 15, 2012 at 8:43 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Right
I do too
Jerome
On Thu, Feb 9, 2012 at 7:21 PM, Jerome Velociter
<jerome(a)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
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
WDYT ? Do you have other ideas ?
Jerome.
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
9 May
9 May
9:39 a.m.
On Fri, May 4, 2012 at 4:13 PM, Eduard Moraru <enygma2002(a)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(a)winesquare.net
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
wrote:
On Wed, Feb 15, 2012 at 8:43 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
> On Thu, Feb 9, 2012 at 7:21 PM, Jerome Velociter <
jerome(a)winesquare.net>
wrote:
Right
I do too
Jerome
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
WDYT ? Do you have other ideas ?
Jerome.
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
11:50 a.m.
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-tp726…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
14 May
14 May
12:31 p.m.
On Wed, May 9, 2012 at 12:50 PM, jerem <jeremie.bousquet(a)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-tp726…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
18 Jul
18 Jul
2:44 p.m.
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(a)gmail.com> wrote:
On Wed, May 9, 2012 at 12:50 PM, jerem
<jeremie.bousquet(a)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-tp726…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2973
days inactive
4594
days old
7 comments
5 participants
participants (5)
-
Denis Gervalle -
Eduard Moraru -
jerem -
Jerome Velociter -
Marius Dumitru Florea