Debug Nicer with Assets

Sometimes we start developing a new project and forget to issue:

php app/console assets:install web --symlink

The result is that we end up debugging screens that lack the css stylesheets preocupation of symfony devs. Our eyes will not relax seeing numbers and letters in black and white without any apparent order sometimes.

The log information is output with a format thought to be presented styled with the assets. This will save you frustration and can save you a lot of time.

Therefore before you continue in every development setup your primary assets.

Patch git diff applied with git apply patch

Last night I was working collaboratively with a partner and there was a git diff file that was sent to me. The diff was sent without sign-off information, no email address, no name, no special formatting, no nothing.

So what I did was to issue:

git apply patch1

And the job was done. Notice that this command just applies the changes but it does not commit them which is ideal. There was another post that I show how to deal with PRs that was previously posted. This here is a more temporary solution, and whenever one just wants to try something in a volatile fashion.

Fix your broken Symfony2 with PRs available

Today I did bin/vendors update and got all messed up with AsseticBundle first.
I was told I needed to update my repos with some PRs that fixed the problem.

I had already blogged about handling PRs from other people into ones repo. However never had this scenario before.

So what I did was:

1
2
3
4
cd vendor/bundles/Symfony/Bundle/AsseticBundle
git remote add fix https://github.com/jstout24/AsseticBundle.git
git fetch fix
git cherry-pick 40bdc973dfaa5aabf51f

What I have done is:
1. went into the problematic repo directory
2. added a remote address of the repo where the PR originated
3. fetch the changes including the commit that has the fix
4. select in particular that commit and apply it to fix my local repo

I am going to fix other parts with other PRs, now wondering what do I do to tell bin/vendors update not to touch these changes.

If you are like me with SE (symfony-standard editon) do this after applying the two or more patches available:

cp deps deps.old
pico deps
//comment the lines of problematic repos
bin/vendors update
// this time clean update

After this operation when the PRs are merged to main repo, it is enough if you just change back the deps file and do bin/vendors update.

In addition to this another way of fixing problems is going backwards. Since with SE symfony-standard edition you have been using git versioning, then you just need to look for earlier commits with valid deps and then the only command needed after reverting back to a valid state would be to issue bin/vendors install.

Please consider donating. Thanks!

Working with File Uploads in Symfony2

I have worked on an UploaderBundle app. Here i will show you how to install and explain the code how to make file uploads to work for you.

Update: If you are not using entities then you should use the method:

$data = $form->getData(); $data['attachment']->move() // see below

Installation instructions are at the bottom.

The documentation seems to be a little unclear as to how exactly define the form. Here is the documentation. Therefore we start with adding to the buildForm the attachment element that is fileType.

public function buildForm(FormBuilder $builder, array $options)
    {
        $builder->add('filename', 'text', array( 'label' => 'File Name :'));
        $builder->add('attachment', 'file');
    }

We also define a method getAttachment on the object that is bound to the form.

public function getAttachment()
{
    return $this->attachment;
}

This has the purpose to retrieve the UploadedFile which is spoken of in the file reference above.

Finally my controller looks like this:

public function indexAction()
    {
	$form = $this->get('cordova_uploader.form_factory.signeddocument')->createForm();
 
        $request = $this->get('request');
 
        if ($request->getMethod() == 'POST') {
 
            $form->bindRequest($request);
 
            $dir = '../media/reception/';
 
            if($form->isValid()) {
 
                $signeddocument = $form->getData();
 
                $uploadedfile = $signeddocument->getAttachment();               
                $uploadedfile->move($dir, 'signeddoc.doc');
 
                $em = $this->get('doctrine')->getEntityManager();
                $em->persist($signeddocument);
                $em->flush();
 
                //reset the form
                $form->setData(new SignedDocument());
            }
        }
 
        return $this->render(
            'CordovaUploaderBundle:Default:index.html.twig',
            array(
                'form' => $form->createView()
            )
        );
    }

As you can see we get the object UploadedFile and then we check the docs here for the methods we can call into this object and move the file to our folder.

I have not included every detail of implementation but have tried to complement the information already available in the docs. For more information you have here the working code of my example here. Please donate as i am working on this hope and please email me if you donate so I can know from who is it coming and thank you personally. Thank you so much.

Instructions:

git submodule add git://github.com/cordoval/UploaderExample.git src/Cordova/UploaderBundle

Add it to AppKernle.php and autoload as follows:

new Cordova\UploaderBundle\CordovaUploaderBundle(),
// and
'Cordova'         => __DIR__.'/../src',

Don’t forget to import the form.xml into your config.yml see code.
And of course include proper routing.

Enjoy!

Do Unit Tests should call real DIC or Fixtures?

Recently I wrote a reply to this post in which interesting classes for *unit* tests were presented. However I made some annotations as to the effect that I always learned from the top guys about testing:

hi there, I like the part that you talked about the Continuous Integration server application. However, i don’t think your tests are unit tests. The reason is that your tests should tend to be isolated into the logic of the test and not in loading interactions with other objects or the database. So to load specific data makes it sound more like functional testing. Specially when you load the DIC, rather I think objects and their methods should be mocked and stubbed. This of course is harder but it is the right way. What do you think?

Idea: Now if i am right it would be neat to create a class that can automatically perhaps implement the mocking or stubbing through the DIC.

http://blog.sznapka.pl/fully-isolated-tests-in-symfony2/comment-page-1/#comment-287