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
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
