Discussion
e.g.
<<CollectLists>> <<CollectLists(filter_selection="Name,Instrument")>>
Thanks for your update; made some short tests over the lunchtime.... btw. moved my files to my public test wiki under: http://www.wikiwiki.ch/Test/CollectLists (some username, etc.. should work)
Feedback:
- Unter Google Chrome (eek) and Internet Explorer 7 (eek eek) there some layout problems. Firefox 3 under Windows and Linux works correctly!
the following html code <input type="submit" name="dbw.submit" value="Filter" style="display: none;"/> works correct on firefox but IEX just remove the style attributes, so an ugly button is displayed above the table.
together with the sinorca4moin theme the table does not size correctly. see my screenshot problem_iex.jpg. I had not enough time to check if it's theme related or not... will do some more investigation.. just want to inform you.
test from 2009-02-05, downloaded your latest changeset
added the common.js patch, removed the # html stuff in your macro to activate the table sort.. and well it works
also the filter for foot::_bar works very well.
- will test it in the next few days a bit more...
- That's a really cool macro. I think it should also go into the main repository, what you think?
- If you have more then one table on a single wikipage, and use the function "filter_selection" you can only filter the first table; second doesn't work
confirmed
align does not center, I know already but have not examined why.
Took the liberty of editing the English of the main page to make it a bit more comprehensible. -- JeroenVet 2009-08-07 11:25:15
thx
There is a little bug in the code that, when sorting is enabled with the common.js patch from FeatureRequests/SortableTables and by de-commenting the line before the final return html, prevents you from having two sortable tables generated by CollectsLists on the same page. The de-commented line should be changed to:
html = html.replace('id="dbw.table', 'class="sortable" id="dbw.table')
-- JeroenVet 2009-08-12 02:59:59
thx for finding this, fixed by http://hg.moinmo.in/moin/extensions/rev/4ec9f902edaf
Questions:
- how can I pre filter some subpages (not with the filter_selection)... e.g. I have 200 projects (active, completed, cancelled, ..) and want only view the 100 running (active) projects. Can I use for this "template" function or is this similarly to "column_heading"?
needs to be implemented, currently I do search by
may be we can add an additional pattern e.g. title:Test-1 active or change te current one.
- Sure a "search" to include only some sub pages would be nice (like "title:foo" or "title:foo -title:bar")
But also a "dict-fullsearch" to only include some pages if a certain dict (definitionlist) exist/notexist would be better.
I mean say the dict is foo::bar then you should be able to include only pages where the dict is foo::bar or also where the dict is not -foo::bar ...
hmm. do you know what I mean You may take a look at the Macro MacroMarket/PageDicts (see Status ~= open).I think yes and I am playing already with re and matching/searching. We want only a row if there is a match in one of the columns. While .* is the default for that.
refactored that feature by replacing filter_pattern with filter_column_value. You can preselect rows to show up only if a key value pair is equal to a given definition e.g. filter_column_value=project:: 1.7-extensions If one wants more than that please support me with a function which can for example destinguish filter_column_value="project eq 1.7-extensions and name ne Bauer" (ne and or should be possible too). That should even not be too difficult for someone else to code.
Do you think that the macro should also support Category stuff? so if you want to use this as a bug-tracking system you could say only CategoryMoinMoinBugConfirmed... well for sure you could also use the dict like Status::Confirmed but maybe using categories has some benefit in general. well I don't know.
I think stabilizing the current features needs to be done before adding more improvements. In general it must not be fixated to page/subpage logic it can be extended to a regular search of e.g. categories. And also it can parse more page elements and not only a definition list. We can do that later, may be the author of PageDicts is also interested I have added a note. I think for bugtracking it could be a nice feature to get them listed also by that macro. I look later today at the javascript code and try to figure out why it is called only from the upper table. MoinMoinBugs/DatabrowserFilter describes the reason
- Can tables additional be sorted?
Yes you have to add another patch from FeatureRequests/SortableTables to common.js by yourself and enable it on the bottom of the CollectLists.py. (Don't forget to reload static stuff in your browser after adding it "shift - reload")
Can I convert my existing table to a page/subpage list? that's an example how I did it for me. That script must be copied to MoinMoin/script/convert (add an __init__.py from one of the other dirs too). You can call it by e.g. MoinMoin/script/moin.py convert table2dict -f $TODAY/Notebooks.txt -b Notebooks from your moin-wiki dir. I have used the action save to store the wiki page Notebooks of the wiki into a file Notebooks.txt beforehand. That creates all the pages in that wiki. If you have choosen to try it out in your private standalone wiki you can move the result by a package to an other wiki by e.g. MoinMoin/script/moin.py export package -u ReimarBauer -s title:Notebook -o $TODAY/Notebook.zip, For further details about the command line interface see HelpOnMoinCommand.
Wishes
Search for Category
I would like to use this Macro for kind of a central phone dictonary. For this I created a new HomepageTemplate, like this:
{{attachment:nobody.jpg|MacroMarket/CollectLists/Discussion|class=mitarbeiterfoto}} = MacroMarket/CollectLists/Discussion = Namen:: Nachname, Vorname Kürzel:: xxx Funktion:: Funktionstitel Abteilung:: [[Abteilungsnamen]] Arbeitsort:: Strasse Nummer, Stockwerk/Raum Telefon:: 044 xxx xx xx Fax:: 044 xxx xx xx Natel:: E-Mail:: vorname.nachname@xxxxx.com == Anmerkungen == ---- CategoryMitarbeiter
Now I would like to collect all this entries / userhomepages together in a big list. The problem is that the current macro only supports subpages to collect and I do not want to move all homepages under a page, because this would also break the wiki username stuff.
my example:
<<CollectLists(column_heading="Namen,Funktion,Abteilung,Telefon,e-Mail",categoryname="CategoryMitarbeiter")>>
well, just a wish, thanx anyway!
bye -- MarcelHäfner 2009-02-26 17:15:27
Hi Marcel
I would be glad if you try this yourself. I think the currrent search logig by the pagename should be changed to a search pattern. needle = '^%s/(.*)' % pagename ← needs to be changes and the parameter and a bit more of code. Don't add a new parameter.
Look at from MoinMoin.search import searchPages and for an example how to use it at e.g. action.PackagePages.searchpackage
searchPages can be used to find everything or bundle pages of interests.
cheers
-- ReimarBauer 2009-02-26 22:30:02
I Reimar
Changed the macro to only supporting CategoryNames... will try later to mix the "Category" and "Parent/Child" stuff together. I think about just to check if the given pagename starts with Category then it's a CategorySearch otherwise it would use your function.
btw. I'm completely new python/development, so be mercy with my code but tips & tricks are always welcome bye Marcel
--- CollectLists.py.original 2009-02-27 12:37:17.025355600 +0100 +++ CollectLists.py.neu 2009-02-27 14:44:04.337409100 +0100 @@ -28,6 +28,7 @@ from MoinMoin.util.dataset import TupleDataset, Column from MoinMoin.wikidicts import Dict from MoinMoin.widget.browser import DataBrowserWidget +from MoinMoin.search import searchPages Dependencies = ["pages"] @@ -62,7 +63,9 @@ # Don't filter if syntax was wrong filter_column_value = u'' - needle = '^%s/(.*)' % pagename + #needle = '^%s/(.*)' % pagename + #Marcel: because there is no child or subpage under the pagename exist, so no / to search for + needle = '^%s(.*)' % pagename filterfn = re.compile(needle).search pages = request.rootpage.getPageList(exists=1, filter=filterfn) if not pages: @@ -71,7 +74,17 @@ # ignore Template pages filterfn = request.cfg.cache.page_template_regexact.search templates = request.rootpage.getPageList(filter=filterfn) - subpages = [page for page in pages if page not in templates] + #subpages = [page for page in pages if page not in templates] + #Marcel: subpages are not generated from the parent/main pages + + #Marcel:s earching now for the category pages = cat:CategogoryName + needle = "cat:%s" % pagename + searchresult = searchPages(request, needle) + subpages = [] + for title in searchresult.hits: + if not wikiutil.isSystemPage(request, title.page_name) or not title.page.getPageStatus()[0]: + subpages.append(title.page_name) + if not subpages: return _("Subpage of '%(pagename)s' does not exist or you don't have enough rights.") % {"pagename": pagename} subpages.sort() @@ -116,8 +129,14 @@ row.append((wikiutil.escape(value, 1), wikiutil.escape(value, 1))) else: row.append('') - parent, child = name.split('/', 1) - link = page.link_to(request, text="/%s" % child) + #parent, child = name.split('/', 1) + #Marcel: because the categorypage is not the parent page of the wanted page + parent = pagename #there is no need for this string... but for to stay compatible let it be + child = name + + #link = page.link_to(request, text="/%s" % child) + #Marcel: don't want the / before every pagelink + link = page.link_to(request, text="%s" % child) data.addRow([link] + row) if transpose: data.columns.extend([Column(link, label=link, align=align)])
Thanks for this modification. Was just what I was looking for. I am not a fan of subpages. I think they should only be used when they cannot exist by themselves, so in other words form a logical part of the main page. Not as as an organizing principle of the wiki. Categories are imho a better choice for that. However, there are some problems with the above code. I have attached my modification on it. This modification accepts an explicit category_name as a parameter, in the absence of which it uses the pagename from which it is called as the category_name. Some unnecessary code is commented out and a bug resolved. CollectLists.py.neu.mod -- JeroenVet 2009-08-07 11:25:15
I hope you like the idea of a search_expression http://hg.moinmo.in/moin/extensions/rev/d89a77a21e55. It depends on your expression now if you want to do a title or category or whatever search. default is the old Subpage search.
Further to post above. You have to apply this patch for the above version of CollectLists to work in version 1.9.1:
@@ -27,7 +27,6 @@ from MoinMoin import wikiutil from MoinMoin.Page import Page from MoinMoin.util.dataset import TupleDataset, Column -from MoinMoin.wikidicts import Dict from MoinMoin.widget.browser import DataBrowserWidget from MoinMoin.search import searchPages @@ -102,12 +101,12 @@ # use keys from template page elif Page(request, template).exists(): page = Page(request, template) - page_dict = Dict(request, template) + page_dict = requests.dicts[template] column_heading_keys = page_dict.keys() else: # fallback use the keys of the first subpage page = Page(request, subpages[0]) - page_dict = Dict(request, subpages[0]) + page_dict = request.dicts[subpages[0]] column_heading_keys = page_dict.keys() data = TupleDataset() @@ -121,7 +120,7 @@ for name in subpages: page = Page(request, name) - page_dict = Dict(request, name) + page_dict = request.dicts[name] if filter_column_value and page_dict.get(filter_key, '') != filter_word: continue row = []
I guess it can be used for the other versions as well. Cheers! -- JeroenVet 2010-01-23 14:35:14
Hi Jeroen; if you like you can add your working 1.9 version direct to the correct macro page MacroMarket/CollectListsCategory. -- MarcelHäfner 2010-01-26 11:39:02
We should implement a search param. needle = '^%s/(.*)' % pagename should become a parameter (search). So that a user can give a regex to search for. Then he can choose by the regex if he wants pages of a category or subpages or whatever. The parameter pagename is then needless. Template Pages should be always excluded from the search results. May be as default it can do the subpages search.
An extension of the alphabetical sort is in preparation -- ReimarBauer 2010-02-04 11:34:49