You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by David Nuescheler <da...@day.com> on 2007/11/18 15:45:39 UTC
Node Resource.getNode() vs. Object Resource.getRawData()
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
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
>> ...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)....
>
> Not sure if I understand correctly, do you mean that is a good thing
> that the API doesn't (or didn't) have a dependency on the JCR libs?
:) I think it should either have a deep dependency on JCR or non at all,
but not just one method.
>
> Me, I don't really care...it feels a bit funny to have just one method
> be dependent on JCR, but that might just indicate that the API is well
> decoupled from JCR.
I think this indicates that there is something wrong with the API :)
But fortunately I can get back to the beach as Felix has found a nice
solution.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Felix Meschberger <fm...@gmail.com>.
Am Freitag, den 30.11.2007, 08:34 +0100 schrieb Bertrand Delacretaz:
> On Nov 30, 2007 8:22 AM, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ...An extended more flexible solution would be something like this:
> >
> > public interface Resource {
> > ....
> > // get this resource as an object of the type or null if not
> > possible
> > <T> T adaptTo(Class<T> type);
> > }...
>
> Very interesting - this means basically delegating the typecast to the
> Resource itself, which is best placed to know whether the cast makes
> sense or not. I like that.
Yes, and the Resoure may even adapt to more types by applying some more
logic, for example a Resource may support adapting to a DOM Document
returning the Node subtree as a DOM Document, or it may adapt to a
JSONObject returning the Node subtree as a JSON object ....
We might even be able to drop these XXXProvider interfaces again,
because they would not be needed. The Resource knows whether it has a
node and just returns that node, without even having to cast something.
And best of all: We dropped the singular reference to the JCR API
again :-)
Regards
Felix
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 30, 2007 8:22 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...An extended more flexible solution would be something like this:
>
> public interface Resource {
> ....
> // get this resource as an object of the type or null if not
> possible
> <T> T adaptTo(Class<T> type);
> }...
Very interesting - this means basically delegating the typecast to the
Resource itself, which is best placed to know whether the cast makes
sense or not. I like that.
-Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Tobias Bocanegra <to...@day.com>.
> > > ... <T> T adaptTo(Class<T> type);...
>
> > ...Yepp, that looks very good to me, +1...
>
> Yee-haaw! We have closure I guess ;-)
i like this, too. well done.
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 1, 2007 12:16 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Felix Meschberger wrote:
> > ... <T> T adaptTo(Class<T> type);...
> ...Yepp, that looks very good to me, +1...
Yee-haaw! We have closure I guess ;-)
-Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Now that I have applied the changes with the mixin interfaces, I realize
> how elegant the solution actually is: Check, whether the resource
> provides certain data and call that that by API. This is much more
> convenient than having just one method and guessing on its result and
> not being able to get other data, such as an URL, etc.
Hmm, not really :) As soon as a resource implementation wants to
implement more than one mixin, but in some cases only one mixin is
available for a concrete object, this makes the implementation
difficult. But fortunately we don't have to go into the details here
(see below).
>
> An extended more flexible solution would be something like this:
>
> public interface Resource {
> ....
> // get this resource as an object of the type or null if not
> possible
> <T> T adaptTo(Class<T> type);
> }
>
> this would allow something like this:
>
> Node node = resource.adaptTo(Node.class);
> if (node != null) {
> ....
> }
>
> as compared to
>
> if (resource instanceof NodeProvider) {
> Node node = ((NodeProvider) resource).getNode();
> }
>
> This is derived from the Eclipse Adaptable interface.
Yepp, that looks very good to me, +1
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 30.11.2007, 08:08 +0100 schrieb Bertrand Delacretaz:
> (sorry about replying so late, the thread was sitting in my "must act
> on this" folder for too long ;-)
Same for me - I wanted to reply yesterday, around the time I applied the
change, but then ...
> > ...We can think of a beter name for getRawData() - although I really think
> > that it is a good name....
>
> Considering the above, we might leave just one
>
> Object getData()
>
> method to access data in the Resource, right?
>
> And for microsling this would return a Node, and in Sling if using OCM
> that would return an Object.
Now that I have applied the changes with the mixin interfaces, I realize
how elegant the solution actually is: Check, whether the resource
provides certain data and call that that by API. This is much more
convenient than having just one method and guessing on its result and
not being able to get other data, such as an URL, etc.
An extended more flexible solution would be something like this:
public interface Resource {
....
// get this resource as an object of the type or null if not
possible
<T> T adaptTo(Class<T> type);
}
this would allow something like this:
Node node = resource.adaptTo(Node.class);
if (node != null) {
....
}
as compared to
if (resource instanceof NodeProvider) {
Node node = ((NodeProvider) resource).getNode();
}
This is derived from the Eclipse Adaptable interface.
Regards
Felix
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Carsten,
(sorry about replying so late, the thread was sitting in my "must act
on this" folder for too long ;-)
On Nov 25, 2007 12:58 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...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)....
Not sure if I understand correctly, do you mean that is a good thing
that the API doesn't (or didn't) have a dependency on the JCR libs?
Me, I don't really care...it feels a bit funny to have just one method
be dependent on JCR, but that might just indicate that the API is well
decoupled from JCR.
> ...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....
In "call it", what do you mean by "it" exactly? Just making sure I
understand your point of view.
> ...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....
Fairly convincing...if we have to downcast anyway, mixins just
restrict the possibilities.
> ...We can think of a beter name for getRawData() - although I really think
> that it is a good name....
Considering the above, we might leave just one
Object getData()
method to access data in the Resource, right?
And for microsling this would return a Node, and in Sling if using OCM
that would return an Object.
> ...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 don't think it's too much magic, it's just convenience wrappers, and
we already have them (ScriptableResource and ScriptableNode).
> ...I still see a top priority in having a clean and useful api directly
> followed by a great implementation making use of JCR....
Ok - I still don't care much about whether the API has a dependency on
JCR, but I see your point about mixins not adding that much value.
-Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Betrand also suggested:
... and it might also be useful to have a StreamProvider which returns
an InputStream
This is probably a good idea in that it allows seeing the Resource as
just being a "handle" (like the java.io.File) and having additional API
to actually access the data.
Regards
Felix
Am Donnerstag, den 22.11.2007, 10:17 +0100 schrieb Bertrand Delacretaz:
> On Nov 22, 2007 10:13 AM, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ...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 ?
>
> As I wrote on the JIRA issue, I like the mixin interfaces idea.
>
> -Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 22, 2007 10:13 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...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 ?
As I wrote on the JIRA issue, I like the mixin interfaces idea.
-Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Sorry for the delay ....
Am Donnerstag, den 22.11.2007, 13:36 +0200 schrieb Jukka Zitting:
> How does this compare to using JCR adapters for things like URLs and
> local files?
What adapters ? The IO handlers of Jackrabbit simple WebDAV ? I don't
see others.
Anyway, such adapters tend to be unconnected and distributed and are not
generally transparent to use. In contrast to the Resource, which has a
unified and very simple interface upfront with mixin providers (you may
call it adapters, see my last mail on this thread). This concentrates
all work of providing different views in one place and prevents
implementing the same thing over and over again.
> To me it seems like the Resource interface, as currently
> envisioned, might well end up growing to a mini-Node abstraction by
> time.
The Resource interface will never be a mini-Node abstraction. By no
means. It is meant as a simple and singular representation of a resource
upon which Sling and microsling operate. The scripts and servlets may
after that look under the hood of the Resource and use whatever
additional data, the Resource may be able to provide.
> I find it odd that the default URI resolver first uses JCR to look up
> a node to be wrapped into a Resource instance that'll then be
> unwrapped using type casts by servlet/script components that do need
> direct JCR access. In general I think that any APIs that require type
> casting as a central feature are somewhat broken.
Not necessairily. I agree with respect to the former getRawData method,
which involves quite some magic to find and use the correct type. This
has probably not been the best of all solutions.
>
> Also, I feel that the object mapping would be better handled on top of
> the resource API, not as a part of it. Especially since it implies two
> completely separate node type mappings (one for the servlet/script
> resolution, one for object mapping) within Sling.
Yes and no. If we implement it inside the resource, we abstract it away
from the user and place the burden on a single location.
> The same goes for the StreamProvider idea. As soon as you start
> thinking that you'd need separate stream representations for nt:file
> and nt:unstructured nodes, you end up with yet another indepent node
> type mapping within the framework. I'm sure that this can only cause
> confusion later on.
Right, I agree, that if we have the object mapping in the Resource
support, we should also have the stream access there. I consider basing
such an implementation on the IOHandlers framework of the Jackrabbit
simple WebDAV.
Regards
Felix
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Nov 22, 2007 11:13 AM, Felix Meschberger <fm...@gmail.com> wrote:
> 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.
How does this compare to using JCR adapters for things like URLs and
local files? To me it seems like the Resource interface, as currently
envisioned, might well end up growing to a mini-Node abstraction by
time.
I find it odd that the default URI resolver first uses JCR to look up
a node to be wrapped into a Resource instance that'll then be
unwrapped using type casts by servlet/script components that do need
direct JCR access. In general I think that any APIs that require type
casting as a central feature are somewhat broken.
Also, I feel that the object mapping would be better handled on top of
the resource API, not as a part of it. Especially since it implies two
completely separate node type mappings (one for the servlet/script
resolution, one for object mapping) within Sling.
The same goes for the StreamProvider idea. As soon as you start
thinking that you'd need separate stream representations for nt:file
and nt:unstructured nodes, you end up with yet another indepent node
type mapping within the framework. I'm sure that this can only cause
confusion later on.
BR,
Jukka Zitting
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Felix Meschberger <fm...@gmail.com>.
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
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 20, 2007 3:37 AM, Jukka Zitting <ju...@gmail.com> wrote:
> ...+1 I would even go as far as questioning the need for the Resource
> interface in the first place; why not use Node instead?...
Having a Resource helps people think in REST terms, so I like that
even though the API could be a bit more minimalistic.
> ...Perhaps I should start writing nanosling. Just
> kidding... ;-)...
hmmm....be careful, we already have some concerns about the swimsuit
angle on the microsling name (which I didn't know about when I came up
with the name, honest ;-)
-Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 20.11.2007, 04:37 +0200 schrieb Jukka Zitting:
> +1 I would even go as far as questioning the need for the Resource
> interface in the first place; why not use Node instead?
Because the Resource for a level of abstraction, which is not possible
using just the Node. I just mention the definition of a "resource type"
to be used for script and servlet selection.
Regards
Felix
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Nov 18, 2007 4:45 PM, David Nuescheler <da...@day.com> wrote:
> 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.
+1 I would even go as far as questioning the need for the Resource
interface in the first place; why not use Node instead?
PS. I may well be too much of a reductionist with this and the URI
mapping issue. Perhaps I should start writing nanosling. Just
kidding... ;-)
BR,
Jukka Zitting
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 20, 2007 11:54 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...Why not replace the SlingScript interface providing
> a Resource by a ScriptResource interfaces:
>
> ...The question of course is: Is a Script a Resource ??...
Not always IMHO, we might have (mini-)scripts which come from
configuration properties, and in testing it might be a pain to have to
create a Resource just to evaluate a script.
I don't have a strong opinion on this though, if there are good
reasons to make Script a Resource I'd be fine with that.
-Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Felix Meschberger <fm...@gmail.com>.
Am Dienstag, den 20.11.2007, 11:11 +0100 schrieb Bertrand Delacretaz:
> >... This would allow for other resources such as a FileResource or an
> > URLResource (hold on, there is an actual use case....
>
> I was going to say "that's nice even though we don't have a use case
> right now", so if we have one that's even better
Thinking about this: Why not replace the SlingScript interface providing
a Resource by a ScriptResource interfaces:
public interface ScriptResource extends Resource {
void eval(Map<String, Object> properties) throws
SlingException, IOException;
}
The question of course is: Is a Script a Resource ??
Regards
Felix
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 20, 2007 11:58 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...OcmMappedResource as in
> "Object-Content-Mapping-Mapped-Resource" sounds a bit weird. ...
> ...I agree that MappedResource sounds kind of generic. After all, it is an
> interface and should be somewhat generic, right ?...
Right, so why not ObjectResource then?
That's what it is, a Resource that points to an Object.
-Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 20.11.2007, 11:11 +0100 schrieb Bertrand Delacretaz:
> >... public interface MappedResource extends Resource {
> > Object getObject();
> > }..
>
> Ok - I'd call that OcmMappedResource maybe, as "mapped" is a kinda generic name.
Not sure. OcmMappedResource as in
"Object-Content-Mapping-Mapped-Resource" sounds a bit weird. Almost like
PDF format, PIN number, ... In addition the term "OCM" seems to me seems
a bit too close to the concrete Jackrabbit JCR-OCM project thus
implicating a concrete implementation in an interface.
I agree that MappedResource sounds kind of generic. After all, it is an
interface and should be somewhat generic, right ?
Regards
Felix
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 20, 2007 11:17 AM, David Nuescheler <da...@day.com> wrote:
> > > ... public interface JcrResource extends Resource {...
> can we make it "NodeResource" ?
Good idea, as it points to a Node, not a "JCR" ;-)
-Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by David Nuescheler <da...@day.com>.
sounds good to me ;)
> > ...Let us keep the Resource completely abstract...
> I like that.
+1
> > ... public interface JcrResource extends Resource {
> > Node getNode();
> > }..
> Ok
can we make it "NodeResource" ?
> >... public interface MappedResource extends Resource {
> > Object getObject();
> > }..
> Ok - I'd call that OcmMappedResource maybe, as "mapped" is a kinda generic name.
sounds good.
i would probably propose:
public interface ObjectMappedNodeResource extends NodeResource {
}
> >... For microsling, we can then safely assume, that the Resource is always a
> > JcrResource...
> ok
sounds like a good approach.
regards,
david
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 20, 2007 10:58 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...Let us keep the Resource completely abstract...
I like that.
> ... public interface JcrResource extends Resource {
> Node getNode();
> }..
Ok
>... public interface MappedResource extends Resource {
> Object getObject();
> }..
Ok - I'd call that OcmMappedResource maybe, as "mapped" is a kinda generic name.
>... This would allow for other resources such as a FileResource or an
> URLResource (hold on, there is an actual use case....
I was going to say "that's nice even though we don't have a use case
right now", so if we have one that's even better
>... For microsling, we can then safely assume, that the Resource is always a
> JcrResource...
ok
>... WDYT ?..
I'm +1 on the proposed changes.
-Bertrand
Re: Node Resource.getNode() vs. Object Resource.getRawData()
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
Maybe we should come back to an earlier proposal we discussed (and
dismissed at that time): Let us keep the Resource completely abstract,
taking out the getRawData and getObject methods and add new interfaces
for the mapped data and the JCR node:
public interface Resource {
String getURI();
String getResourceType();
ResourceMetadata getResourceMetadata();
InputStream getInputStream();
}
public interface JcrResource extends Resource {
Node getNode();
}
public interface MappedResource extends Resource {
Object getObject();
}
This would allow for other resources such as a FileResource or an
URLResource (hold on, there is an actual use case: We abstract Scripts
as being Resource based, having an URLResource would allow scripts to be
stored in OSGi Bundles for Sling)
For microsling, we can then safely assume, that the Resource is always a
JcrResource.
WDYT ?
Regards
Felix