[dev] Api consistency for share listing

[Jan Schneider]

Zitat von "Michael J.Rubinsky" <mrubinsk at horde.org>:

>
> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von "Michael J.Rubinsky" <mrubinsk at horde.org>:
>>
>>>
>>> Quoting Alfonso Marín Marín <almarin at um.es>:
>>>
>>>> Hello,
>>>>
>>>> Cheking module APIs, i have noticed that listCalendars in  
>>>> kronolith return an array of ID's, but listTasklists in nag and  
>>>> listNotepads in mnemo return the datatree objects instead the ID's.
>>>>
>>>> ¿Is it any reason to do that? I think all of then should behave  
>>>> like listCalendars
>>>
>>> Agreed. Can you create a ticket on bugs.horde.org so it doesn't  
>>> get forgotten about?
>>
>> We should probably have both: a generic listShares() method in all  
>> apps that support shares, and (still consistent)  
>> listCalendars/Tasklists/Etc() methods for the specific applications.
>
> What would the difference(s) be between these two? If it is that one  
> method returns the actual share object, is that something we really  
> want to do via the API? Having an application-level object be  
> returned via the API doesn't make much sense to me.  Alternatively,  
> if we want the information available in the share object, we could  
> return some sort of array/hash/json/whatever representation of the  
> object properties, not the object itself.
>
> Or, are you just suggesting that we have a listShares() method that  
> is just an alias of list[Calendars|Tasklist]()?

No, I indeed want listShares() to return the shares. It doesn't matter  
if they contain application-specific information, as long as they all  
extend the general Share object. I still see this useful because we  
might want to operate on the application shares from a central place  
at one point, e.g. in a share editor in the admin sections.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/