-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/25/12 7:34 AM, Felix Meschberger wrote: > Hi, > > Am 24.10.2012 um 16:13 schrieb Jan Willem Janssen: > >> Hi, >> >> The default interfaces for OCD/AD provide just enough information >> to build a generic configuration editor for Metatype'd >> configurations. >> >> However, on can think of use cases in which the editor needs >> additional 'hints' in order to provide a better user experience. >> For example, one could think of an attribute that provides the >> user a list of predefined options, > > This already exists in the form of the option elements in the > descriptor and the optionValues() and optionLabels() methods in the > AttributeDefinition interface. > >> *or* allows him/her to type another option (not in the list). > > The option values are also used for validation of attributes and > are currently defined to be decisive: If an attribute's value is > not one of the listed ones it is invalid. > > I could imagine, that it would make sense to have another option to > indicate the options to be "proposals" rather than "a decisive > list".
This would be a helpful addition, in my opinion, if the proposals are rather static. One additional use case I'd can think of is: suppose we have a property for which an auto-completion functionality is desired, but not on others. Adding such property to AttributeDefinition would make no sense in most of its use cases, as its merely an aid when using a UI-editor for editing the metatype'd configuration. >> While it is certainly not an option to extend the MetaType spec >> with all kinds of fancy options for UI-builders, might it not be >> an idea to add a kind of "free-format" field to the OCD/AD for >> these kinds of situations? > > I am not a big fan of "free-format" or "interpret as you like" > stuff in a specification. Because this gives way to implementation > dependencies which are hard to handle in a deployment case. Normally, I do not like such fields as well. However, the alternative would be to "misuse" another field (for example, description) for such facility. As the main constraints of the attribute are properly defined and remain valid, the validation should remain correct and leading. Maybe we could add a Dictionary (akin to the service registry) to AttributeDefinition instead of a "free-format field" to make it less free format? - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is:/ Luminis Technologies B.V. IJsselburcht 3 6825 BS Arnhem +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQiVFqAAoJEKF/mP2eHDc4R68P/A31q7XPiXkTk5hOodwJQDu1 s4IpitRCxweqzmbdwkJ3zjJunVAohq4ckexq7m8glW4yV163sQk29uXMqVmyfjzu mYfBK7x/Gw768lJAUXi0mUHUP1EWlH0aiWWME/esxEoHANeNi7sL7uJ6xe/quuaW nTLaqBVjZ4Idq5SSug83BZHhHUG1V8ws/affZ6B/3m9UdG69OW/GnHwz7B0pzlSI aYy7AFpTN9+TSE8gAYfe0FW/CY7WRMY3AMmjcf40rvWfgov9CHWdpITe9bB4qp9u u4T/GfvlPU6JOZytSQT0xgqIvWZeXQAc14/9PZjCzgcpgdGxifPNO3TxwTaq7c1w RBdzpjBnxU9N8y9b9KHGlpnnw8PotJGmpePJN/660B7rFRZvNd/4zjPoS/1hg75H ltJmOLdhr4grhhQMk/epLZNQ67w2NXx1Xml8cUiLM4VmJJvxJr7o+PCOAapHtU6g nnXCbeaICqgKCaREWX7A5vwc5qji0AkBgjHWQDClbngZPTkj3LUwyRLU/nq/toFH gxQmOT4wPr2adBIObInEjk4fRBqKEwAjx1S5nMNAThCsVFgPRhYVE/7n+utTG8g3 270bg+VaA9yUh0XTF7GpYeFqC9jgTg+l9DtPe1VvmH8ZdITIQvW40DzO7r8iogs6 CmtUo8+xqKDRNP/4+Ngd =8dvN -----END PGP SIGNATURE----- _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
