David Nuescheler wrote: > Hi guys, > > I recently stumbled over a change in the > org.apache.sling.api.resource.Resource > interface that may be a symptom of a slight misalignment of my view of the > grand > scheme of (micro-)sling. > > Item Resource.getItem() was changed into Object Resource.getRawData() > > I have to admit that I never understood the more abstract .getItem() to begin > with since i would have expected a .getNode() since all of the usecases > that I know of use a node and not a property. > > Changing this to a .getRawData() returning an Object illustrates that we seem > to have a difference in opinion (again) on the role of JCR in microsling. > For me personally being JCR backed is the most defining feature of microsling. > > Extensibility, restfulness, ease-of-use and many other features are already > claimed and established by numerous other web app frameworks, and trying > to make a case that sling is incrementally better is not a case that i would > attempt to make. > > To me this sounds like a case of what Stefano calls "Flexibility Syndrome" > http://www.betaversion.org/~stefano/papers/ac2006.2.pdf > pages 145 and following. I think his conclusion to "always" avoid the > "flexibility syndrome" is spot on. > > In this case i think already the .getItem() expresses a flexibility syndrome > where we can't really come up with a usecase but still leave a door open. > The .getRawData() only takes this further into an even more "flexible" > direction. > > I think a .getNode() would be much less confusing and more direct. > If someone should ever need a getItem() or even a .getRawData() > i think we could always address that later. > It seems that I miss all these fun discussions during my vacation :( Okay, I see the possibility of FS in this case, but 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). In addition, if you use the ocm stuff, you don't need this anyway.
So, did we miss the point with the API? No, I don't think so - it's "just" the API - 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. 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. I'm not in favour of adding new interfaces (or mixins) for this stuff. We can think of a beter name for getRawData() - although I really think that it is a good name. 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 still see a top priority in having a clean and useful api directly followed by a great implementation making use of JCR. Carsten (Sunbathing in Florida atm) -- Carsten Ziegeler [EMAIL PROTECTED]
