> hmm.. too bad. You could always base64-encode it and replace +/= by .-_ <GD&R>
> On Wed, Oct 2, 2013 at 2:28 PM, Peter Kriens <[email protected]> wrote: >> I think the config admin spec recommends (SHOULD) that a property key is >> a >> symbolic name, this leaves out square brackets ... >> Kind regards, >> Peter Kriens >> On 2 okt. 2013, at 15:35, Raymond Auge <[email protected]> wrote: >> On Wed, Oct 2, 2013 at 4:48 AM, Peter Kriens >> <[email protected]>wrote: >>> Well, you can store the actual configuration somewhere else and use the >>> current mechanism to provide a pointer. Or just store it in XML/JSON in >>> a >>> string/byte[] in the configuration? >>> Alternatively you can map the configuration of virtually an XML to properties using nested property names and integers for elements <a><b>3</b><b>1</b></a> -> a.1.b=1 >> Ok, that's actually close to how I have it modelled so far. >> I'm also looking for a way to perhaps auto convert. So perhaps, as you imply, something close to xml -> xpath -> property. >> /a[1]/b[1]=3 >> /a[1]/b[2]=1 >> a.b[1]=3 >> a.b[2]=1 >>> We consciously prevented the complexity of XML Schemas to allow things like Metatype (see Webconsole's editor) since we expected the >>> configuration >>> data to be relatively simple. >> Right, in this case the properties here are static (i.e. it's not really >> "configuration"), so no UI. >>> However, there are no limits to the byte[] length or String length so this allows you to encode more complex data. Although this will not give >>> you the automatic UI. >> Good to know. >> Thank you, >> - Ray >>> Kind regards, >>> Peter Kriens >>> On 1 okt. 2013, at 16:59, Raymond Auge <[email protected]> wrote: >>> Hello everyone, >>> I'm wondering the best approach for modelling hierarchically complex configuration data in DS >>> For example, Portlets (JSR-168/286) have rather complex configuration http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd. >>> If I wanted to model a Portlet as a DS component, I have a hard time mapping the complexity. >>> Any ideas how to model this? >>> I could ref an XML resource or some other weirdness, but is there perhaps >>> a more elegant approach? >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect >>> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) >>> _______________________________________________ >>> 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 >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect >> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) >> _______________________________________________ >> 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 > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com> (@Liferay) > _______________________________________________ > 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
