Hi Stefan,
To me, this sounds a bit schizophrenic - you're saying that the
preferred way is to use a Parameter object, but that we need to
support String-based lookup. And I'm not actually sure what "which
type belongs to which string constant" actually means.
Above all, this seems to create a confusing API. Since the expectation
is that String-based lookups will work consistently, there's
effectively no way to use the extra data within the Parameter object
inside the lookup mechanism. For example, you mentioned the idea of
using the application ID from the Parameter object as a way of
expressing scope. But of course, this can't actually happen because
there would be no way to do this with just Strings.
I also personally find the setting of the default at the Parameter
level a bit confusing. IME, defaults are *very* context-sensitive,
whereas (if I understand) the Parameter objects are meant to be used
across-contexts.
All of which is to say that I would rather see the API have a clean
separation between configuration lookup (which can be done purely with
Strings) and Parameter definition. Or, to put in AEM terms, separate
the functionality common to author & publish (configuration lookup)
from the author-side functionality (parameter defintion which leads to
editing).
At this point, Configuration just becomes Map<String, ValueMap>. The
keys are are the application IDs and the resulting maps are the actual
configurations for that application (which frankly I'd rather see
called 'component' but that's neither here nor there). The only
deviation I'd suggest from normal Map behavior is that
config.get("non-existing-application-id") should return an empty
ValueMap. This would allow you to do null-safe chaining, e.g.
config.get("foo").get("bar") could return null, but never throw an NPE
(unless config itself is null)
If developers choose to adopt the Parameter objects, that's fine.
Perhaps we even should have a utility method
ConfigurationUtils.get(config, param) which calls
config.get(param.getApplicationId()).get(param.getName(),
param.getType()) But this is an optional step and the use of Parameter
objects isn't implied by the Configuration API.
Regards,
Justin
On Tue, Oct 14, 2014 at 6:58 PM, Stefan Seifert <sseif...@pro-vision.de> wrote:
> 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
