• Det står ingenting på denne lappen – There is nothing on this ticket
• Overbevist – Satisfied
• Vellykket – Successful
• Du er nødt til å… – You really have to…
• Ta en blund – Take a nap
• Kan jeg få en sånn – May I have one of those/these? (Whilst pointing at something)
• Kjempeflaks – Really lucky
• Kollisjonsputer – Airbags
• Jeg må tidlig opp – I have to be up early
• Litt skuffa – A bit disappointed
• Vidunderlig – Wonderful
• Jeg er lei av… – I’m sick of…
• Jeg vil du skal… – I would like you to…
• Åpenbart – Obviously
• Ødelegge – Destroy
• Takk og lov! – Thank goodness!

*vis words that I like:

• Sannsynligvis – Probably
  
• Tilfeldigvis – Accidentally
• Forhåpentligvis – Hopefully
• Heldigvis – Luckily

* P.s. When I write på engelsk I am borrowing a format that I really like, used by Kari in her Norwegian blog. I urge you to subscribe to that one too!

Check it out: http://elephpants.blog.linpro.no/2009/10/02/unwanted-end-of-sessions/

This issue has come up many times in the symfony forum and on IRC, and whilst it seems like a fairly trivial one, it is important to discuss the best practice around it. Often we want to modify a form based on something outside the form’s scope, like a user’s credentials or the page they are on, or maybe some session values – lets take the example of a dropdown widget where admin users get to see a few more options.

The bad way

Everyone that has been using symfony for a while is aware of the context singleton. This magic sprite allows us to grab all sorts of information about the context we are in, including the user, session, request, view, and many more things. Whilst it certainly has its place, most of the time, however, we should avoid using it. The clue to the reason why is carefully disguised in the class name “Context”.

When we refer to a context in our code, we are locking ourselves in to the fact that the context must exist, so every time we use it we are basically saying that this class can now only be used in a symfony project with a fully initialised symfony stack hanging over it.  This becomes a problem in things like unit tests, where you have to mock up a loaded context object with bells and whistles in order to test a simple function or class.

So this is what you might think of doing:

// In your form class
public function configure()
{
  $choices = array(1 => "something boring", 2 => "something dull");
 
  $currentUser = sfContext::getInstance()->getUser();
 
  if ($currentUser->isAuthenticated() && $currentUser->hasCredential("admin"))
  {
    $choices += array(5 => "something cool", 6 => "something leet"); 
  }
 
  // ....
}

The reason this is bad is that the forms framework is a standalone framework – it should be possible to pick up your form class and drop it into any project. It should also be possible to test it independently of symfony, without being tied in by sfContext. So what is the better way?

The dependency injection approach

You might read that and think “woah, this is getting complicated!” but we’re not talking about dependency injection containers here, we’re simply saying that you can make your form object depend on something to run. The thing it depends on should not be the context singleton, it should be the minimum thing that the form needs to operate correctly – which in this case, is a user object that supports credentials.

// In your actions.class.php
$this->form = new myForm(array(), array("currentUser" => $this->getUser()));
 
// In your form class
 
// ...
if (!is_object($this->getOption("currentUser")) || !($this->getOption("currentUser") instanceof sfUser))
{
  throw new InvalidArgumentException("You must pass a user object as an option to this form!);
}

The test here is where we are making this form “dependent” on a user object. In this case we are insisting that the object is an instance of sfUser, which you may argue is tying us in to symfony again, but you could use any test here to ensure that the object will have the necessary functionality you need, maybe check for the existence of a “hasCredential()” method for example.

When writing a test for this form class, we now only need to instantiate a user object and load it with some credentials – much easier than doing the same thing and locking into a context singleton. There may be other times when this form could be useful in a lightweight environment, where you can get speedy access to a user object but don’t want the overhead of the symfony context – you might not think of one now, but it’s best to code this way and you’ll have less reasons to kick yourself further down the line.

The completed code, for our single widget form

// In your form class
public function configure()
{
  if (!is_object($this->getOption("currentUser")) || !($this->getOption("currentUser") instanceof sfUser)) 
  {
    throw new InvalidArgumentException("You must pass a user object as an option to this form!");
  }
  else
  {
    $currentUser = $this->getOption("currentUser");
  }
  $choices = array(1 => "something boring", 2 => "something dull");
 
  if ($currentUser->isAuthenticated() && $currentUser->hasCredential("admin"))
  {
    $choices += array(5 => "something cool", 6 => "something leet"); 
  }
 
  $this->widgetSchema['my_dropdown']    = new sfWidgetFormChoice(array("choices" => $choices));
  $this->validatorSchema['my_dropdown'] = new sfValidatorChoice(array("choices" => $choices)); 
}

Wrap up

Think about this example the next time you think about modifying a query based on a user object, or session value in a peer class, or Doctrine table class… Maybe you should have passed a parameter there too? Every class and method you write, think about how you can reuse it, will it even be possible the way you have written it? If something simply must be coded in a symfony specific way, think about making a parent and a child class for the problem you are trying to solve. In the parent class, you can make things as generic as possible – so you can re-use that class to your heart’s content. In the child class, you can add the symfony specific code – kept to a minimum.

I haven’t been too active lately with the Norwegian blog, mostly because of the usal lame excuse regarding time and too much work and all that. One thing I have been doing lately is reading, or at least trying to read the Chris Ryan book “Blodpenger”, and during this reading several words crop up that are interesting – but which I forget way too quickly.

Hopefully by sharing some of them here, it will help me to remember, and also give me a quick reference point for when I inevitably forget again!

Some words – from prologue and chapter 1

• Sylige – visible
• Stram – tight (fingrene var stram)
• Forvridd – contorted, mangled, twisted (På ringfingeren satt en forvridd gullring)
• Dugg – dew
• Grundigere – thoughtfully
• Bøye – bend (han bøyde seg = he bent over)
• Tilhøre – belong to (måtte ha tilørt en kvinne)
• Halvannen – one and a half
• en Grop ( a ditch)
• Peste – panted (den peste mens den løp)
• Ryggsøyle – spine
• Mistanke – suspicion
• Nøyaktig – precisely
• Gjørmete – muddy
• Gned – rubbed
• Slør – veil
• Blikk – look, glance (hun løftet blikket)
• Lynraskt – very quickly, blazingly, “at light speed”
• Påføre – cause, bring upon
• Som ventet – as expected (den var som ventet)
• Ifølge – according to
• Somle – faff, dawdle, time waste
• Myke halsen – stiff neck
• Klesplagg – Garment, Item of clothing (et nytt klesplagg)
• Øreflippen – the earlobe
• Slikket – licked
• Åndsfraværende – vacantly (Han slikket øreflippen hennes åndsfraværende)
• Ånd – spirit, Fraværende – absent
• Bekymret – worried, concerned (det som bekymret ham)
• Fortjener – deserve
• Halvt fordervet – half to death (han slo henne halv fordervet)
• Tillatelse – permission

And that’s not even the whole chapter…

Cascading / Transitive persistence

In Doctrine there are two ways to define a cascade, one will tell Doctrine what to do, the other defines how that condition is set up on your database when Doctrine builds the sql commands. The reason this was a gotcha for me, is that we only ever used one of the types, and were completely unaware of the other one! The Doctrine manual is quite long, and unless you’ve read it several times cover to cover it’s easy to miss these things – although next time I will at least be reading the appropriate section of the manual, regardless of what I think I already know.

So, you want a delete cascade? You might do something like this in your yaml file:

PhoneNumber:
  columns:
    user_id:
      type: integer
  relations:
    User:
      class:       User
      local:       user_id
      foreign:     id
      onDelete:    CASCADE

What the above definition says is that this phone number is connected to a user, and if the user record is deleted – in order to maintain database integrity with foreign keys, the corresponding phone number records should also be deleted. This is perfect behaviour – but Doctrine does not do anything with it, it simply sets up the database to handle it, so if you are using a dbms that supports delete cascades then everything will be handled at the database level.

Adding softDelete to the equation

So here comes the gotcha, all of our tables use the softDelete behaviour – which means that instead of the row being deleted, a flag is set (deleted=true) which then magically makes the row appear deleted in all your queries (Providing you have dql callbacks turned on). This means that the row is never actually deleted at the databse level, and thus the cascade is never applied. Now I always knew this, I mean I wouldn’t install a behaviour before knowing what it does right? What I wrongly assumed was that the call to onDelete: CASCADE would take care of “soft deleting” my relations too, but it doesn’t, in fact that line is effectively useless when combined with softDelete. For that you need to set the doctrine cascade parameter:

PhoneNumber:
  actAs: [softDelete]
  columns:
    user_id:
      type: integer
  relations:
    User:
      class:       User
      local:       user_id
      foreign:     id
      foreignType: one
      cascade:     [delete]

Now the behaviour will be as expected. If you are using softDelete and your application has a lot of delete operations, you should take some time to understand what is happening, because Doctrine must fetch and load all of the related objects and then check their relations and cascade settings and so on, so in a large system deleting a single user could result in quite a lot of database queries and cpu time. It is for this reason that database level cascades are preferable, so maybe being more picky about which models you apply the softDelete behaviour would be prudent. Learn more about Doctrine Transitive Persistance.

Defining types of foreign key relations

This one is also one of those “read the manual” situations, but similarly to the above example what caught us out here is that we again thought that there was only one option for defining what we wanted to do, when in fact there were too parameters we should have been considering. This gotcha also only applies if you are defining your relations in a yaml file, as the problem lies in it’s interpretation when Doctrine builds the base classes.

Look at the following example:

User:
  columns:
    payment_id:
      type: integer
      notnull: true
  relations:
    Payments:
      class:       Payment
      local:       payment_id
      foreign:     id
      foreignType: many

The intention was that a user could have multiple payments, and it seemed to make sense to define it using the foreignType parameter above, however when the model was built – this always related in a $this->hasOne(…) statement being created, because what was actually happening is that we were not defining the relationship at the other end, we were actually defining it at the local end! So foreignType: many actually means “Many users can have one payment” – hence the interpretation of $this->hasOne(..)

In actual fact using the foreignType key is mostly useless, as Doctrine “guesses” this side of the relationship. It’s only necessary if Doctrine guesses incorrectly and you need to override it, our example above should actually have been using the “type” parameter, which defines the relationship from the other perspective:

User:
  columns:
    payment_id:
      type: integer
      notnull: true
  relations:
    Payments:
      class:    Payment
      local:    payment_id
      foreign:  id
      type:     many

Adding [ foreignType: one ] to this schema declaration would have no offect, as Doctrine would guess it to be the case (in this example). The above declaration will now correctly form a $this->hasMany(…) statement in your base class. To make it easy to remember, just forget about foreignType all together unless you come across a special case where you nee it – and prepend the word “has” to the type parameter, that should give you a clue as to what you are defining.

So, with one-to-one relationships, the type parameter is unnecessary, with one-to-many you specify the type: many (Doctrine will guess the one part) and with many-to-one you also do not need to specify the type as it will be guessed based on how you’ve got the relation set up from the other model’s perspective.

Read more about relations in the Doctrine manual.

Conclusion

it’s hard to believe that after 6 months of coding a large application that currently has over 30,000 lines of code and growing we could have a schema file with several useless calls to onDelete: CASCADE and even more useless calls to foreignType. It’s even harder to believe that in the early days of the project, we simply overrode the setup methods to add the relations that we needed, when the Schema.yml file failed to come up with the goods. Next time I think I’ll spend a little more time with the documentation, although we are of course experts now – so maybe next time we won’t need to?

If you use PHP and have ever wondered why you get something so cool for free, maybe a little tang of guilt can creep in. Contributing to the language in one way or another is a great way to pay something back, and there are many ways to do so, one of which is to write tests….

Tests keep the code sane. Every time things change, the tests can be run to make sure that everything still works ok – just like the php tests you (hopefully) write in your own projects. The best way to maintain this stability for the language itself is also to have as much code covered by tests as possible.

Every year, the PHP team organises TestFest, aiming to introduce testing to the masses in the most straightforward way. All you have to do is find out where your nearest event is being held and sign up. You will be given everything you need and assisted in every way to help you write at least one test – hopefully many more.

Details of TestFest 2009 Norway have just been released, if you are in the area, check it out!

The word Aker comes up a lot in and around Oslo, and after a brief discussion about it yesterday, it struck me that using familiar names can help us to learn less familiar vocabulary.

The word comes from old Norse for “acre” and was the name of an old farm, which helped to name a church (the old Aker church) which then went on to name the district and spawn the other things we know and love today. You can read more about that on the Wikipedia page.

Words to learn that “Aker” can help us to remember

• Hus = House – You should be familiar with Akershus (county), literally “the House of Aker” but don’t read too much into that without reading the following reference also:
• Festning = Fortress – Akershus Festning is the fortress overlooking the Oslo Fjord. It’s name fully expanded means something like “The fortified house of Aker”. The district of Akershus was named after the fortress, not the other way around!
• Elv = River (feminine so “the river” is “elva”) – Akerselva is the river that runs through Oslo, literally “the river of Aker”
• Østre = Eastern – one of the main roads running in an Easterly direction out of Oslo parallel to the E6 is Østre Aker Vei, literally “Eastern Aker road”. We may already know that “Øst” means “East” so this helps us to remember the method to convert to “Eastern”.
• Brygge = Jetty – You need to be in the marine industry to know exactly how this would translate in English (wharf, quay, mooring, dock, etc), but jetty is probably closest. Situated in the Oslo habour is the trendy district of Aker Brygge where you will find shops, restaurants, apartments and more. (You should also be aware that Brygge can be a verb – to brew).
• Sykehus = Hospital – “Aker Sykehus” and “Akershus sykehus” (Known as A-hus) are 2 of the hospitals serving Akershus.
• Gamle Kirke = Old church – Gamle Aker kirke is one of the reasons for the name, and is the oldest existing building in Oslo.
• Bakke = Hill – Akersbakken is the hill that Gamle Aker Kirke resides on, and also the name of the adjacent road

Summary

Hopefully reading some interesting facts and making some connections in your brain between vocabulary and real world situations will help to improve your (and my) Norwegian. I have certainly learned a few things from producing this blog post, and I hope you do from reading it

It has been a while since the last one, sorry about that! I have been orienteering in England and dealing with a bout of conjunctivitis but I’m back in the office now and raring to go. Today’s phrase got a bit messy because I’m still a bit tired and out of practice – so forgive me, but also be thankful there are a few points to discuss

Today’s word: Oversvømmelse

• Translation: Flood
• Pronunciation: aw-ver-shvur-merl-ser

First attempt

Det har vært så lenge
siden jeg har skrivet
noen ting, derfor trenger jeg
en oversvømmelse av inspirasjon!
Siden jeg er ikke helt sikker om
setningen opp der, skal jeg også
sier at oversvømmelse i fjor
i England var kjempedårlig og
mange folk måtte dro fra husene deres.
Det var bra vær for ender!

Errors/Observations:

• There is not really a Norwegian equivalent for “it has been so long since” so we should stick with “it is so long since”, det er så lenge siden
• å skrive, skrev, har skrevet
• derfor does not really work here, we can replace it with at jeg trenger
• Ikke placement can be tricky, in this sentence (a subordinate clause) ikke must precede the finite verb: Siden jeg ikke er helt sikker
• Om and På can also be tricky for English speakers – here we should use sikker på
• The next sentence is a bit messy, and is better written as forige setning, or sentingen over
• “Skal jeg også sier at” is better written as vil jeg også si at. Vil and Skal can also cause some difficulties, since skal generally means “will, shall” and vil generally means “would like to, want to”. Sier should also have been in the infinitive, å si.
• kjempedårlig does not really work in this context, so we can introduce a new word: forferdelig (terrible)
• dro should be dra, as in English you would say “had to leave” not “had to left”.
• Since we are talking about their own houses, we should say husene sine, otherwise we could be referring to “their” as in anybodies houses.

Final edit:

Det er så lenge
siden jeg har skrevet
noen ting at jeg trenger
en oversvømmelse av inspirasjon!
Siden jeg ikke er helt sikker på
forrige setning, vil jeg også
si at oversvømmelse i fjor
i England var forferdelig, og
mange folk måtte dra fra husene sine.
Det var bra vær for ender!

Translation:

It has been so long since
I have written anything that
I need a flood of inspiration!
Since I'm not totally sure about
the previous sentence, I will also
say that the floods last year
in England were terrible and many
people had to leave their houses.
It was nice weather for ducks!

In fact, I applied for a job for the Norwegian “Russ service” web service (russ.no) which would have been pretty cool, as then I would have been russ@russ.no

Anyway, the reason I started writing this was because of the Russ is not short for Russell blog post which I’ve just read, do take a look and think of how it is for me and my name during this time of celebration and chaos.

• English translation: Fast, rapid, quick
• Pronunciation: hewt-ti

First attempt

Om sommeren i England
noe tid i August er det et veldig stort, og veldig
fint arrangement som heter "RIAT".
Når vi bodde i England, prøvde vi alltid
å besøke det fordi det var kjempe morsomt å
se på alle de hurtigefly som kom fra
mange land :o)

Errors/Observations:

• I wasn’t sure about the first sentence as I wanted to say “during the Summer, some time in August” but that does not really work the same way in Norwegian. Adding a few commas and changing it to “en helg i August” works in this case.
• Similarly in English, adding veldig before every adjective in a sentence is a little bit “over-emphasising”, so the latter one(s) can be skipped
• kjempe morsomt – this is one of those joining up word scenarios! Quite often with kjempe followed by an adjective, the words can be joined – in this case kjempemorsomt
• One last error, and it’s a bit of a noob mistake as we were doing so well… we are talking about a definitive collection of aircraft “de hurtige…” so we must add “ene” to form de hurtigeflyene
• Når changes to Da – see comments below

Final edit:

Om sommeren i England,
en helg i August, er det et veldig stort, fint arrangement 
som heter "RIAT".
Da vi bodde i England, prøvde vi alltid
å besøke det fordi det var kjempemorsomt å
se på alle de hurtige flyene som kom fra
mange land :o)

Translation:

During the Summer in England, one weekend in August,
there is a very big, fine show/arrangement called "RIAT".
When we lived in England, we always tried to visit it because
it was really fun to see all the fast planes that came
from many countries :o)

Link: RIAT – The Royal International Air Tattoo