Let me see how close I am to your thought process. A resource can have a sling:resourceType which defines the process which processes the resource. That is the default process, however you can apply other resourceTypes to that resource so it's processed differently based on your need.
To me that makes it more like an OO interface. Right now, you can apply any resourceType to any resource and it will attempt to handle it. Even if the values on the resource that the resourceType requires aren't there. By assigning types to the resourceType you can define required/optional fields and the types of actions that can occur on that resource. This will then give you the ability to do the following 1. generate meta data about the resource for use with a UI 2. potentially used as a field validation if someone attempts to create a resource type without the proper fields 3. Will generate an error if they use something like sling:include to override the default resourceType and the new resourceType requires properties that the resource doesn't have. How am I doing? - Jason On Tue, Oct 2, 2018, at 10:15 AM, Bertrand Delacretaz wrote: > Hi Jason, > > thanks for your feedback! > > On Tue, Oct 2, 2018 at 3:48 PM Jason E Bailey <j...@apache.org> wrote: > > ...To restate. Given a resource, you should be able to define what > > properties that resource can contain and what child resources it can be the > > parent of... > > Yes, among other things including some that we might discover along the way. > > > ...1. There's some things that are implicit. For example, stating that a > > resource can be a parent of a resource would imply > > that you could perform the action to create the child resource.... > > Absolutely, which means we can generate hyperlinks for such operations > automatically. > > >... We're still a REST platform, do we need to have actions that are > >different then the standard REST methods? Would we have something > >different?... > > I think actions can be more specific, at least in terms of their > link:rel values. > > A hyperlink can say > > link:rel=sling.create.imagefolder, method=POST, path=./images > > as basically it, along with the Sling Type System (STS) typedef, needs > to contain enough information to generate an HTML form when generating > a UI. > > maybe...just thinking outloud, but basically an action can have a more > specific name than POST to clarify what it does exactly. > > > ...Looking at the code, I get confused between a type for a resource and a > > sling:resourceType. I believe these are different things.... > > I think it's fair to describe the code as a hack created when those > ideas where still emerging ;-) > > My point of view is that a resourceType points to an STS typedef, > which conceptually points to rendering scripts or servlets. > > That's conceptually...in practice I think we can keep the current > script resolution mechanism, but the STS typedef might validate > operations before passing them on. > > Does that address your concerns? > > That's all still vague for now anyway, needs to be defined more > clearly and proven with prototypes. > > -Bertrand
