2011/11/11 Justin Edelson <[email protected]>: > A configuration printer is certainly an option, but I think the devs > I've see run into this problem would be better served by something > more interactive. So let's say both :) +1
> > I'm not opposed to a metadata file, but the reason I prefer the > service property method to a file in META-INF is that we can reuse the > service properties from AdapterFactory implementations. The Web > Console doesn't need to care whether the metadata is provided by a > metadata provider service or an AdapterFactory service (or some other > arbitrary service). See https://gist.github.com/1359911 for an example > of the Web Console plugin I built as a POC. Hmm, I'm not a fan of declaring a service just for the sake to provide meta information :) But we could use the annotations to just generate meta type info, by just using the Component annotation with ds=false. Carsten > > Justin > > On Fri, Nov 11, 2011 at 6:08 PM, Carsten Ziegeler <[email protected]> > wrote: >> Great idea and I'm definitely +1 on such a web console plugin. Not >> sure if this is a web console plugin or a configuration status >> renderer (we need the last one as well). >> >> I think instead of defining the additional metadata through the java >> annotations with additional classes like the >> JcrNodeResourceAdapterMeta in your example, what about having a meta >> data file in META-INF of the bundle instead. I know its separate from >> the java code though. >> >> Regards >> Carsten >> >> 2011/11/11 Justin Edelson <[email protected]>: >>> Working with new Sling developers, I find that one of the concepts >>> they have trouble with is in the area of Adapters and that it is hard >>> to find out what objects are adaptable to which classes. Although it >>> is possible to document this (see for example >>> http://dev.day.com/docs/en/cq/current/developing/sling-adapters.html), >>> because new Adapters can be dynamically added (or removed) through >>> OSGi services, any documentation is potentially incomplete. >>> >>> What I would like to do is create a new Web Console plugin which >>> displays the list of available adaptation pairs. I'm still thinking >>> about the UI, but you could imagine that a first version would be a >>> select list on the left listing the adaptable classes and a list on >>> the right of the possible adapters for the selected adaptable. >>> >>> For implementations of AdapterFactory, the necessary metadata already >>> exists in the service registry, but for cases where a class implements >>> its own adapters, this metadata needs to be added. >>> >>> In order to do this, I propose the following: >>> 1) The creation of such a Web Console plugin (obviously). >>> 2) The creation of new OSGi Services for classes which implement their >>> own adaptations. For example: >>> @Component >>> @Service(value=Object.class) >>> @Properties({ >>> @Property(name="adaptables", >>> value="org.apache.sling.api.resource.Resource"), >>> @Property(name="adapters", value={ >>> "javax.jcr.Node", >>> "javax.jcr.Item", >>> "java.io.InputStream", >>> "java.net.URL", >>> "java.util.Map", >>> "org.apache.sling.api.resource.ValueMap" >>> }) >>> }) >>> public class JcrNodeResourceAdapterMeta { } >>> >>> 3) The establishment of a new service property, named >>> adapter.condition, which optionally indicates the conditions under >>> which an adaptation can be made. For example, in the case above: >>> @Property(name="adapter.condition", value="If the resource is a >>> JcrNodeResource") >>> >>> The Web Console plugin would need to note that potentially not all >>> adapters are listed, but I believe that if we add the metadata for all >>> the adapters in Sling, that will set a good precedent for downstream >>> projects to follow. If we want, we could also add a note which says >>> "If there's an adapter not listed here, please file an issue with the >>> adapter provider." :) >>> >>> Adding this metadata is not a trivial amount of effort, but it also >>> something I feel will pay dividends down the road. >>> >>> WDYT? >>> >>> Justin >>> >> >> >> >> -- >> Carsten Ziegeler >> [email protected] >> > -- Carsten Ziegeler [email protected]
