http://bugs.dwscoalition.org/show_bug.cgi?id=2159First problem: how to generate the image.
No idea. How do comment counts do it?
To answer that question, I will load the dw-free change history into
my text editor to find the relevant code. A
![[site community profile]](http://s.dreamwidth.org/img/comm_staff.png)
changelog search might also
work for this.
(All commands assume execution at the top level of dw-free.)
hg log -v -r 1: | bbeditLooks like the relevant file is htdocs/tools/commentcount.bml, according
to the original bugfix from Allen. But that file isn't there! Searching
further, it becomes apparent that Dre moved this to a controller in the
course of her crusade to slay BML.
bbedit cgi-bin/DW/Controller/CommentCount.pmNot much code! Most of it is using Image::Magick methods. The only
non-obvious parameter is the size of the image - how big should it be
for our text? We will have to use trial and error.
What should our arguments be? Comment count uses user and ditemid, the
necessary information to figure out which entry is referenced. For our
image, we should only need the text of the invite code itself.
Hmm. Since we only have two states to communicate, used and available,
maybe instead of using dynamic text like comment count does, we should
use icons - perhaps a green check mark for available, a red stop sign
for used. This has the advantage of not requiring the viewer to
understand English.
open htdocs/img/silk/site/tick.pngopen htdocs/img/silk/comments/delete.pngThose are pretty close! Let's see if we can figure out how to return
those images as responses, instead of using Image::Magick. I think the
best way to do this is to redirect the request to the URL of the image,
and use HTTP headers to tell the browser how long to cache it.
Once an invite code is used, it will never revert to being unused. We may
be able to reduce the computation needed for this feature by extending the
cache period once the code activation is detected. On second thought, though,
this may not be true for promo codes, and our tool will work for those too.
Time to decide on the name of our controller and the site URL that will be
used to point to the dynamic image. Once we make those decisions, the new
controller can be written and tested independent of any other work that needs
to be done for this bug. We'll also need to consult DW::InviteCodes for the
function that tells us whether a code has already been used or not.
The actual code as described above doesn't take long to write. Unfortunately,
the name of the source image is advertised to the end user because we used
a redirect. But since the images are intended to be embedded in a page,
the redirection shouldn't be obvious in normal use conditions.
You can read through the resulting patch here:
http://bugs.dwscoalition.org/attachment.cgi?id=5472Let me know if anything I wrote needs further explanation. :)
![[personal profile]](http://s.dreamwidth.org/img/silk/identity/user.png){kind=small}
pauamma
![[staff profile]](http://s.dreamwidth.org/img/silk/identity/user_staff.png){kind=small}
