Menu
▾
▴
[phpesp-dev] Introduction; proposal for phpesp fixes
|
From: Keith S. <ph...@on...> - 2009-04-12 02:22:18
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Greetings,<br>
<br>
I sure hope this list isn't particularly large. I've been using phpesp
for several months now, and have made numerous fixes and enhancements
to the project, which I'd like to give back to the community.<br>
<br>
Before logging bugs and submitting patches willy-nilly, I wanted to do
my first round via the developers list. I
welcome any comments on these before I submit patches and log bugs -- I
want to make sure I'm staying consistent with the community that has
worked on it for so long, and that I remain close to the mission of the
product, not expecting it to do things it wasn't meant to do. Also,
think of this as my attempt to
introduce myself and describe how much I've looked at the product. :)<br>
<br>
Here's the list of major issues I plan to attack, in about this order.<br>
<blockquote>
<dl>
<dt>Signup fails: realm is not quoted in INSERT statement</dt>
<dd>Account creation always fails: the insert statement into the
respondent
table is the culprit, because the value of realm is not in single
quotes. (I gotta wonder, though -- how could this not have come up as a
bug already?)</dd>
<dd><br>
</dd>
<dt>Resume survey link broken after saving in test mode</dt>
<dd>Link to resume survey after saving in test mode is missing the
survey name.<br>
<br>
</dd>
<dt>Emailed survey results must display questions ordered by
position, not by id</dt>
<dd>Emailed survey results display questions/answers by order of
id,
rather than by order they are shown in application. If you add/remove
questions several times, the IDs will definitely not represent the
order in which the questions are presented. The results could be
extremely confusing or even wrong, especially if questions are worded
in such a way that you need to read them in order. (For example, if a
question just says, "If not, why not?")<br>
<br>
[Related <i>enhancement</i>: add the question number to the email. I
have found that when respondents typically correspond with the survey
administrator, or with other respondents, they reference questions by
their number, since it's prominently displayed in the survey. For
instance, "I didn't understand question 12." By including it in the
results that are emailed, it allows the two to be correlated.]<br>
<br>
</dd>
<dt>View private survey results by username i/o rid</dt>
<dd>To view survey results, the admin must select from a random
number
counter. This number is of no meaning to anyone, so doesn't serve well
as a lookup key. With the current implementation, it is impossible to
look up survey results for a specific user, which is a common use case
for private surveys.<br>
<br>
The drop-down should display the username
in it so its contents can potentially be identified. My solution is to
display the username, followed by the response ID (rather than a
generated counter) in parentheses after it. The response ID is included
because, unlike the counter, this value doesn't change. So an admin
might remember, "Oh yeah, joeuser's survey with ID 145 is the one with
the weird answers", and easily retrieve it.<br>
<br>
For public surveys,
it should display only the response_id, rather than an incremental
counter. This is a minor improvement, but a useful one, because --
again -- the number will remain fixed. So looking up the results for
survey 45 will ALWAYS show the results for survey 45, even if other
surveys or results end up getting purged, which may change the number
if it were just counting rows returned by a SQL query.<br>
<br>
This fix
doesn't solve every use case -- it only goes so far with multiple
submissions -- but it's a vast improvement. A further improvement,
which I included, sorts the drop-down box by username followed by
response ID, for the same reason.
<br>
<br>
This can be done for public surveys as well as private ones,
but it's much more meaningful for private ones, as querying by IP
address is going to be almost as useless as querying by response id. My
fix only applies to private surveys, although a future enhancement
could add a config option to control this.<br>
</dd>
</dl>
</blockquote>
The first two, by the way, are very easy one-line fixes. If someone can
easily verify that the first one is a bug for all users, I'd advocate
putting that into the upcoming release. The others can probably wait a
little bit if nobody else has really complained, and I can provide
fixes for those once the impending release branches.<br>
<br>
Cheers.<br>
<pre class="moz-signature" cols="76">-- Keith
AIM/Y! : kswartz26
</pre>
</body>
</html>
|
