The hardest most dreadful part of Inklog is upon me: theming. I've got the majority of the theming code done. But every half hour that I work on it, I change it to an entirely different structure. I'm stuck in a hole in between flexibility and ease of use.
For instance, when writing the image gallery code, do I want to force users to use gallery?page=4 to signify the 4th page? Or do I want to allow them to use that or gallery/4 to signify the 4th page? What if the user speaks Spanish and she prefers gallery?pagina=4? I can allow just one option very easily. However, a very picky user will complain, and, perhaps, alter the code to do it her way. However, once the code is altered in this fashion, I'll be reluctant to take any patches or code modification from them because they'll be using a different starting code base than the "official" code is. Perhaps I should allow the page identifier to be specified in the configuration? This way a user can say "my page parameter is named 'pagina', while another user might use 'page', while another user might use something entirely different. I can give this level of flexibility, it just means a lot more work. I can also skip all the extra work by placing the role of deciphering which page to display on the template itself. This makes the template code more complicated but much more flexible.
If everything is stored in configuration, then the next and previous page URLs can be generated for the template instead of forcing the user to piece them together herself in the template code. One big problem with generating URLs for the template is that the URLs will be specific to a transport type (HTTP, for example). The "URL" to transport that item via XML-RPC or via SMTP might look entirely different and, at that point in the code base, the renderer doesn't know what medium it's being rendered for, and it shouldn't have to. I could use an "internal" URL to the document and then have the template author run the URL through the modifier of their choice to produce the correct URL, but then the modifier will have to know a little something about the transport layer and its designed URLs. I had hoped that the transport layer would be simple to code and ultimately flexible allowing greater use by more people. This would complicate matters considerably.
I think that I'd like to use a combination of the above. Perhaps I'll still hold the page identifier (and other things) in configuration, and, using this data, I can auto-determine how many items to retrieve, and where to begin based on the page identifier. However, I wont construct a nextURL or a previousURL for the template. Instead, I'll provide the template with a nextPAGE and a prevPAGE and allow the template design to construct the URLs appropriate for the system.
I think.
It's all too confusing. There are a million options and none of them are any more "right" or "wrong" than the others. The system is flexible enough that changing something like this after it has been written won't be too difficult. Especially if I don't have to retain backwards compatibility with the old way of doing it. Therefore, it might make the most sense to just pick one (perhaps the easiest to code that retains the most flexibility) and then, after beta testing take suggestions and rewrite it if needed. I think that's what I'll do.
Once again, however, and comments or suggestions you might have will be greatly appreciated.
