I am totally digging having Flickr photos and Ma.gnolia bookmark integration into this site.
If you missed the announcement on the Vine Type or AspAdvice sites, I released Vine Type 1.5 with support for Flickr and Ma.gnolia.
Flickr
Vine Type now supports up to 26 different sets of Flickr images. This means you can display photos of your vacations in one area and photos of your pets in another area. Vine Type will retrieve photo URLs based on your Flickr tags and return only the URLs of photos with the associated tag along with your name of the image.
The Vine Type web site also shows how to display a random sampling of a larger set of images.
Ma.gnolia
Again, up to 26 sets of Ma.gnolia bookmarks. The Ma.gnolia API returns a URL to a website thumbnail, so I had to incorporate that into the feature.
Your Ma.gnolia bookmarks are retrieved based on tags in a similar fashion to the Flickr API, and Vine Type churns out XHTML with the bookmark title, description, and thumbnail. The title and thumbnail are linked to the web site URL. There are several ways to style these after they come back -- I'm hiding the title and just showing the thumbnail in the left sidebar of this site.
The other cool thing is that the bookmarks can be private, so you can create a private set of bookmarks, give them all a unique tag, then display them on your website without displaying them on Ma.gnolia.
Other enhancements
There are several new template variables associated with timestamps to allow greater control over timestamp display, and I've removed the previous dependence on naming the Vine Type aspx file "default.aspx". That last one is especially important for folks who test-drive Vine Type on their exisiting sites, I've found. Now folks will be able to rename default.aspx to something else such as test.aspx and Vine Type will function fine in a live environment.
So if you downloaded Vine Type in the past and ran into this problem, please try again -- and accept my apologies for not getting to this sooner.
Comments
Cool features Carl! Do you have some documentation describing the upgrade process from earlier versions?
For the most part, the upgrade process is:
There was a change to a navigation widget in version 1.1 that would require replacing the template css file. Also I recommend changing the template file in this release as described in the v1.5 announcement. It's a straightforward find and replace change.
Even folks running early versions .98 or .99 can simply drop the Vine Type 1.5 dll into the bin directory and they've upgraded.
To take advantage of new features, you'll need to add entries to your config file but there should be no harm done by upgrading. And if something looks funny, just put the old dll back in and email me for advice.
Simple enough, I like that. I just noticed that you had only just released v1.4 in September. I'm liking this rapid release cycle. Are you trying out the "release early and often" mantra?
Not necessarily "early" but definately "often." More like "As appropriate and often."
Which is not practical with complicated upgrade scenarios. I read about folks setting aside entire weekends to upgrade their sites. And the upgrade instructions are hilarious! Uninstall every plug-in ... backup your database ... Uninstall your application ... install the new version ... and on and on and on with caveats at every turn.
When your product's upgrade instructions are to plop the new dll down on the server why not release often?
PS: Thanks for asking!
Well done! I'm loving your upgrade process Carl. No funky directories, no nightmares. One file, that's it. Odd question though, can the DLL migration handle any necessary data structure updates and changes as well? If so, my hat off to you good sir!
Jakob,
Again, thanks for asking. Vine Type reads in an XML Schema file, then loads the database from an XML file. I think there was a schema change early in the Beta process where I added an element to the schema.
XML is great in this regard, and folks get the new schema in a 100 percent seamless fashion. Say the new schema has n elements per article node. It reads in the old XML file with n-1 elements per node but that's okay. Going the other direction, however, won't work.
Then I generate the new default value for the new element and when I write out a new article node, it has n elements. Instant upgrade. The user never sees it happen.
XML has its downside but the schema changes go in easily. I just have to code to allow for a missing element.