[
https://issues.apache.org/jira/browse/SLING-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264684#comment-14264684
]
Carsten Ziegeler edited comment on SLING-4275 at 1/5/15 3:45 PM:
-----------------------------------------------------------------
We could pass in two arguments :) And with the same argument we could add a
bunch of utility methods to the RenderContext just because they are useful for
extensions. What about adding a getConverter() (or maybe a better name) method
to RenderContext and move all the toXXX into that one? This avoids bloating the
RenderContext with all these methdods. Or have a ConversionUtil with static
methods (similar to the PropertiesUtil we have for configuration handling)?
I'm also wondering why there is a generic toNumber method and not toInteger, or
toFloat?
And what do you think about removing the RuntimeExtension interface?
was (Author: cziegeler):
We could pass in two arguments :) And with the same argument we could add a
bunch of utility methods to the RenderContext just because they are useful for
extensions. What about adding a getConverter() (or maybe a better name) method
to RenderContext and move all the toXXX into that one? This avoids bloating the
RenderContext with all these methdods.
I'm also wondering why there is a generic toNumber method and not toInteger, or
toFloat?
And what do you think about removing the RuntimeExtension interface?
> 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)
