Hi all, After seeing a general consensus, I created a JIRA for this [1]. In addition to the initial proposal on the list I added another one. While the first one is certainly straight forward, the second one has the added benefit, that the XXXProvider interfaces may also be used in other circumstances than just the Resource use case.
WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-109 Am Sonntag, den 18.11.2007, 15:45 +0100 schrieb David Nuescheler: > 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
