-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)
iEYEARECAAYFAkjMuRUACgkQIXd7fCuc5vJssACgq8p28nUCIyLSc7dg93QZLJrO
cq4AnjH1kItxbE9O0yjUcfJy2iRs3CsI
=USjj
-----END PGP SIGNATURE-----