Hi Carsten, (sorry about replying so late, the thread was sitting in my "must act on this" folder for too long ;-)
On Nov 25, 2007 12:58 AM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > ...currently the API > does not have any other reference to JCR! So, introducing this one > single dependency does not seem to fit the "JCR backed" theme either, > right? It's one method out of hundreds (didn't really count them).... Not sure if I understand correctly, do you mean that is a good thing that the API doesn't (or didn't) have a dependency on the JCR libs? Me, I don't really care...it feels a bit funny to have just one method be dependent on JCR, but that might just indicate that the API is well decoupled from JCR. > ...the complete framework consisting of API and > implementation is "JCR backed" - and this makes the difference compared > to other frameworks. And we have a clean and nice api with all the other > features. I still think that this makes sense and I wouldn't call it FS.... In "call it", what do you mean by "it" exactly? Just making sure I understand your point of view. > ...The discussed approaches by either using extensions of the Resource > interface or using mixins are not any better than a method returning an > object. As a client of the api you get a Resource object and either try > to cast it down to sub interface, try to cast it to a mixin or try to > cast the return value to something. It's basically the same thing - the > only difference is that with using mixins or sub interfaces, you > predefine a set of possibilities. But there is not much value in that, I > think.... Fairly convincing...if we have to downcast anyway, mixins just restrict the possibilities. > ...We can think of a beter name for getRawData() - although I really think > that it is a good name.... Considering the above, we might leave just one Object getData() method to access data in the Resource, right? And for microsling this would return a Node, and in Sling if using OCM that would return an Object. > ...We should rather think about making things easier in the scripting > stuff, so for example if you use Javascript and have a resource object > which points to a node, why not having a resource.node property? > I know, this might fall into the "too much magic" category - but right > now I don't think so.... I don't think it's too much magic, it's just convenience wrappers, and we already have them (ScriptableResource and ScriptableNode). > ...I still see a top priority in having a clean and useful api directly > followed by a great implementation making use of JCR.... Ok - I still don't care much about whether the API has a dependency on JCR, but I see your point about mixins not adding that much value. -Bertrand
