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