hello justin. yes, this is my expectation for the java code. if you only provide a string-based access to configuration parameter every developer will start to create a "NameConstants" class to define the much-used property names (or you will provide such a class as part of your applications API). then the developer has to remember which type belongs to which string constant. then you have to find a way where you define the default values of a parameter, and describe its edit mode capabilities. all this is covered by building a structured parameter definition. but yes, it started as a simple helper class with constants to easy access all existing parameters of an application.
as a bonus there is an abstract implementation of the "ParameterProvider" interface which just reads the static fields of such a class and provides the defined parameters as OSGi service to the config infrastructure. you still need the string-based (or map-based) access for usecases like sightly templates where it is not so easy or uncommon to use constants for accessing map values. but in our experience the parameters are used in most cases in the java business logic behind the presentation layer, not in the presentation layer (scripts) itself. and of course the lazy developers can use this access at well in java code... stefan >-----Original Message----- >From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of >Justin Edelson >Sent: Tuesday, October 14, 2014 11:32 PM >To: dev@sling.apache.org >Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, >Multitenancy > >Hi Stefan, >Thanks for clarifying. So is it accurate to say that your expectation >that the *vast* majority of clients to use a strongly-typed Parameter >object rather than doing a simple String lookup? > >To me, this seems very heavyweight, but maybe I am being short sighted >(or lazy). > >But on the other hand, if you expect clients to use Paramter objects, >why support String lookup at all? > >Justin
