Validation
Someone caused an interesting bug this morning: the input validation function doesn't check for weird character encodings (Hello, Korea...), which can be parsed and stored correctly but gunk up the XSLT processor. I've modified the node addition system to perform rigorous sanity checks on all incoming data. This has the added benefit of ensuring that your content is valid XML, so mistakes like tags which are closed out of order will be detected.
10 comments
Copyright ©
2006
Aphyr
Comments
I would suggest adding some sort of subcategory-based or fully random access way to view your photos. You have a heck of a lot of them, and going through them a page at a time is a wee bit cumbersome.
Just a thought. (The present design is very elegant, however.)
Photo navigation is getting to be somewhat troublesome--and I don't have the time right now to fully implement a new scheme. What I can tell you is that there are several ways you can modify the results.
The view function returns up to twelve nodes whose properties match any valid field specification in the url. Hence, /view.cgi?title=Meredith will return all matches with a title of Meredith. Similar queries can be performed with date, id, taipu, author, etc, but these are not as useful. If only one node is returned, the XSLT shifts a bit to give an extended view of that node.
Yes, I am working on a search function. ;-)
In addition to the standard field queries, the view function takes four optional settings: sort field, sort order, page, and results per page (with url values: sort, order, page, and rpp respectively.) So, for example, you can craft a URL like this:
/view.cgi?taipu=photo&sort=title&order=ASC&page=2&rpp=24
...Which returns the second page in ascending order of photographs sorted by title with 24 results per page. As you can see, it's powerful, but not especially useful. In terms of UI design, I opted for simplicity in place of complex but powerful query builders. The view function is fairly friendly in that it will remember what values you passed to it last time, so it's easy to browse through with 24 results per page, for example.
What really does bug me at the moment is a lack of a way to return to the thumbnail page of a photograph from a given full view. Actually, there's a quick solution, but it fails in certain cases for reasons I won't go into here. I'm waiting until the more elegant scheme becomes feasible, which requires some architecture changes.
As for "folksonomy" tags, that's definitely on the list. Maybe over winter break. ;-) Thanks for the ideas.
Also, what happened to the alt154.org domain name? Is it no longer accessable, or would a redirect be possible?
Alt154 was a small group of hackers and network enthusiasts of which I was a member. Shortly after I set up this server, alt154.org went down semi-permanently. I believe the administrator is working on getting that machine back online, but he has a number of more pressing concerns, so I'm not really suprised it's still dead.
photo id=129 is missing. Also, t'would be nice if the cheatcodes would stick once entered. (i.e., if they were carried over to the <> buttons. Just a thought.)
You've got some really amazing photos on your site.
A bunch of nodes are missing, actually. To preserve permanent links, node sequences aren't compacted when entries are deleted.
As for the view function options, I completely forgot to re-encode those in the URL. It's fixed now, but I have to run. I'll clean up the unused fields when I get back.
Oh, and thanks! :-D
Are you saying that your content managment system doesn't support international text? Tsk tsk tsk... :-P
Seriously, though, I'm not sure what difficulties there are in supporting international text on the web (can you just use UTF-8, or is it more complicated than that?), but it would be cool if you made Ragnar international.
"the input validation function doesn't check for weird character encodings (Hello, Korea...)"
Or did you mean even outside of UTF-8?
To be honest, I don't know what the encoding was. It didn't match *any* standard I know of--might have just been random data, but it couldn't be translated to UTF-8. I'm only guessing Korea from the link that was in ASCII. The other post (there were two) was similar--no recognizable encoding.
To be honest though, I'm really fuzzy on the whole matter of multi-charset data. The database engine can store pretty much arbitrary strings, but the XML parser complains about non-UTF8 data when it encounters something it can't translate.