Hi Felix, The API reorganisation looks good to me.
On Wed, Nov 19, 2014 at 10:49 PM, Felix Meschberger <fmesc...@adobe.com> wrote: > Apart from splitting the base .api package, this are further discussions: > > * Exceptions are forming a hierarchy with SightlyEngineException being the > root and itself extending from SlingException > Sure, it makes sense. > * I wonder, whether we should really drop the *Component abstract classes > (RuntimeExtensionComponent and UseProviderComponent). I don’t think they > provide real value at all but have an activate method, which they expect to > be called and which they expect to be a DS component annotated with the > Felix annotations. I think this is brittle. > The abstract classes were written specifically for that activate method, in order to avoid writing those lines of code for every implementation. > * UseProvider defines an ordering method and declares itself being > Comparable. I think this is wrong. The UseProviders should be sorted using > regular OSGi service ranking. > If we make the service.ranking property configurable (metatype = true) I guess we could use the OSGi ranking. Theoretically the Use providers can be configured to be called in a pre-determined order, depending on how the Sightly projects from an instance make use of the Use-API (Java Use-API objects deployed in bundles / Java Use objects near the component script in the repo / JS Use-API, etc.). Having the Use providers called in the most favourable way can increase performance for Sightly applications. > * I wonder, whether we really have to have all this API exported at all: > Some API I don’t see implemented at all (e.g. BaseRenderUnit — or is that > the base class for the Java classes generated from the Sightly templates ?) > The BaseRenderUnit is indeed the base class for classes generated from Sightly scripts, which is why we need to export the other classes as well. In this regard Sightly is no different from the JSP engine. > * Last but not least (actually most important of all): There is close to > no JavaDoc. Before cutting a release of this bundle, JavaDoc must be > provided for the API. For example I am not sure, what the Record or the > ObjectModel interfaces are really used for. > It's on my TODO list. Thanks, Radu
