-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nikola Smolenski:
Ah, OK. (BTW, now the tool itself doesn't work...)
(fixed)
I imagined a different syntax, similar to wikisyntax, but this is fine too. To comment on it:
i think a lot of your comments are answered in the README (/home/river/reports/README). nonetheless, i will answer again here with some rationale, since it's not obvious why something might be done a particular way.
# First, one should be able to include comments, for example like this :)
in fact, everything in the file that's not a %directive is a comment.
%name Last 100 edits %description Shows the last 100 edits for a user %category Users # Probably, this should be changed into 'categories', as one tool can # realistically be in several categories, as is the case with Interiot's tstoc
well, the category is used to sort the reports in the web interface: http://toolserver.org/~river/cgi-bin/reports?wiki=dewiki_p having multiple categories would mean a report appeared twice in the list. (which might not be a bad thing when there are many reports, perhaps...)
# I don't understand, in %(username)s what is the 's' at the end doing?
that indicates it's a string (Python database query format syntax). MySQLdb only supports strings, so it's somewhat redundant, but still required. (it might be possible to implement a custom format syntax, but it would have to be done very carefully to avoid SQL injection.)
# Also, there is some potential for clash here, as % is modulo operator in # MySQL. It will be rarely used, but still...
unfortunate, but any syntax is going to have that problem at some point. (btw, you can write '%%' for a literal %.)
%variable username, username, Username # The final Username is name displayed in the form, but what are the first # two?
# Also, what is needed is the ability to specify variable type. Username # could be of type 'text', but there is also need for booleans (checkbox), # arrays (radio buttons), maybe more.
%variable <name>, <type>, <display name>
the only type right now is username, which is just a text box. but in the future, i imagine this would have some kind of auto-complete for usernames.
%fields page, Page, page_namespace, page_title timestamp, Time, rev_timestamp %end
# I don't understand this, as I can't look at the tool's output.
it's explained in the README; basically, <type>, <title>, <params...> for example 'page' takes two params, the SQL namespace and title columns, and constructs a title from them.
# I imagined that here, one would be able to specify patterns that would # shape the output, similar to %query. For example: # %report # html: <td><a href="http://%(wiki_url)/wiki/%(page_title)">%(page_title)</a></td> # wiki: * [[%(page_title)]] # %end # Variable names here would be column names from the query, + variable names # from the form, given in %variable, + "magic" variables like this %(wiki_url)
i don't really like the idea of embedding markup in every query, since it means any change to the markup will require editing every query (and hoping there aren't any mistakes). in general i think most reports can be done using the different %field formatters (even more complicated ones, like 'thumb' to embed a thumbnail of an image). the aim isn't to replace _every_ report tool; very complicated reports can still remain as separate tools.
One more thing is that the list of wikis should be handled better, and should be on the same page as other form elements.
it can't easily be, because the list of reports depends on which wiki you select (some reports might only make sense on one wiki).
the list of wikis could be done better; i haven't done any work on the interface yet, until the logic is fairly complete.
Also, how are new reports made by different users going to be handled? Everyone would just put them in reports directory in his home dir?
when the tool moves to stable, reports will be in (for example) /projects/reports/reports/*.query. all tool developers will have access to that directory.
- river.