[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" <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. Didn't Chuck recently change some API methods to also return  
HTML code?

If blocks don't provide what you need, create a different API method,  
and not the other way round, misusing blocks for something they are  
not intended for.

> I also know that there are other apps that use similar params...I   
> believe Chuck did something similar in Jonah's tag cloud.

That doesn't make it better :)

Jan.

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