Skip to content

jonocode – a developer's blog

I moved! –> http://pressreload.com

Category Archives: Doctrine

Symfony has automated the process of creating a CRUD application, and even has built-in CSRF protection.

However, for a site with multiple users, the generated CRUD code just won’t do.

In my schema, each row of a model is owned by a user, according to their user_id. In the dashboard application I am building, each user has a list of programs.

They can create, read, update and delete each program that they own.

But the generated actions would allow users access to other user’s programs, simply by changing the id in URLs such as /program/edit/id/1.

My solution? Store the user_id of the currently logged in user in myUser.class.php. Since the myUser class has ownership of the id of the currently logged in user, I thought it was appropriate to implement convenience getters and setters for the dashboard here.

So my list action would contain:

$this->programs = $this->getUser()->getPrograms();

The myUser::getPrograms() method is implemented like so:

public function getPrograms()
{
  return Doctrine::getTable('Program')->fetchByOwner($this->getId());
}

public function getProgram($pk)
{
  $program = Doctrine::getTable('Program')->find($pk);
  return $this->hasOwnershipOf($program) ? $program : false;
}

public function hasOwnershipOf($row)
{
  if ( isset($row['user_id']) )
  {
    if ( $row['user_id'] == $this->getId() )
    {
      return true;
    }
  }
  return false;
}

Adding the myUser::fetchByOwner() method leaves the model functionality open to being called from another administrative application other than the dashboard. You could use a Doctrine magic method here, however I would prefer to return programs in alphabetical order (or perhaps allow for other options to be passed in using a Doctrine_Query as a second parameter).

For myUser::getProgram($pk), I simply use the ::find() magic method in doctrine to retrieve the object by primary key, as usual, and then return it only if it matches the user_id of the logged-in user.

Writing for multiple users is common place for web-based applications. However, it’s something I don’t usually deal with at work where I write simple, single-user back ends for editing website content.

Is there a more elegant way of handling user ownership of database content? Perhaps by writing a doctrine behavior? How do you usually go about it?

Please comment.

I’m sure there are a number of ways you can handle this. There are also tons of modifications you can do to make it more useful, or better adapted to your particular needs. This post will quickly illustrate one way to create a dynamic stylesheet in Symfony 1.2.

I just finished writing a module that allows my users to change their background color. So I thought I’d share a similar way of doing this with an example.

Create a new doctrine model. Since we’re keeping things simple, our style sheet will only have one editable element: the body tag’s background-image.

DynamicCSS:
  columns:
    identifier: string(255)
    background_color: string(255)

Add a fixture and load it up:

/data/fixtures/fixtures.yml

DynamicCSS:
  black:
    identifier: "main"
    background_color: "#000000"
$ symfony doctrine:build-all-reload

The identifier will be the stylesheet’s name. You’ll see it in the route, which you’ll add now:

/apps/frontend/config/routing.yml

dynamiccss:
  url: /dynamiccss/:identifier.css
  param: { module: dynamiccss, action: render }

Create a new module:

$ symfony init-module frontend dynamiccss

This module will be used to render a dynamic style sheet. You’ll want to make sure it doesn’t render the layout, and that it returns a content type of ‘text/css’. So edit the actions file and add a preExecute() method. Of course, you’ll also need a method to fetch the style sheet and render it.

/apps/frontend/modules/dynamiccss/actions/actions.class.php

  
...
  public function preExecute()
  {
    $this->setLayout(false);
    $this->getResponse()->setContentType('text/css');
  }

  public function executeRender()
  {
    $this->stylesheet = Doctrine::getTable('DynamicCSS')
      ->getByIdentifier($request->getParameter('identifier'));
    $this->forward404Unless($this->stylesheet);
  }
...

Next we’ll add the template, which is at this point is very simplistic. You’ll need to have that ::getByIdentifier() method implemented in the DynamicCSSTable class, as well.

/apps/frontend/modules/dynamiccss/templates/renderSuccess.php

body {
  background-color: <?php echo $stylesheet->getBackgroundColor() ?>;
}

/lib/model/doctrine/DynamicCSSTable.class.php

...
public static function getByIdentifier($identifier)
{
  return $this->createQuery('c')
    ->addWhere('c.identifier = ?', $identifier)->fetchOne();
}
...

Now you can add your dynamic style sheet to the view. Here is an example:

/apps/frontend/config/view.yml

default:
  ...
  stylesheets: [/dynamiccss/main.css: { raw_name: true }]
  ...

That “raw_name” option allows you to override the typical way of creating an asset’s file name.

Now whenever someone edits the background color for the “main” style sheet, from the database, the background color can change.

You’ll still need to add an interface for editing the background color (or however many other options you add). That is up to you.

Complaints? Pointers? Thought of a better way?

Please post.

Tags: ,

Here is something to watch out for. If you define global behaviors in your schema, and then define table-level behaviors, the global behavior will be removed (unless you declare it again on the table level).

Here is a quick example:

actAs: [Timestampable]

Program:
  actAs:
    Sluggable:
      fields: [name]
  columns:
    name: string(255)
    user_id: integer(4)
  relations:
    sfGuardUser:
      foreignType: many
      type: one
      local: user_id
      foreign: id

For a short while I couldn’t figure out why the created_at and updated_at fields weren’t showing up in the Program table. Then I realized that it was removed at the table level, and I had to add it in again.

The official documentation does not mention this:

http://www.symfony-project.org/doctrine/1_2/en/04-Schema-Files#chapter_04_global_schema_information

Hopefully this will save you 15 minutes of scratching your head.

Here is more information on Symfony 1.2 and doctrine:

http://www.symfony-project.org/doctrine/1_2/en/04-Schema-Files