> > To be nitpicky, not only is it possible to combine rc with wikipages, its > > been supported (and mostly unused) for ages in the form of > > special:recentchangeslinked. More structured lists could be done with > > content handler (as with all things there are pros and cons to such an > > approach). > > but this wouldn't scale for a Watchlist view - which basically does a > JOIN on recent changes with the items in that collection. > The experimental > http://en.wikipedia.beta.wmflabs.org/wiki/Special:GatherEditFeed which > provides a multiple watchlist type feature is only possible because it > is done in a database. If you believe there is a way to do that, I'd > love to see a prototype from you proving me wrong :-). >
With content handler you can still add random things to the db in your own custom tables, that just functionally depend on the wiki page. Im not suggesting that you parse a page each time you want a list and then merge with rc in php. A good example of this is special:recentchangeslinked - wikipages have links, links go in pagelinks (or other depending on type) table, special page does inner join + filesort just like watchlist to get recently changed pages. > > > >> We'll also hoping to support the filtering of > >> collections via tags which becomes much easier if stored in a > >> database. > > > > "Tags" is another jargon quaigmire in mw land.... > > > > Anyways no particular reason why stuff can't be canonically on a wikipage > > and extracted to db tables (in a similar fashion to link tables). Doing > > that gives you history, reverting, oversight, collaborative editing, talk > > pages, etc for free. (But of course im sure that has its own drawbacks) > > > > [Also its important to keep in mind: it is easy to wax poetic on the > > mailing list about how something ought to be done, much harder to actually > > do it. So take my comment with the salt appropriate of somebody who hasn't > > implemented anything nor has any plans to] > > > >> A watchlist is not a wikipage, so that in my eyes sets a > >> precedent. > > > > Its also unequivocally private. I think a lot of the conflict here comes > > from the dual nature of gather as public/private. > > True, but given we as a community apparently want truely public > watchlists it's time to work out what that looks like :) > [..] > > Agreed, this is definitely an integration problem. I'd like us to > generalise our existing site features and make them less like duct > tape. There is very little code abstraction which has traditionally > made this difficult. I think when we say "this should be a wiki page" > we actually mean something different - in that what we are really > saying is "this should integrate with recent changes" or this should > integrate with X. Identifying those problems will move us forward as > we will find solutions to them and build better software. Starting > with "it should be a wikipage" is approaching the problem from the > wrong direction. This may turn out to be the solution but it's not a > good way to write software efficiently. > Making foo be an instance of X is a good way to solve the problem of make foo behave like x for all properties of x, including those that don't exist yet. (Making interfaces more generic is also obviously good, but when I hear, it should do all the things wiki pages do, I naturally come to the conclusion it should be a wikipage) So, lets turn this around - what aspects of wiki pages don't you want this to have? In my mind a wiki page has the following properties: *Is editable *contains data of some kind (not neccesarily wikitext) *is viewable (biggest conflict thus far) *integrates with tools for managing content (history, rc, revdel, etc) *has a unique name in a common shared namespace (i mean namespace in the cs sense of the word, not mediawiki sense) Which property don't you want? Or are there other properties I forgot that you don't want? If not, what is wrong with wiki pages? --bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
