Botched Code

As a web developer, you have to deal with web forms. Why would you make a new form, and an edit form, which is basically the same.

How to handle this would be to use this design pattern:

1.) load the get item to load, if it exists. Lets call it $dataObject
2.) if $dataObject is empty/does not exist, start a new dataObject. Lets call it $dataObject
3.) dataObject is now instantiated.
4.) Do what needs to be done — for example “title” of the page, being “editing XXX”, or “new dataObject”. Whatever frontend reflections need to happen, based on if it’s new object or editing an old object.
5.) populate the form, accordingly. If the object is blank, it’ll just be populated with the default values.

6.) onSubmit()… check to see if an ID value was submitted, and the appropriate security checks, and deal accordingly. If there was no ID value, start a new dataObject, to be populated with the data submitted.

7.) $dataObject->save();

The above described is how symfony admin generator handles form reuse. While the admin generator is useful for most cases, sometimes you need to just do “more” customizations, than using the generator.

For example, you need to handle a collection of both NEW and Prior saved objects… to do batch edits, it’s easier to do it manually, instead of using the symfony-admin-generator.

How to make a restful interface easily with symfony:

# “project_root”/app/”app_name”/config/routing.yml

# default rules
homepage:
  url:   /
  param: { module: test, action: index }

test_get:
  url: /v2/tester
  class: sfRequestRoute
  param: { module: test, action: get }
  requirements:
    sf_method: [get]

test_put:
  url: /v2/tester
  class: sfRequestRoute
  param: { module: test, action: put }
  requirements:
    sf_method: [put]

test_post:
  url: /v2/tester
  class: sfRequestRoute
  param: { module: test, action: post }
  requirements:
    sf_method: [post]

test_head:
  url: /v2/tester
  class: sfRequestRoute
  param: { module: test, action: head }
  requirements:
    sf_method: [head]

# generic rules
# please, remove them by adding more specific rules
default_index:
  url:   /:module
  param: { action: index }

default:
  url:   /:module/:action/*

Remember, order DOES matter… if you have the default one at the top, the more specific matches to be overlooked. So move more specific items to the top, and your routing will be fine.

Summary:
post to http://localhost/sf_project/frontend_dev.php/test, will call frontend->test->post

delete to http://localhost/sf_project/frontend_dev.php/test, will call frontend->test->delete

put to http://localhost/sf_project/frontend_dev.php/test, will call frontend->test->put

head to http://localhost/sf_project/frontend_dev.php/test, will call frontend->test->head

you get the point…

Doctrine Soft Delete is a fabulous method that will set a deleted_at column when the user deletes a record. So it doesn’t really delete the record but timestamps it as deleted.

This offers wonderful functionality to you admin generated app. But there’s a catch!

If you’re using a batch delete you’ll notice that the code uses DQL (Doctrine Query Language) to make the delete and not actually calling the delete() method from the class.

I fixed this quickly by actually time stamping deleted_at field:

$count = Doctrine_Query::create()
      ->update('myclass')
      ->set('deleted_at','now()')
      ->whereIn('id', $ids)
      ->execute();

Symfony should account for this so that soft delete will work properly with admin generated code.