Template Versioning Week 3
This week I committed a random theme to svn and created a corresponding Trac ticket as per the assignment description.
In addition I have been reading up on various VCS, but I decided that the best course of action at this point is just to dive in and start coding. This is because there were a few functions specified by the Revision class that I am still a bit unsure about what their exact implementation will need to be in terms of the types of their parameters. Thus far I have coded the first version of the VCSAdapter interface as well as the initial version of the Revision class (though I’m pretty sure some of the methods in that class will change).
After coding the initial Revision class, I am currently debating whether or not to have a class hierarchy for revisions such that there is a base class Revision, and two child classes: PreCommitRevision (I may name it WorkingCopy) and PostCommitRevision. This is in part due to the fact that prior to committing, a Revision doesn’t have a version number. Right now I just specify that an uncommitted revision should have a NULL revision ID.
Additionally, for documentation purposes I wrote some phpDoc comments and made sure that was all setup to generate documentation.
I have been using the group skype chat to ping my mentors about a few things: my dev environment (right now I’m using Eclipse PDT with the subversion plugin + MAMP) and it seems to be working nicely for me, though I’m always open to suggestions… it would be interesting to start a thread about our dev environments with the hope that it doesn’t turn into a “your editor sucks” thread 🙂 .
I also asked about naming classes, etc. and Nacin pointed me to a blog post he wrote on how to name your functions. If any of you guys are also fairly new to WordPress plugin development then I’d highly recommend that you give it a read. The main idea is to prefix your function/class names so that they don’t conflict with existing core or other plugin functions or, alternately, to wrap generically named functions in properly prefixed classes. All class/interface names mentioned above are actually prefixed with Theme_Versioning.
Eg Theme_Versioning_VCSAdapter. I prefixed the interface functions with Theme_Versioning as well.
I plan on starting to write a basic “dummy” VCSAdapter plugin (that implements the interface) for testing purposes so that I can know how the Revision class will need to be implemented in the production version. My development philosophy is basically that thinking and planning are extremely useful to a point, but past that point it’s much more productive to jump in, start coding and then refine and reassess as you iterate, iterate, iterate!
Hopefully this wasn’t too long winded!