Blogging with FLOW3? Almost there!

The last days we had Andreas Förthner up in Lübeck to work on FLOW3 together, and it was indeed very successful!

We split work, so while Robert was working on the Blog package so it can be proudly used for the upcoming FLOW3 tutorial, Andreas worked on the needed - but missing - security, session and login functionality while I dug deep into the persistence code.

As a result we now have a blog with almost complete functionality (multiple blogs, posts, tags, related posts done - comments, categories in the pipeline) whose development pushed the implementation of sorting, limit and offset in the object persistence and made support for easy XML feed output in Fluid reality.

This and next week we'll continue with those efforts and already look forward to put the new stuff to use when coming back to TYPO3v5 development after that!


Migrations in FLOW3

Migrations in Rails are quite nice. Basically what they give you is timestamped files containing steps needed to adjust the database and the data when going up and down in migration history.

I'd keep the timestamped files idea, that leaves the question where do we store what migrations have been applied already? A cache seems too fragile. Something like Migrations.yaml in Data/Persistent?

Then we don't have tables, but classes. No problem, we can map that easily. While we could try to diff class schemas and detect added and removed member variables. We don't need added ones, they will be just stored for any new instances and initialized to NULL (or rather not touched at all) during reconstitution. Removed ones don't do harm, aside from taking up space.

But isn't renaming of class members and changing the data inside what is most problematic? There is no way to automatically find out if "zip" used to be "postcode" and to change "year" from DateTime to integer using wild guesses.

So, Rails got quite some things right there with it's migration concept and making developers write down what needs to be changed.

Since a migration has up and down parts for going forth and back in time, it's easy to revert most things (see the ChangeAlbumYearToInteger migration example in the article linked above). Anyway, some stuff is irreversible, they say: really deleting stuff with drop_table and remove_column. Is it?

This is where TYPO3 was right for quite some time, renaming things to zzz_deleted_foobar instead of dropping right away. Now, if we would rename them and include the timestamp from the migration file, we could even restore such stuff.

I'll look into a nice syntax for this the next days...


Git instead of Subversion?

We are currently looking into Git as an alternative to Subversion. Interested in coming along?

A very nice, although fast-paced, introduction to git is http://gitcasts.com/posts/railsconf-git-talk

This is about git on Windows, from the same guy: http://gitcasts.com/posts/git-on-windows

Now, practical stuff. As long as everything is still in Subversion for us, using git's built-in Subversion bridging is cool. Just read this to get started: http://www.viget.com/extend/effectively-using-git-with-subversion/

I did that for PHPCR and TYPO3CR last week to be able to branch for some experimental stuff I'm doing, and that works beautifully. Creating a branch, committing to that branch, switching back to master, changing something there, committing that to Subversion. All worked well.

Most impressive is the speed with which all that happens (aside from the svn commit). Looking at the history? Diff? All lighting fast.

Granted for the Mac there is GitX, a nice frontend. But git comes with built-in GUI tools as well, git gui and gitk. TextMate has very complete Git bundle, and there is EGit for Eclipse (still rough). And TortoiseGit.

That might be helpful. I hope. :)