[
https://issues.apache.org/jira/browse/SLING-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-4275:
------------------------------------
Description:
I have some comments about the public Sightly API:
1. There are several exceptions, like SightlyException,
RuntimeExtensionException, SightlyUseException - are these really required? The
API does not mention any method/interface throwing such an exception
2. RuntimeExtension and ExtensionInstance - I think we can get rid of the
RuntimeExtension interface and simply pass the RenderContext in
ExtensionInstance#call.
3. The purpose of the Record interface is a little bit unclear to me. In
addition it has a T get(String) method while properties returns a Set<String>.
I guess the engine supports a Map, so maybe we can get rid of this interface?
4. ResourceResolution seems to contain methods for getting scripts. Isn't this
some functionalty the existing ServletResolver component provides? Or if not,
shouldn't we move this to the Sling API?
5. Many of the methods in the RenderContext are Object traversal and value
conversion methods. I think this needs to go into a separate service (and maybe
package)
was:
I have some comments about the public Sightly API:
1. There are several exceptions, like SightlyException,
RuntimeExtensionException, SightlyUseException - are these really required? The
API does not mention any method/interface throwing such an exception
2. RuntimeExtension and ExtensionInstance - I think we can get rid of the
RuntimeExtension interface and simply pass the RenderContext in
ExtensionInstance#call.
3. The purpose of the Record interface is a little bit unclear to me. In
addition it has a T get(String) method while properties returns a Set<String>.
I guess the engine supports a Map, so maybe we can get rid of this interface?
4. ResourceResolution seems to contain methods for getting scripts. Isn't this
some functionalty the existing ServletResolver component provides? Or if not,
shouldn't we move this to the Sling API?
5. Many of the methods in the RenderContext are Object traversal and value
conversion methods. I think this needs to go into a separate service (and maybe
package)
6. UseProvider services. What about registering such a service with a required
property indicating the identifiers it provides instead of requiring to ask
each and every provider?
> Review of the Sightly API
> -------------------------
>
> Key: SLING-4275
> URL: https://issues.apache.org/jira/browse/SLING-4275
> Project: Sling
> Issue Type: Task
> Components: Scripting
> Reporter: Carsten Ziegeler
> Fix For: Scripting Sightly Engine 1.0.0
>
>
> I have some comments about the public Sightly API:
> 1. There are several exceptions, like SightlyException,
> RuntimeExtensionException, SightlyUseException - are these really required?
> The API does not mention any method/interface throwing such an exception
> 2. RuntimeExtension and ExtensionInstance - I think we can get rid of the
> RuntimeExtension interface and simply pass the RenderContext in
> ExtensionInstance#call.
> 3. The purpose of the Record interface is a little bit unclear to me. In
> addition it has a T get(String) method while properties returns a
> Set<String>. I guess the engine supports a Map, so maybe we can get rid of
> this interface?
> 4. ResourceResolution seems to contain methods for getting scripts. Isn't
> this some functionalty the existing ServletResolver component provides? Or if
> not, shouldn't we move this to the Sling API?
> 5. Many of the methods in the RenderContext are Object traversal and value
> conversion methods. I think this needs to go into a separate service (and
> maybe package)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
