Hi everyone,
just added my comment to the mentioned usecase page at [0]. Please note
that the solutions I've extracted that from were partially ui driven so I
had to abstract quite a lot to get generic requirements out of those. This
also means that it might still be a bit ui oriented which I woul
Hi Stefan,
On Fri, Oct 17, 2014 at 2:08 PM, Stefan Seifert wrote:
> ...the alternative storing at /conf is already implemented [1] - it's up to
> the system configuration which persistence provider is used...
Ok, now I remember reading this earlier in this thread. Sorry about
the noise, it's a l
hello Bertrand.
>On Fri, Oct 17, 2014 at 11:56 AM, Stefan Seifert
>wrote:
>> ... https://cwiki.apache.org/confluence/x/1ATTAg ...
>
>Thanks for this. Looking at your use-cases it feels like your context
>is always derived from the current resource's position in the content
>tree, am I correct?
y
Hi Stefan,
On Fri, Oct 17, 2014 at 11:56 AM, Stefan Seifert wrote:
> ... https://cwiki.apache.org/confluence/x/1ATTAg ...
Thanks for this. Looking at your use-cases it feels like your context
is always derived from the current resource's position in the content
tree, am I correct?
If yes that e
--
>From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
>Sent: Wednesday, October 15, 2014 4:01 PM
>To: dev
>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
>Multitenancy
>
>On Wed, Oct 15, 2014 at 3:48 PM, Stefan Seifert
>wrote:
>&
Am 15.10.14 um 15:40 schrieb Justin Edelson:
> Hi Carsten,
> I have two concerns with this model:
> 1) Creating an annotation class can be a bit heavyweight. If I want to
> just store a common value used across multiple scripts, doing so would
> require creating this class, compiling it, deploying
On Wed, Oct 15, 2014 at 3:48 PM, Stefan Seifert wrote:
> ...this does not match the experience of our projects. we need those
> parameters only in rare occasions directly
> in the scripts (e.g. sightly)...
As usual, IMO having a shared list of use cases (wiki?) would help a
lot in getting consen
>[...] But to my
>mind, one of the key targets for this new configuration structure is
>scripts.
this does not match the experience of our projects. we need those parameters
only in rare occasions directly in the scripts (e.g. sightly), and in most time
in the java code (models the scripts, dif
Hi Carsten,
I have two concerns with this model:
1) Creating an annotation class can be a bit heavyweight. If I want to
just store a common value used across multiple scripts, doing so would
require creating this class, compiling it, deploying the bundle, etc.
vs. just adding a node property and re
>However, one downside would be that you don't have hierarchical
>configurations or maps - just scalar types and arrays of it.
support for maps we can add using a helper method - internally its stored as
string array anyway.
hierarchical configurations could be modeled using annotation properti
Am 15.10.14 um 10:56 schrieb Stefan Seifert:
>
>>> do you have a link where such a concept is defined in context of the
>>> new DS specification? using the same concept as a (new) DS version
>>> would be plus.
>> Sure, the spec can be found here
>> https://github.com/osgi/design/blob/master/rfcs/r
>> do you have a link where such a concept is defined in context of the
>> new DS specification? using the same concept as a (new) DS version
>> would be plus.
>Sure, the spec can be found here
>https://github.com/osgi/design/blob/master/rfcs/rfc0190/rfc-0190-
>Declarative_Services_Enhancements.pd
ml#Providing_parameter_definitions
>
>
>
>
>
>> -Original Message- From: Carsten Ziegeler
>> [mailto:cziege...@apache.org] Sent: Wednesday, October 15, 2014
>> 8:24 AM To: dev@sling.apache.org Subject: Re: FW: [PROPOSAL]
>> Context-specific configuration
en Ziegeler [mailto:cziege...@apache.org]
>Sent: Wednesday, October 15, 2014 8:24 AM
>To: dev@sling.apache.org
>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
>Multitenancy
>
>In general, using typed objects is the preferred way to go, so I think a
&
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-
>>&g
In general, using typed objects is the preferred way to go, so I think a
configuration object should be a type object and return configuration
values in the correct type. Let's not fall back into the 80s and fiddle
around with string conversions all over the place.
Having a type for a configuration
> 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
;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 cli
justinedel...@gmail.com] On Behalf Of
>>Justin Edelson
>>Sent: Tuesday, October 14, 2014 4:58 PM
>>To: dev@sling.apache.org
>>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
>>Multitenancy
>>
>>Hi Dominik,
>>Thanks for this li
ailto:justinedel...@gmail.com] On Behalf Of
>Justin Edelson
>Sent: Tuesday, October 14, 2014 4:58 PM
>To: dev@sling.apache.org
>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling,
>Multitenancy
>
>Hi Dominik,
>Thanks for this link, but I'm still conf
Hi Dominik,
Thanks for this link, but I'm still confused about scoping. Looking at
http://wcm.io/config/api/usage-api.html, it seems like a Configuration
object is essentially just a ValueMap. In a non-trivial application,
it seems like you need some kind of namespace for configuration
properties.
Hi,
It looks like a well documented and complete contribution covering non
OSGi configuration and dealing with multiple contexts. I think that is
a widely held generic use case, even if for many projects only one
context is considered.
As such, I think it has a place in Sling, if only to save down
Hi everyone,
I guess people yet just had no chance to dig into the proposal since there
are a lot of scenarios adressed throught this proposal. As far as I
understood the API & SPI the main driver for this proposal is the massive
multisite scenario as described in the mentioned wiki page. Key aspe
p.s. url [1] is wrong - it should be
https://cwiki.apache.org/confluence/x/So2uAg
-Original Message-
From: Stefan Seifert [mailto:sseif...@pro-vision.de]
Sent: Saturday, October 04, 2014 1:54 AM
To: dev@sling.apache.org
Subject: [PROPOSAL] Context-specific configuration for Apache Sling,
24 matches
Mail list logo
