hello justin. i understand you concerns and see what you are pointing at. i hit the problem as well at the same time wanting to have single valuemap with all parameters and application separation or parameter names. i'm open to removing the parameter<> stuff from the main API, it can always added as a layer on-top.
but carsten introduced a new idea, lets discuss this first. stefan >-----Original Message----- >From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of >Justin Edelson >Sent: Wednesday, October 15, 2014 2:50 AM >To: dev@sling.apache.org >Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, >Multitenancy > >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
