[dev] [cvs] commit: ansel/lib/Block recently_added.php

[Jan Schneider]

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

> Quoting "Jan Schneider" <jan at horde.org>:
>
>> Zitat von "Michael Rubinsky" <mrubinsk at horde.org>:
>>
>>> Quoting "Jan Schneider" <jan at horde.org>:
>>>
>>>> Zitat von "Michael Rubinsky" <mike at theupstairsroom.com>:
>>>>
>>>>> Quoting "Jan Schneider" <jan at horde.org>:
>>>>>
>>>>>> jan         2008-06-06 05:34:27 EDT
>>>>>>
>>>>>> Modified files:
>>>>>>  lib/Block            recently_added.php
>>>>>> Log:
>>>>>> Blocks are for end users, don't let them set URLs.
>>>>>
>>>>> This breaks using the blocks via the API from an external  
>>>>> gallery website.
>>>>
>>>> Then there has to be done a separate API method. The primary use for
>>>> blocks is for users to customize their portals. And it doesn't make
>>>> sense to provide them with url parameters if they don't know what they
>>>> are for and what is going to break if they use them.
>>>
>>> IMO, this greatly reduces the utility of being able to retrieve
>>> blocks  via the api. I do understand the concern, though. Not sure
>>> if it's  possible, but what about having a set of seperate block
>>> params that  are hidden to the user...or maybe allowing params that
>>> are not  explicitly defined in the block to be passed in?  Not sure
>>> I see how  another api method would overcome the limitation of the
>>> params not  being present in the blocks?
>>
>> If you'd be using a different API method you would be completely free
>> to pass any parameters around that you like and retrieve anything
>> back.
>
> Not to make too big a point of it, but that would mean basically   
> duplicating the block code in the api methods...and would mean  
> adding  a new api method for each "block" we want to be able to use.  
>  I guess  the solution here then is to either extend an existing api  
> method (if  an appropriate on exists for the particular block in  
> question) to  return the data or the HTML...or just build the  
> "block" in the client  code with data obtained via the api.

Exactly, that would be the correct approach IMO.

Jan.

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