hmm.. too bad.
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
