Re: StarResource.adaptTo(Node.class)
Hi, 2009/2/24 Felix Meschberger : > ...SLING-344 [1] added the StarResource [2] to support requests to > explicitly unknown resources like /* or /*.html. One feature of this > class is, that it adapts to a "FakeNode" Yes, the use case for that is when building a simple CRUD application. Requesting the StarResource and adapting that to a Node provides you with empty values for all the node's properties, so if using the sling.wizard() from sling.js you have no code to write for the Create action - it is handled just like the Update action, but works on the "magic" star resource. The only difference between Create and Update in this case, is that for Create you retrieve the * resource (which initializes all your fields to empty values), whereas for Update you retrieve the actual resource that was created before. See my "blog in 46 lines" example at http://dev.day.com/microsling/content/blogs/main/sling-46-lines-blog.html for an actual mini-app that uses this feature. > ...having a > synthetic resource not backed by a JCR item return a non-null result for > adaptTo(Node.class) is kind of strange. > > For this reason, I suggest remove the Node adapter functionality of the > StarResource, such that > > StarResource.adaptTo(Node.class) == null... Although I see the idea, that would break the above use case. I'm open to suggestions for providing that functionality in another way, but don't have much time to look at it myself at the moment. -Bertrand
Re: StarResource.adaptTo(Node.class)
On Tue, Feb 24, 2009 at 2:38 PM, Felix Meschberger wrote: > Bertrand Delacretaz schrieb: >> ...Although I agree with the intention, I think the "edit the magic star >> to create content" use case is a valid one, and we need to provide an >> alternative before breaking it > ...In fact, looking at the sling.js script, the wizard() method calls > getContent() inderectly, which places a JSON request, which is handled > by the default GET servlet for JSON. Since this servlet is completely > prepared to not get a Node, it makes no difference Great - if that works I have no problem with your suggestion. I'm back from a business trip + holiday and swamped with stuff, so won't have time to check that right now. -Bertrand
Re: StarResource.adaptTo(Node.class)
Hi, Bertrand Delacretaz schrieb: > (ignore second copy if this comes doubled...offline Gmail + 2 > computers + Gmail was down) Only got one.. > > Hi, > > 2009/2/24 Felix Meschberger : >> ...SLING-344 [1] added the StarResource [2] to support requests to >> explicitly unknown resources like /* or /*.html. One feature of this >> class is, that it adapts to a "FakeNode" > > Yes, the use case for that is when building a simple CRUD application. > > Requesting the StarResource and adapting that to a Node provides you > with empty values for all the node's properties, so if using the > sling.wizard() from sling.js you have no code to write for the Create > action. > > The only difference between Create and Update in this case, is that > for Create you retrieve the * resource, whereas for Update you > retrieve the actual resource that was created before. > > See my "blog in 46 lines" example at > http://dev.day.com/microsling/content/blogs/main/sling-46-lines-blog.html > for an actual mini-app that uses this feature. > >> ...having a >> synthetic resource not backed by a JCR item return a non-null result for >> adaptTo(Node.class) is kind of strange. >> >> For this reason, I suggest remove the Node adapter functionality of the >> StarResource, such that >> >>StarResource.adaptTo(Node.class) == null... > > That would break the above use case. > > Although I agree with the intention, I think the "edit the magic star > to create content" use case is a valid one, and we need to provide an > alternative before breaking it. The point is, that a resource is not required to adapt to a Node. For example resources loaded from the file system or from bundles are not backed by nodes and will always return null on adaptTo(Node.class). Hence every application must be prepared to get null in this case and therefore the sling.wizard() must also be prepared to not get anything. In fact, looking at the sling.js script, the wizard() method calls getContent() inderectly, which places a JSON request, which is handled by the default GET servlet for JSON. Since this servlet is completely prepared to not get a Node, it makes no difference. Regards Felix
Re: StarResource.adaptTo(Node.class)
(ignore second copy if this comes doubled...offline Gmail + 2 computers + Gmail was down) Hi, 2009/2/24 Felix Meschberger : > ...SLING-344 [1] added the StarResource [2] to support requests to > explicitly unknown resources like /* or /*.html. One feature of this > class is, that it adapts to a "FakeNode" Yes, the use case for that is when building a simple CRUD application. Requesting the StarResource and adapting that to a Node provides you with empty values for all the node's properties, so if using the sling.wizard() from sling.js you have no code to write for the Create action. The only difference between Create and Update in this case, is that for Create you retrieve the * resource, whereas for Update you retrieve the actual resource that was created before. See my "blog in 46 lines" example at http://dev.day.com/microsling/content/blogs/main/sling-46-lines-blog.html for an actual mini-app that uses this feature. > ...having a > synthetic resource not backed by a JCR item return a non-null result for > adaptTo(Node.class) is kind of strange. > > For this reason, I suggest remove the Node adapter functionality of the > StarResource, such that > > StarResource.adaptTo(Node.class) == null... That would break the above use case. Although I agree with the intention, I think the "edit the magic star to create content" use case is a valid one, and we need to provide an alternative before breaking it. -Bertrand
Re: StarResource.adaptTo(Node.class)
Sounds reasonable. +1 Juanjo
Re: StarResource.adaptTo(Node.class)
Felix Meschberger wrote: > Hi all, > > SLING-344 [1] added the StarResource [2] to support requests to > explicitly unknown resources like /* or /*.html. One feature of this > class is, that it adapts to a "FakeNode". > > Given that in the meantime we are firm on the resource tree, which > resolves resource, which need not be backed by JCR items, having a > synthetic resource not backed by a JCR item return a non-null result for > adaptTo(Node.class) is kind of strange. > > For this reason, I suggest remove the Node adapter functionality of the > StarResource, such that > > StarResource.adaptTo(Node.class) == null > Urgs, that's really strange; yes we should change it: +1 Carsten -- Carsten Ziegeler cziege...@apache.org