Note that a bug has been opened to track this:
https://www.osgi.org/members/bugzilla/show_bug.cgi?id=2464.
John
>
> Re: [osgi-dev] [metatype] custom properties for OCD/AD?
>
> -----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
>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
