phpwiki-talk

[Phpwiki-talk] Wikilens-phpwiki integration: PageList custom column problems

[Scott Y. <sy...@cs...>]

Reini,
My name is Scott Yilek and I'm working on wikilens with Dan Frankowski. 
 We've recently been trying to integrate wikilens with phpwiki and we 
are still having a few issues with the new pagelist custom columns.

The main problem is that we need to send each column more parameters 
than are currently allowed.  Currently each custom pagelist column's 
constructor gets $params which is always assumed to be length 4 with 
$params[3] as the reference back to the pagelist object.  If any other 
parameters are needed, the constructor gets them from the pagelist 
object: $this->_pagelist->getOption('user')  for example.  This doesn't 
quite work for us because we need each column to get its parameters 
independently from the other columns.  For example, we can't do 
getOption('user') if we want a column for each buddy; we need to send in 
the buddy as a parameter.

What would be great is if each column's constructor could accept more 
parameters as necessary.  The way Dan Frankowski proposed originally 
worked well for this because we could create our own column objects how 
we liked them and just sent them into pagelist to be added.  Do you 
think we should go back to this or do you see a better solution?

Thanks!
Scott Yilek
sy...@cs...

Re: [Phpwiki-talk] Wikilens-phpwiki integration: PageList custom column problems

[Reini U. <ru...@x-...>]

Scott Yilek schrieb:
> My name is Scott Yilek and I'm working on wikilens with Dan Frankowski. 
> We've recently been trying to integrate wikilens with phpwiki and we are 
> still having a few issues with the new pagelist custom columns.
> 
> The main problem is that we need to send each column more parameters 
> than are currently allowed.  Currently each custom pagelist column's 
> constructor gets $params which is always assumed to be length 4 with 
> $params[3] as the reference back to the pagelist object.  If any other 
> parameters are needed, the constructor gets them from the pagelist 
> object: $this->_pagelist->getOption('user')  for example.  This doesn't 
> quite work for us because we need each column to get its parameters 
> independently from the other columns.  For example, we can't do 
> getOption('user') if we want a column for each buddy; we need to send in 
> the buddy as a parameter.
> 
> What would be great is if each column's constructor could accept more 
> parameters as necessary.  The way Dan Frankowski proposed originally 
> worked well for this because we could create our own column objects how 
> we liked them and just sent them into pagelist to be added.  Do you 
> think we should go back to this or do you see a better solution?

Have you updated your source, so that I can see it?

I thought putting the required column options to the pagelist object is 
enough, so that the columns can get it from the pagelist object.

you need more usernames? cannot you put the needed array of buddies to 
the $pagelist->_options then?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Wikilens-phpwiki integration: PageList custom column problems

[Scott Y. <sy...@cs...>]

Reini Urban wrote:

> Scott Yilek schrieb:
>
>> My name is Scott Yilek and I'm working on wikilens with Dan 
>> Frankowski. We've recently been trying to integrate wikilens with 
>> phpwiki and we are still having a few issues with the new pagelist 
>> custom columns.
>>
>> The main problem is that we need to send each column more parameters 
>> than are currently allowed.  Currently each custom pagelist column's 
>> constructor gets $params which is always assumed to be length 4 with 
>> $params[3] as the reference back to the pagelist object.  If any 
>> other parameters are needed, the constructor gets them from the 
>> pagelist object: $this->_pagelist->getOption('user')  for example.  
>> This doesn't quite work for us because we need each column to get its 
>> parameters independently from the other columns.  For example, we 
>> can't do getOption('user') if we want a column for each buddy; we 
>> need to send in the buddy as a parameter.
>>
>> What would be great is if each column's constructor could accept more 
>> parameters as necessary.  The way Dan Frankowski proposed originally 
>> worked well for this because we could create our own column objects 
>> how we liked them and just sent them into pagelist to be added.  Do 
>> you think we should go back to this or do you see a better solution?
>
>
> Have you updated your source, so that I can see it?


We haven't updated our source because we're still merging, in part 
depending on the resolution to this question.

However, our tarred source code has our original proposal for custom 
pagelist columns.  The code to best explain our problem is in our 
lib/plugin/UserRatings.php file on lines 204-212.

>
> I thought putting the required column options to the pagelist object 
> is enough, so that the columns can get it from the pagelist object.
>
> you need more usernames? cannot you put the needed array of buddies to 
> the $pagelist->_options then?


Each pagelist column needs to get its own user, and although an array of 
users in PageList that can be accessed by $pagelist->_options can store 
all the users, each column still needs to be sent a parameter to tell it 
which user it's supposed to show ratings for.  Somehow the column needs 
to know which user in the array to use.  So sending the constructor more 
arguments seems necessary, and the way we had it before makes this 
possible and fairly easy.

I tried to put in a hack to still use the way you currently have it set 
up, where on the same lines mentioned above i do,
 
$col = array('_PageList_Column_ratingvalue','custom:ratingvalue', 
$u->getId(), 'right', $u);
$pagelist->addColumnObject($col);

and then in addColumnObject() function in PageList I change
$params[3] = & $this;
to
$params[count($params)] =& $this;
so that the reference is always the last element of the parameter array 
instead of the 4th element.  This works, but involved me editing the 
core code which we are trying to avoid, and it just feels wrong.  But it 
highlights what we need to do: send extra parameters to the column's 
constructor.


Thanks,
Scott