[
https://issues.apache.org/jira/browse/SLING-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264346#comment-14264346
]
Carsten Ziegeler edited comment on SLING-4275 at 1/5/15 8:39 AM:
-
{quote}
* SightlyException is the "root" exception of all of Sightly.
* SightlyUseException may be thrown by the UseProvider API. Respective JavaDoc
mention is missing
* RuntimeExtensionException may be thrown by the RuntimeExtension API.
Respective JavaDoc is missing
{quote}
Right, but do we really need these different runtime exceptions? Each service
having it's own runtime exception seems like a waste to me, especially as the
caller does not do anything different with such a specific runtime exception
compared to a "plain" runtime exception.
bq. RuntimeExtension.provide is called once per script evaluation while
ExtensionInstance objects may be called for each occurrence of the extension's
use in the script. As such this is kind of a caching mechanism.
As ExtensionInstance has a single method, I think we could go without this
extra layer of object caching and go with a singleton
bq. The Record interface supports for simplified property access in a much
simpler way than the Map interface would allow. Also Pojo's in use
attributes/statements may implement the Record interface to actually inject
properties into the current evaluation scope.
bq. I think this is another case of incomplete JavaDoc.
So I'll wait for the javadoc update - what about ValueMap?
bq. Yes, this should probably be moved to the Sling API. But we did not want to
tie the release of Sightly to an update of the Sling API: The Sling API bundle
cannot alwas be simply updated in a running system unless you want to accept
ripple effects due to extended API in other packages, such as the resource API.
So we start with something which will be added to the Sling API later on and
then we deprecate this stuff again? Maybe we should at least put this in a
separate package so we can deprecate the whole package later on
bq. The RenderContext is created for script evaluation and handed down the
evaluation stack and extensions. I don't think this needs to be exposed as a
service.
I was not refering to making the RenderContext itself a service - I'm refering
to the utility methods in that interface that handle Object traversal and value
conversion - I don't think these methods belong to RenderContext - they can
either be moved to an utility class or service.
was (Author: cziegeler):
{quote}
* SightlyException is the "root" exception of all of Sightly.
* SightlyUseException may be thrown by the UseProvider API. Respective JavaDoc
mention is missing
* RuntimeExtensionException may be thrown by the RuntimeExtension API.
Respective JavaDoc is missing
{quote}
Right, but do we really need these different runtime exceptions? Each service
having it's own runtime exception seems like a vaste to me, especially as the
caller does not do anything with such exceptions.
bq. RuntimeExtension.provide is called once per script evaluation while
ExtensionInstance objects may be called for each occurrence of the extension's
use in the script. As such this is kind of a caching mechanism.
As ExtensionInstance has a single method, I think we could go without this
extra layer of object caching and go with a singleton
bq. The Record interface supports for simplified property access in a much
simpler way than the Map interface would allow. Also Pojo's in use
attributes/statements may implement the Record interface to actually inject
properties into the current evaluation scope.
bq. I think this is another case of incomplete JavaDoc.
So I'll wait for the javadoc update - what about ValueMap?
bq. Yes, this should probably be moved to the Sling API. But we did not want to
tie the release of Sightly to an update of the Sling API: The Sling API bundle
cannot alwas be simply updated in a running system unless you want to accept
ripple effects due to extended API in other packages, such as the resource API.
So we start with something which will be added to the Sling API later on and
then we deprecate this stuff again? Maybe we should at least put this in a
separate package so we can deprecate the whole package later on
bq. The RenderContext is created for script evaluation and handed down the
evaluation stack and extensions. I don't think this needs to be exposed as a
service.
I was not refering to making the RenderContext itself a service - I'm refering
to the utility methods in that interface that handle Object traversal and value
conversion - I don't think these methods belong to RenderContext - they can
either be moved to an utility class or service.
> Review of the Sightly API
> -
>
> Key: SLING-4275
> URL: https://issues.apache.org/jira/browse/SLING-4275
>
