phpwiki-talk

[Phpwiki-talk] Re: Development on phpwiki

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

Dan Frankowski schrieb:
> I am going to devote more time to Phpwiki this summer. I may also get 
> two undergraduates working for 30 hours/week. I'd really like to push 
> forward recommenders everywhere and wikilens.org so it becomes very 
> cool. For me, recommenders everywhere only works if the features we're 
> excited about get into a widely available and well-known system. For a 
> refresher, see
> 
> http://www.wikilens.org/index.php/RecommendersEverywhere
> http://www.wikilens.org/index.php/WikiLens

I could add to this.

> Moreover, there are certain features we absolutely must have. These 
> include:
> 
> - Working and easy-to-use user/page permissions

my current top goal.

> - Sorting on the PageList widget 

sortby=rating? ok.

> - others will arise (e.g., things in PageList, making categories more 
>   "natively" supported in Phpwiki, etc.)

This is new to me. Can you describe this?
Do you mean dynamic categories? We had some kind of patch for this 
feature some years ago. page : category relation in the database.
Other wiki's tried that also.
We didn't like that. We thought that manual fixes (links at the bottom 
of each page) and backlinks are easier, just the engine should support 
the needed features people are proposing.

> I am happy to work on these things, but I hesitate because if you are 
> also working on them, my proposed changes may not be useful, hence that 
> is wasted work. On the other hand, if you don't believe in them (for the 
> sake of argument, making category pages special), they will never be 
> accepted.

I want to bring out a release today, so I will answer tommorrow.
There are still several known problems, and lot of tests to do.

> Thus, I would be interested in hearing more from you about how you think 
> of the Phpwiki development process. That is, what should I keep in mind 
> to make my work most likely to be accepted by the Phpwiki team? How can 
> I best help out the Phpwiki team, given my interests?
> 
> This sort of thing might include just plain knowing more about you or 
> other Phpwiki developers. Possible examples:
> 
> - How much time do you devote to it?

Currently full time. In the near future about 4 hrs a week. Not as less 
time as in the last two years for sure.

> - How long have you been around?

phpwiki development since my acadwiki, which started with 1.2 and then 
came jeffs 1.3.x tree.
for some early software development see my website.

> - What is the team style?
> - What development processes do you think work well?
> - Where could there be improvement?
> - How would you like to grow the Phpwiki development team so that it can 
>   make faster progress?
> 
> My boss said I should feel free to call long distance to talk about 
> these things, if you are willing. Give me a phone#, propose a time.

I'd rather prefer email or wiki discussion. I worked as teleworker for 
several US companies before and was never convinced in the usefulness of 
phone conversation.

> Some things I've noticed:
> - Phpwiki is downloaded often (~200 times a day).
> - You are the most active developer right now. Most other developers are 
> inactive, a couple (e.g., Joby) seem somewhat active.
> - You seem to be working on many things at once.
> - More documentation would be nice. The Phpwiki Phpwiki has a lot of 
> good stuff, and a lot of what might be old cruft.
> - People are asking for stability.
> - Phpwiki releases have some features which work well, and others which 
> are experimental or non-functional. The difference is not always obvious.
> - People are asking for features.
> - The email list phpwiki-talk is the best place to gather right now
> 
> I would be eager to help where I can. I am not entirely useful, though. 
> For example, unfortunately, I do not know the code or functionality as 
> well as you or other developers, so I cannot take over documentation.

At least you can start if you feel a urgent desire to so. We already 
discussed this. Others can fix wrong things then.

I have to stop now, because I have to prepare a radio show about the 
nature and importance of science, and several misleading paths in the past.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: Development on phpwiki

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

Dan Frankowski schrieb:
> http://www.wikilens.org/index.php/RecommendersEverywhere
> http://www.wikilens.org/index.php/WikiLens

BTW: Do you have some kind of public or semi-public archive (ftp,cvs) of 
the wikilens code?

I saw at bimike.net that people already wrote a lot of new apps, and I 
am very interested.

 >> WikiLens and Presidents :: 2004-04-09 09:45:08

And I want to see how the buddie feature developed in the meantime, to 
make it eventually WikiUserNew independent. I.e. to provide some useful
hooks in the core.
Lately I added some kind of generic adodb/sql query function, mainly for 
action=upgrade, but togther with your generic pageiterator this might be 
something needed.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: Development on phpwiki

[Dan F. <dfr...@cs...>]

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> http://www.wikilens.org/index.php/RecommendersEverywhere
>> http://www.wikilens.org/index.php/WikiLens
>
>
> BTW: Do you have some kind of public or semi-public archive (ftp,cvs) 
> of the wikilens code?
>
> I saw at bimike.net that people already wrote a lot of new apps, and I 
> am very interested.


Cool! I set up a nightly script to make the latest publicly visible site 
available in a tarball at http://www.wikilens.org/wikilens-src.tgz.

> >> WikiLens and Presidents :: 2004-04-09 09:45:08
>
> And I want to see how the buddie feature developed in the meantime, to 
> make it eventually WikiUserNew independent. I.e. to provide some useful
> hooks in the core.


I agree it would be useful to think about the relationship between 
WikiUserNew and buddies (by the way, singular "buddy"). To integrate 
1.3.9 into our site, I ended up moving things around, and making a 
RatingsUser class that is pretty much independent. That is, it could be 
ripped out of WikiUserNew and put somewhere else, although that might 
cause a bunch of files to have to include that new place.

> Lately I added some kind of generic adodb/sql query function, mainly 
> for action=upgrade, but togther with your generic pageiterator this 
> might be something needed.


We don't have a very generic pageiterator yet. We are still working on 
integrating our newest preference apps with PageList. Right now, 
PreferenceApp (e.g., SodaApp, SoftwareProjectApp) is not based on PageList.

Dan

[Phpwiki-talk] Re: Development on phpwiki

[Dan F. <dfr...@cs...>]

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> I am going to devote more time to Phpwiki this summer. I may also get 
>> two undergraduates working for 30 hours/week. I'd really like to push 
>> forward recommenders everywhere and wikilens.org so it becomes very 
>> cool..
>

>> - Working and easy-to-use user/page permissions
>
>
> my current top goal.


Great.

>
>> - Sorting on the PageList widget 
>
>
> sortby=rating? ok.


Not exactly. Two things here so far:

1. We need to sort on things not in the DB (e.g., predicted value). 
Thus, I am adding sorting of pages in memory based on 
column::_getValue() (incidentally for any column, which is nice).
2. We need multiple columns of the same type (e.g., 'ratingvalue' type 
for my buddies A, B, C, D, etc. on the same PageList).

I have been delaying my reply until I have posted some code for this on 
WikiLens, but it's going slower than I'd hoped, so I'm replying without 
code in order to give you a heads-up. 2 is more challenging-- it 
requires identifying column by something other than name or type. Right 
now, I am trying to convert the code so it can still use the name, but 
immediately translates it into column # (0, 1, 2, 3, etc.) for the 
purposes of button headings specifying sorting. I'll post this as soon 
as I can.

>
>> - others will arise (e.g., things in PageList, making categories more 
>>   "natively" supported in Phpwiki, etc.)
>
>
> This is new to me. Can you describe this?
> Do you mean dynamic categories? We had some kind of patch for this 
> feature some years ago. page : category relation in the database.
> Other wiki's tried that also.
> We didn't like that. We thought that manual fixes (links at the bottom 
> of each page) and backlinks are easier, just the engine should support 
> the needed features people are proposing.


Unfortunately, I cannot be specific yet. I don't think we understand 
what we want. I'll just say that a category is looking more and more 
important to me. Random thoughts:

1. Imagine recommending movies versus sodas. Each of those 
recommendation "domains" is so different, you might want the recommender 
to act different in each.
2. If ActionMovie is a subcategory of Movie, you might want traits of 
Movie (e.g., structured data fields) to 'inherit' from the Movie category.
3. You might want to get notification whenever a new item enters or 
leaves a particular category (which is different from page-level 
notification).
4. Category-level modification time (when's the last time someone 
changed something in this category?).
5. List all category pages (currently: pages with the CategoryPage plugin).

These are ideas floating around category that make it look pretty 
important. Only 3 and 4 are concrete. Not sure if the back-links is 
enough to support  this stuff eventually.

>> Thus, I would be interested in hearing more from you about how you 
>> think of the Phpwiki development process. That is, what should I keep 
>> in mind to make my work most likely to be accepted by the Phpwiki 
>> team? How can I best help out the Phpwiki team, given my interests?
>>
>> This sort of thing might include just plain knowing more about you or 
>> other Phpwiki developers. Possible examples:
>>
>> - How much time do you devote to it?
>
>
> Currently full time. In the near future about 4 hrs a week. Not as 
> less time as in the last two years for sure.


What does this mean? Why currently full time? Why 4 hours/week later?

>
>> - How long have you been around?
>
>
> phpwiki development since my acadwiki, which started with 1.2 and then 
> came jeffs 1.3.x tree.
> for some early software development see my website.
>
>> - What is the team style?
>> - What development processes do you think work well?
>> - Where could there be improvement?
>> - How would you like to grow the Phpwiki development team so that it 
>> can   make faster progress?
>>
>> My boss said I should feel free to call long distance to talk about 
>> these things, if you are willing. Give me a phone#, propose a time.
>
>
> I'd rather prefer email or wiki discussion. I worked as teleworker for 
> several US companies before and was never convinced in the usefulness 
> of phone conversation.


Er .. okay. I think there are advantages to each, but I respect your 
preference. So what do you think of the development process (i.e. 4 
questions above)?


>> I would be eager to help where I can. I am not entirely useful, 
>> though. For example, unfortunately, I do not know the code or 
>> functionality as well as you or other developers, so I cannot take 
>> over documentation.
>
>
> At least you can start if you feel a urgent desire to so. We already 
> discussed this. Others can fix wrong things then.


Okay.

> I have to stop now, because I have to prepare a radio show about the 
> nature and importance of science, and several misleading paths in the 
> past.


Thanks for your time.

Dan

Re: [Phpwiki-talk] Re: Development on phpwiki

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

Dan Frankowski schrieb:
> Reini Urban wrote:
>> Dan Frankowski schrieb:
>>> - Sorting on the PageList widget 
>> sortby=rating? ok.
> 
> Not exactly. Two things here so far:
> 
> 1. We need to sort on things not in the DB (e.g., predicted value). 
> Thus, I am adding sorting of pages in memory based on 
> column::_getValue() (incidentally for any column, which is nice).
> 2. We need multiple columns of the same type (e.g., 'ratingvalue' type 
> for my buddies A, B, C, D, etc. on the same PageList).

Ok. Sorting as generic slow PageList method, to be able to sort on every 
column. Even better.

> I have been delaying my reply until I have posted some code for this on 
> WikiLens, but it's going slower than I'd hoped, so I'm replying without 
> code in order to give you a heads-up. 2 is more challenging-- it 
> requires identifying column by something other than name or type. Right 
> now, I am trying to convert the code so it can still use the name, but 
> immediately translates it into column # (0, 1, 2, 3, etc.) for the 
> purposes of button headings specifying sorting. I'll post this as soon 
> as I can.

>>> - others will arise (e.g., things in PageList, making categories more 
>>>   "natively" supported in Phpwiki, etc.)
>>
>> This is new to me. Can you describe this?
>> Do you mean dynamic categories? We had some kind of patch for this 
>> feature some years ago. page : category relation in the database.
>> Other wiki's tried that also.
>> We didn't like that. We thought that manual fixes (links at the bottom 
>> of each page) and backlinks are easier, just the engine should support 
>> the needed features people are proposing.

> 
> Unfortunately, I cannot be specific yet. I don't think we understand 
> what we want. I'll just say that a category is looking more and more 
> important to me. Random thoughts:
> 
> 1. Imagine recommending movies versus sodas. Each of those 
> recommendation "domains" is so different, you might want the recommender 
> to act different in each.
> 2. If ActionMovie is a subcategory of Movie, you might want traits of 
> Movie (e.g., structured data fields) to 'inherit' from the Movie category.
> 3. You might want to get notification whenever a new item enters or 
> leaves a particular category (which is different from page-level 
> notification).
> 4. Category-level modification time (when's the last time someone 
> changed something in this category?).
> 5. List all category pages (currently: pages with the CategoryPage plugin).
> 
> These are ideas floating around category that make it look pretty 
> important. Only 3 and 4 are concrete. Not sure if the back-links is 
> enough to support  this stuff eventually.

Well, this sounds like wikilens extensions to existing plugins.
I would rename them then.

We currently have subpage and category pagegroups. Maybe seperate 
indexing and queries (also search) for page groups will be useful.
But we haven't spoken about so far.

>>> Thus, I would be interested in hearing more from you about how you 
>>> think of the Phpwiki development process. That is, what should I keep 
>>> in mind to make my work most likely to be accepted by the Phpwiki 
>>> team? How can I best help out the Phpwiki team, given my interests?
>>>
>>> This sort of thing might include just plain knowing more about you or 
>>> other Phpwiki developers. Possible examples:
>>>
>>> - How much time do you devote to it?
>>
>> Currently full time. In the near future about 4 hrs a week. Not as 
>> less time as in the last two years for sure.
> 
> What does this mean? Why currently full time? 

Because I quit working full-time in Oct 2003, and will start soon again 
full-time. Now I do work half-time.

 > Why 4 hours/week later?

Because my new job will give me more free time than the last one, which 
exhausted me.

>>> - What is the team style?
>>> - What development processes do you think work well?
>>> - Where could there be improvement?
>>> - How would you like to grow the Phpwiki development team so that it 
>>>   can make faster progress?
> 
> Er .. okay. I think there are advantages to each, but I respect your 
> preference. So what do you think of the development process (i.e. 4 
> questions above)?

Just send patches for the beginning.

>>> I would be eager to help where I can. I am not entirely useful, 
>>> though. For example, unfortunately, I do not know the code or 
>>> functionality as well as you or other developers, so I cannot take 
>>> over documentation.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Sorting on any PageList column (WAS: Re: [Phpwiki-talk] Re: Development on phpwiki)

[Dan F. <dfr...@cs...>]

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> Reini Urban wrote:
>>
>>> Dan Frankowski schrieb:
>>>
>>>> - Sorting on the PageList widget 
>>>
>>> sortby=rating? ok.
>>
>>
>> Not exactly. Two things here so far:
>>
>> 1. We need to sort on things not in the DB (e.g., predicted value). 
>> Thus, I am adding sorting of pages in memory based on 
>> column::_getValue() (incidentally for any column, which is nice).
>> 2. We need multiple columns of the same type (e.g., 'ratingvalue' 
>> type for my buddies A, B, C, D, etc. on the same PageList).
>
>
> Ok. Sorting as generic slow PageList method, to be able to sort on 
> every column. Even better.
>
>> I have been delaying my reply until I have posted some code for this 
>> on WikiLens, but it's going slower than I'd hoped, so I'm replying 
>> without code in order to give you a heads-up. 2 is more challenging-- 
>> it requires identifying column by something other than name or type. 
>> Right now, I am trying to convert the code so it can still use the 
>> name, but immediately translates it into column # (0, 1, 2, 3, etc.) 
>> for the purposes of button headings specifying sorting. I'll post 
>> this as soon as I can.
>

Okay, we have PageList column sorting on wikilens.org.

I attach our new PageList.php. I do not attach a patch file because:

a) so much of it looked changed (often in small ways)
b) some of the "changes" are actually that we are on 1.3.9, not the 
latest CVS PageList.php, so we probably have some change merging to do.

Anyway, below I describe a little more the changes in the attached 
PageList.php, and I hope they are generally useful.

Dan

Here are our changes. At the high level, we wanted

a) To be able to sort on any column, even if not in the DB (e.g., 
predicted value).
b) To be able to have multiple columns of the same type (e.g., rating 
value for Sam, Joe, Mary, etc.). This requires referring to the columns 
by an id other than column name. We chose number (col# 0, 1, 2, 3, ..).

In detail, in order of how they show up when I use tkdiff (a graphical 
diff):

- We don't yet have creator, owner, etc. (probably from 1.3.10?).
- require_once()s, so our PageListTest.php unit tests work
- add _PageList_Column_base::getHeading() because at one point I thought 
we might have to override on a subclass
- ditched heading() because no one seemed to be using it anywhere
- add parms to button_heading(): $pagelist to refer to it in the 
sortby() function, $colNum to generate HTML for headings.
- add _PageList_Column_Base::_compare() for default sorting.
- add more column types: numbacklinks is probably useful, the rest 
(coagreement, minmisery, averagerating) are WikiLens-specific, and we'll 
end up pulling them out later
- We don't yet have author/creator changes (1.3.10 or CVS?)
- add _PageList_Column_pagename::_compare
- add _PageList_Page class for sorting
- add PageList::_columnsMap to map column names to #s
- PageList::_rows => PageList::_pages to signify we are storing 
_PageList_Page entries now
- Set PageList::_options right away, so it is accessible to all functions
- Change getTotal(), isEmpty(), addPage() to work with _pages.
- Make a _renderPageRow() that turns a _pages entry into HTML, so we can 
delay its HTML rendering until after we sort it
- don't have maxLen() .. don't know what that is
- Get rid of sortable_columns() .. they're all sortable now
- Add getOption() function to get options because it is convenient to 
not get PHP warnings about "array index doesn't exist"
- Change _addColumn(): add commentary, have it call addColumnObject()
- Add addColumnObject() to allow outside objects to add columns of the 
same type, by repeated calling of this function.
- Add _pageCompare() and_sortPages() for sorting
- We don't have any paging code yet .. this will unfortunately perhaps 
interfere with sorting in some ways.
- _generateList() and _generateTable() use _renderPageRow()

Re: Sorting on any PageList column (WAS: Re: [Phpwiki-talk] Re: Development on phpwiki)

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

Dan Frankowski schrieb:
> Reini Urban wrote:
>> Dan Frankowski schrieb:
>>> Reini Urban wrote:
>>>> Dan Frankowski schrieb:
>>>>
>>>>> - Sorting on the PageList widget 
>>>>
>>>> sortby=rating? ok.
>>>
>>>
>>>
>>> Not exactly. Two things here so far:
>>>
>>> 1. We need to sort on things not in the DB (e.g., predicted value). 
>>> Thus, I am adding sorting of pages in memory based on 
>>> column::_getValue() (incidentally for any column, which is nice).
>>> 2. We need multiple columns of the same type (e.g., 'ratingvalue' 
>>> type for my buddies A, B, C, D, etc. on the same PageList).
>>
>>
>>
>> Ok. Sorting as generic slow PageList method, to be able to sort on 
>> every column. Even better.
>>
>>> I have been delaying my reply until I have posted some code for this 
>>> on WikiLens, but it's going slower than I'd hoped, so I'm replying 
>>> without code in order to give you a heads-up. 2 is more challenging-- 
>>> it requires identifying column by something other than name or type. 
>>> Right now, I am trying to convert the code so it can still use the 
>>> name, but immediately translates it into column # (0, 1, 2, 3, etc.) 
>>> for the purposes of button headings specifying sorting. I'll post 
>>> this as soon as I can.
>>
>>
> 
> Okay, we have PageList column sorting on wikilens.org.
> 
> I attach our new PageList.php. I do not attach a patch file because:
> 
> a) so much of it looked changed (often in small ways)
> b) some of the "changes" are actually that we are on 1.3.9, not the 
> latest CVS PageList.php, so we probably have some change merging to do.
> 
> Anyway, below I describe a little more the changes in the attached 
> PageList.php, and I hope they are generally useful.
> 
> Dan
> 
> Here are our changes. At the high level, we wanted
> 
> a) To be able to sort on any column, even if not in the DB (e.g., 
> predicted value).
> b) To be able to have multiple columns of the same type (e.g., rating 
> value for Sam, Joe, Mary, etc.). This requires referring to the columns 
> by an id other than column name. We chose number (col# 0, 1, 2, 3, ..).
> 
> In detail, in order of how they show up when I use tkdiff (a graphical 
> diff):
> 
> - We don't yet have creator, owner, etc. (probably from 1.3.10?).

No, owner/creator is in latest CVS only.
It's a bit slow now, I have to investigate why.

> - require_once()s, so our PageListTest.php unit tests work
> - add _PageList_Column_base::getHeading() because at one point I thought 
> we might have to override on a subclass
> - ditched heading() because no one seemed to be using it anywhere

I left it in. maybe someone or some theme wants to keep the old style.

> - add parms to button_heading(): $pagelist to refer to it in the 
> sortby() function, $colNum to generate HTML for headings.
> - add _PageList_Column_Base::_compare() for default sorting.
> - add more column types: numbacklinks is probably useful, the rest 
> (coagreement, minmisery, averagerating) are WikiLens-specific, and we'll 
> end up pulling them out later

I've moved plugin or theme specific columns into the resp. files, to 
clean up PageList.

> - add _PageList_Column_pagename::_compare
> - add _PageList_Page class for sorting
> - add PageList::_columnsMap to map column names to #s
> - PageList::_rows => PageList::_pages to signify we are storing 
> _PageList_Page entries now
> - Set PageList::_options right away, so it is accessible to all functions
> - Change getTotal(), isEmpty(), addPage() to work with _pages.
> - Make a _renderPageRow() that turns a _pages entry into HTML, so we can 
> delay its HTML rendering until after we sort it
> - don't have maxLen() .. don't know what that is

This is the max strlen of all pagenames, to get consistent pagename 
column width on paging.

> - Get rid of sortable_columns() .. they're all sortable now
> - Add getOption() function to get options because it is convenient to 
> not get PHP warnings about "array index doesn't exist"
> - Change _addColumn(): add commentary, have it call addColumnObject()
> - Add addColumnObject() to allow outside objects to add columns of the 
> same type, by repeated calling of this function.
> - Add _pageCompare() and_sortPages() for sorting
> - We don't have any paging code yet .. this will unfortunately perhaps 
> interfere with sorting in some ways.
> - _generateList() and _generateTable() use _renderPageRow()

Very good! Finally I don't have to do all the work alone.
I'll add this tomorrow.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/