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. I guess to sum it up, my personal preference would be the following: (*1*) Node Resource.getNode() (2) Object Resource.getNode() (3) Item Resource.getItem() (4) Object Resource.getItem() ... (xx) Object Resource.getRawData() I think simplicity is a key paradigm of microsling. I would hate to sacrifice simplicity on the most frequent case for very doubtful cases that we don't even know yet if we are ever going to have them. regards, david
