Monday, February 22, 2016

Finish one thing today

This is a short one.

Just got this link on our Slack channel:
https://finishonethingtoday.com/

Simple, but great. It might sound stupid, but I believe it is not only about getting the job done, but sometimes also about leaving your comfort zone. Not to mention delivering results when you have really bad mood. If you do, I keep my fingers crossed that it passes in no time :)
Autor: o

Thursday, February 4, 2016

How working at DocPlanner looks like

This is just a few words about how important it is to give people freedom and engage their passion to achieve your goal. Welcome to DocPlanner.


The office


Of course you will get your desk, MacBook (or anything else that you want), 24" LCD and a comfty chair...




... but sometimes it's better to lay in our fluffiest office ever.




You are not surprised when you open up the fridge and see this one day:




And also not surprised seeing this the day after:




You will get some swag on regular basis!




Or you can play a little with something really classy.



People

We have a great office. I mean, really great. I haven't seen a better office so far, IRL  nor on internet. But what is office without people? People is what matters most!

People are always here for you to help with anything they can.




Even if sometimes you will get hit with few dozens of foam balls...




...or have your shoes glued to the roof when you're on vacation...




...at the end of the day, you love them. Some crazy contest? Why not!




Nerf ride at other department's manager? No problem.




You wouldn't believe it but we also have a girl in IT dept. She helps us manage tickets and repairs our weapons during spare time.




HR also takes care of us, see this awesome cake we got at last developer day!




Sometimes we also have some fun outside.





There are also some other perks that no picture will describe:

  1. Flexible hours.
  2. Remote on demand.
  3. Conferences.
  4. Free coffee, tea, and fresh fruits every wendesday.
  5. Last, but most important: people really care.

Want to join Docplanner? Check out our latest offers or hit me directly!

See ya!




Autor: o

Wednesday, February 3, 2016

Extending Symfony2 services

Have you ever wondered how could you add some extra functionality to existing symfony2 services, like RequestContext or even override some of it's logic? Here's how!


Powerful decorating


One of awesome things about Symfony2 container is that you can decorate services. In my opinion it is really awesome and powerful - you can simply change behavior of literally any component of Symfony, like EventDispatcher of HttpKernel. It's not too good to tweak them on daily basis, but sometimes you hit edge case when this trick is a life saver. In the end it's nothing more than:

  1. Extending class of service you want to alter.
  2. Making changes - adding methods or overriding exisiting ones.
  3. Writing new service definition.
That's it! Let me show you an example. Let's say that we want to do something abstract, for example modify event_dispatcher service. Let's try to modify dispatch() method, so every attempt of dispatching any of events which name start with "foo" will push some info to logger.

Here's original dispatch() method definition (as of Symfony 2.8):


We cannot edit this method in place, so let's create our own class that extends CoontainerAwareEventDispatcher and overrides it:


Now the last part, service definition:


Note that you should not worry about changed service id. Symfony will do the work for you and you will get your modified dispatcher when you try to get event_dispatcher from container.

Of course this is not the only usage of service decorators. You can also use it to, for example, pass some extra services to class you extend, or replace some service definitions. It is also possible to add some public methods, but my suggestion is to do this only when really neccesary - this way you change original vendor's API which can change or lead other developers into confusion.

I hope you found above stuff useful. Happy coding!


Autor: o

Thursday, January 28, 2016

How to inject services into Symfony 2 form

Note

This post addresses latest versions of Symfony 2. In Symfony 3 form instantiation changed, but just a little bit, so most concepts of this post will still be valid.

Sometimes you stumble upon the case when there is need to perform some extra logic while creating or handling a form. Best way to do it without getting your code shattered is to inject services into the form.


What is Symfony form?


In fact, all classes that extend AbstractType are not forms - they are form factories. Real form class is created when you call createForm() method inside your controller. Example:

This is a form definition (this is the reason that it is so popular to name Symfony forms as *Type, because they are form types, not forms themselves).


Real form is created when you do this:

As you can see, after calling controller's createForm() method, Form (not FooType) instance will be returned. Under the hood, your controller calls form.factory service, which in the end calls buildForm() method in your FooType to build the form. This description is of course simplified a bit, if you want to go deeper just click over some sample project and check out The Form Component documentation page.


Why do people create *Form classes instead of *Type classes?


 This is just a matter of fashion. Some people respect that what they are writing is a form type definition, while rest is used to create Form classes from other frameworks. I fall into the second group.


Injecting things


Okay, enough theory, let's describe three approaches of injecting things into your form factory.

Worth noting

When you get into AbstractType's guts, you will notice that there is no constructor defined. That gives us field to easily inject stuff using constructor injection.

The ugliest: inside controller


This is the simpliest, yet (in my opinion) ugliest way of doing this. Greatest con is that your controller now is responsible of injecting things into things. This is not what controller is supposed to do. This is the container job. Only case when this come handy is when you test out things and have some time booked for further refactoring. There's one advantage though - you are able to pass other things than services:


The proper: defining form as a service 


This is another approach, way better than the first one. This is the way that most of people go. Create your form type, and then define it as a service:

Having this, you can build your form like this:

Pros:

  • cleaner controller
  • container handles injection
  • thanks to tags, form factory knows where to look for form

Cons:

  • you cannot inject non-service stuff in here
  • one form type = one service. This is bad on bigger projects


By the way, there's a guy named Joe Sexton who got deeper into this approach on his blog post.


The efficient: Have your own form factory


This is the way that I prefer doing it. Speaking marketing language, let's start with advantages:
container handles injection

  • you can pass non-service things
  • you can make few factories in single service, which is the desired way for bigger projects
  • you can even pass form.factory service into your factory, so you can return Form instances directly from your service (no need to call createForm() in controller 

Okay, so let's say that we write ticket booking system and we  have those three forms:


All of above take part in one flow: ticket booking. It is natural to create one service that will handle creation of all of them. Let's create a service then:


And this is service definition:


Now, to get the form:

I hope that you will find above stuff helpful. Happy coding!





Autor: o
Subscribe to: Comments (Atom)