17 Dec
2008
17 Dec
'08
12:11 p.m.
Sorry for the typo. (loose -> lose)
Could we also need the selectors(as I earlier mentioned but probably did
not get noticed):
- All objects of the class {className} in a {page}, {page}'s {version}
or the entire wiki?
/objects/class/{className}/
/space/{space}/page/{page}/objects/{className}/
/space/{space}/page/{page}/history/{version}/objects/{className}/
possibly with the added:
[?start=offset&number=n]
Fabio Mancinelli wrote:
Eduard Moraru wrote:
Hi, here's my 2 cents re the first
proposal...
Why do we have separation between objects and tags/comments? Shouldn't
the objects mapping be enough to handle them?
Of course objects are enough to handle them but since comments and tags
are very "useful" objects imho it's worth to expose them *also* as
separate resources that can accept specific media types.
I mean, imagine you want to tag a page. If you have
/spaces/{space}/pages/{page}/tags
You can do a POST to that URI by sending, for example, just the new tag.
Something like:
curl -d "foo" http://localhost:8080/spaces/Main/pages/WebHome/tags
If you handle this *only* with objects you will need to post a more
complex media type, typically an XML containing the property name,
value, etc.
Same thing for comments:
curl -d "I like this page"
http://localhost:8080/spaces/Main/pages/WebHome/comments
And does it make sense to have this, when we
already know the guid of
the object we want:
I agree that with guid the old way of identifying objects is useless.
I put it in the resource list because it is the current way of
identifying objects. And maybe somebody has a reason to leave it.
The drawback would be that we loose:
* /tags/{tag1}[,{tag2},{tag3}...][?start=offset&number=n] (The list
of pages tagged with tags {tag1}, {tag2}, {tag3}, ...)
Of course, we could still have it as a convention or we could even
create a generic way of getting this result with other objects as well.
I don't understand why you say we "loose". If we want to expose
a /tags
resource we can do this. And I think that it's a resource worth to be
exposed.
Related to pages, we could also have:
* /pages[?start=offset&number=n] (The list of available pages in the
space in the entire wiki)
Could we need it?
Probably for indexing purposes that could be useful.
Thanks.
P.S.: From what I asked around, it seems that attachments are not
objects. That seems weird to me because, intuitively, the attachments
should be objects on a page of the class Attachment. On attachments you
have versioning, meta-data and an attachment can exist on a page or not,
the behaviour of an object. Could anybody explain the reason for this
please?
AFAIK, it's for historical reason. Yesterday I was asking ThomasM how
attachments work because me too I found it a bit counterintuitive.
Thanks.
-Fabio
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs