Hi Guys, Felix says: > Coming back to David's initial problem, that the ScriptableNode does not > provide the getSession() method: We have SLING-154 [1], which is > concerned with completing the ScriptableNode implementation, and there > is a way to access the Session, I think, we do not need to do anything > else at the moment. Well my problem that goes even beyond that. Even if I would manage to acquired a Session somehow all the nodes that come back from calls will be ScriptableNodes and will hide the methods that I need to manipulate the node.
I agree with Felix that https://issues.apache.org/jira/browse/SLING-154 resolves my Issue in a pragmatic fashion. ...on a more general level, though. <pointless-rant> Carsten says: > For instance, if you have a non-jcr-resource this resource ... Can we please not use that as an argument... I really think we should focus on the real use-cases we have at hand. I know I sound like a broken record regarding the abstraction of Sling from JCR. Getting access to session and node is just the beginning. Personally, I think it makes little sense to promote abstraction on the Sling API layer, if we re-introduce all the JCR dependencies "rightfully" and based on use-cases through the back door into all the scripting layers. I guess what beats me is, why we can't build abstraction into the system as we go along and just cover our current needs for now. YAGNI. Scratch your own itch. Flexibility Syndrome. </pointless-rant> Feel free to ignore the above rant since I think we discussed this matter on this list many times over... regards, david
