Posted: July 25th, 2010 | Author: tolleiv | Tags: extension, sprite, typo3 | No Comments »
TYPO3 4.4 ships with a long list of improvements. One of them is the sprite API which was developed during T3UXW09. It extends the iconWorks API and enables to retrieve any backend-icon from a central sprite.
As extension maintainer there are several ways to use these new parts of the API you can either just use it to display core icons, you can include your own icons and retrieve it with the new API or you can include your own sprite and retrieve the separate icons.
Use sprite icons
Using sprite icons is pretty easy, to get a checkmark icon you could use this:
t3lib_iconWorks::getSpriteIcon('status-dialog-ok');
The list of all available icons can be retrieved using the ‘spriteiconoverview‘ extension which I just recently pushed into the TER 
Add your own icons
The API also provides the possibility to include your extension’s icons using either single icons or your own icon sprite.
Using single icons can be done with the following code in your ext_tables.php or ext_localconf.php:
$icons = array(
'myicon' => t3lib_extMgm::extRelPath('myextension') . 'myicon.gif'
);
t3lib_SpriteManager::addSingleIcons($icons, 'myextension');
Using this icon is easy again:
t3lib_iconWorks::getSpriteIcon('extensions-myextension-myicon');
If your extension comes with a larger amount of icons you might want to use your own sprite. This includes your sprite as a image file and a CSS file. The css file should look like this:
.t3-icon-extensions-myextension {
background-image:url(../../typo3conf/ext/myextension/myextension_sprite.gif);
}
.t3-icon-extensions-myextension-icon1 { background-position: 0px 0px; }
.t3-icon-extensions-myextension-icon2 { background-position: 0px -16px; }
The path to your sprite needs to be relative to the typo3temp/sprites/ folder, from where the (temporary) merged CSS file will be included.
This sprite can be included using:
$icons = array(
'extensions-myextension-icon1',
'extensions-myextension-icon2'
);
t3lib_SpriteManager::addIconSprite(
$icons,
t3lib_extMgm::siteRelPath('myextension') . 'myextension_sprite.css'
);
As you see it’s quite easy to include the new API, the API provides some further options for overlays and further modifications which I didn’t mention here. And as a final motivation this is a comparison between old and new API to get a “back” button:
// old API
$icon = '<img' . t3lib_iconWorks::skinImg($this->doc->backPath,'gfx/goback.gif','width="14" height="14"') . 'alt="" />';
// new API
$icon = t3lib_iconWorks::getSpriteIcon('actions-view-go-back');
—-
The sprite API is quite new and my knowledge about how to use it is also relatively fresh – so please let me know if you’ve any remarks or questions.
Btw. special kudos for his involvement during the implementation of this nice feature and many many thanks for helping me to understand it, to Steffen Ritter 
—-
Further reading:
—-
Posted: July 9th, 2010 | Author: tolleiv | Tags: git, typo3 | 1 Comment »
I just found that Peter shares the slides of the Git workshop from the T3DD10 on slideshare. Since this 4 hour workshop was – for many reasons – one of my favorites during the T3DD10, I felt that it’s worth to mention it. And due to the fact that TYPO3 is moving very fast towards Git it’s worth to look at them — Open workshop slides
Btw. at the beginning I didn’t belief that a Git workshop could fill 4 hours – now I don’t think that shorter workshops make any sense 
Posted: June 30th, 2010 | Author: tolleiv | Tags: git, typo3, version control | Comments Off
When I first saw a presentation about Git 2 years ago I liked it, but I was convinced that Subversion covers all I need. Things have changed and especially the bad performance of Subversion for larger repositories and the need to commit things without messing up the official trunk motivated me to look up how to get started with Git. If you need more reasons why you should look into Git, you’ll find them in [7] – anyways it’s worth to have a look how I managed to work with it
There are basically 2½ different tasks during the “daily” development.
- Create a local working copy a.k.a clone the repository
- Fix a bug or implement a feature and create a patch file with the changes
- Receive a patch and review it – eventually commit the changes
0. Repository initialization
Getting started and creating the repository from an existing Subversion repository looks like this:
mkdir templavoila
cd templavoila
git svn init -t tags -b branches -T trunk https://svn.typo3.org/TYPO3v4/Extensions/templavoila
git-svn fetch
This will pull the entire SVN history into your local Git repository – use “git-svn fetch -r ” to reduce the amount of imported revisions.
To keep your repository up-to-date you need these commands:
git stash
git-svn fetch
git rebase trunk
git stash apply
If you followed the SVN trunk/tags/branches convention you should see that it also finds tags and branches during the import. But using “git branch” afterwards you’ll see that there’s only one local branch called “master”. That’s where Git shows it’s strength the first time, because it distinguishes between local and remote branches. Work can only be done within local branches, whereas the existing SVN branches are only recognized as “remote” branches so far. To list all remote branches you can use “git branch -r”. If you followed the trunk/tags/branches convention, you should see your SVN tags and branches within this list – otherwise you might want to read [8]. To make a remote (SVN) branch available in your local repository use:
git checkout --track -b tv_1-4 templavoila_1-4
1. Working with the repository
Starting to work on a new feature or a bug always starts with a new branch in git:
git branch issue00012345
git checkout issue00012345
You’re now working in the “issue00012345″ branch and all commits will just be committed to that branch. Once you made changes you can either just commit all modifications with:
git commit -a
or add particular files and commit only these files with:
git add fileA
git add fileB
git commit
or with a nice pre commit preview which lets you decide which lines you want to commit:
git add --patch
git commit
Preparing the patch for the mailingslist:
In a pure Git workflow “git format-patch” is used to communicate patches, but due to the fact that there’s a Subversion repository involved either the old style diff / patch or a workaround needs to be used to communicate changes.
Creating a patch which works for the mailinglist can basically be done using:
git diff --no-prefix master > myPatchFile.patch
An alternative workaround to create proper SVN diff files (including svn revision etc..) can be found in [10] it’s used very straight forward:
git svn-diff > mySvnPatchFile.patch
2. Review and commit patches
Reviewing the patch someone sent to the list:
As “usual”
patch -p0 < myPatchFile.patch
can be used to apply patch files.
Once the files passed the review the changes can be committed using “git add” and “git commit” as shown before.
Committing to Subversion:
Once you committed everything to your local repository you’re able to perform this command to “forward” your commits to the Subversion repository.
git svn dcommit
Practically every single commit within git will also be reflected as a single Subversion commit. For several reason this might not always suit your situation.As a workaround you could merge all commits during the merge of your feature branches into the master branch using:
git merge --commit --squash issue00012345
git svn dcommit
Of course I don’t recommend to do this for your regular work since have small granular commits is always better.
Sources and further reading
[1] Patch-oriented development made sane with git-svn
[2] An introduction to git-svn for Subversion/SVK users and deserters
[3] Git – SVN Crash Course
[4] Getting the GIT checkout
[5] An Illustrated Guide to Git on Windows
[6] git svn workflow –
feature branches and merge
[7] whygitisbetterthanx.com
[8] Multiple branches using git-svn
[9] Effectively using Git with subversion
[10] Git Workflow with Upstream SVN
Notes
- Don’t try to dcommit to https://svn.typo3.org/TYPO3v4/Extensions/templavoila unless you know what you’re doing – I just used it to show you that it’s even working with large history projects.
- For projects hosted on forge.typo3.org there might be a native git support soon – stay tuned
- Let me know if you had problems with any of the snippets
- Further information about the review process for the TYPO3 Core and several other TYPO3 related projects can be found on typo3.org
Posted: June 15th, 2010 | Author: tolleiv | Tags: typo3, workspaces | 1 Comment »
One of the enterprise features TYPO3 has to offer is versioning and workspace handling. Kasper did a great job when he initially brough these featues into TYPO3. Unfortunately during the last years they became orphans and nobody really took care of them. There are multiple reasons for that, one was that Kasper didn’t allow big changes, another one was that everyone was somehow able to live with the existing odds they had but probable the most important one was that it was just to complicated to improve them alone without knowing the big picture.
The good news is that these times are over and that some important changes to improve workspace handling are planned for
the upcomming TYPO3 4.5 (read more on TYPO3.org) and the cool news is that I was lucky enough to be part of that team and that I was able to attend a great “kickoff” meeting two weeks ago.
What changes we plan can be found on TYPO3.org, a detailed protocol of the meeting can be found here in addition.
I’m happy to be part of that and I hope everyone on the team can keep up his/her motivation.
Posted: May 8th, 2010 | Author: tolleiv | Tags: typo3, viral web | Comments Off
I’m pretty busy in these days and unfortunately there’s not much time to write blogposts. In detail there’s currently a long list of feature wishes and bugs for TemplaVoila which need my attention and in addition I also already started to prepare a workshop for the T3DD10 about Git*.
Just to keep this blog alive this is what I found interesting during the last weeks:
For TYPO3 enthusiasts especially the changes within the TYPO3 Core regarding the integration of further T3UX09 results and all the small changes which happen to get 4.4 ready might be of the biggest interest (https://svn.typo3.org/TYPO3v4/Core/trunk/ChangeLog). Besides that Sebastian Kurfürst tweeted that he finished the last chapter of his Extbase/Fluid book and Amazon says that they deliver it in the first weeks of July. I think once his book is out we’ll see much more people starting to work with Extbase and Fluid.
It also seems that the TYPO3 v5 project — called “Phoenix” — is getting more and more relevant. They decided to scrumify the delvelopment and started to do Sprints to achieve quick and visible results. Sounds like a good way to go – let’s see how long they keep that up. Besides that there’s also an interesting mail Robert Lemke posted in a newsgroup to answer the rumors about the why v5 takes so long and why they had to start from scratch and so on – very interesting statements.
Besides that you might like these bits and bytes:
*If anyone wants to help with the Git workshop or has suggestions feel free to contact me. I don’t feel really prepared for it yet but I also think that someone has to present Git to the TYPO3 community since Subversion kinda sucks in certain aspects – also the workshop itself is not confirmed yet but I’m pretty sure it will happen since lot’s of people are interested to hear about it.
