You must first sign up to be able to contribute.

Admin Generator 1.2 Sprint Notes


  • Admin gen should be more decoupled than the current admin gen: there will be more small classes, so we'll be able to extend this small features easily
  • We must be able to use the admin gen with only PHP code
  • A decoupled admin generator would also mean more flexibility in extending different parts of it
  • We need a main object for each object, something like ArticleAdmin?, CommentAdmin?, etc.
  • We can have a .yml configuration file, but this is optional, as long as it remains possible to do fast and flexible generation
  • Majority of the features must be independant from the controllers and templates
  • We need to be able to output HTML, XML, JSON, JS, or whatever for the list, the form, and the filters. That way, we will be able to provide an HTML, Flex, ExtJs? interface with the same architecture and share code
  • Generated controllers will handle the lesser logic; most of the time, people will customize/implement their logic in the admin class, or form class, or filter class, or list widget
  • 2 main objects will be generated and manipulated by the admin generator:
    • a list widget (sfDataGrid?)
      • The list widget can have an associated Filter form which will provide filtering parameters
    • a edit/create form
  • sfAdminManager will have references to n sfAdmin instances and their respectives routing, to be able to handle related objects administration contextualy and easily in forms
    • Then sfAfminManager will be able to provide a full stack backoffice app, capable of providing a backend for the whole model classes :)
  • AdminGen? won't bundle any js lib/framework
    • but will provide DOM ids and class names to ease ajaxification by external plugins
  • Old admin gen and the new one will coexists, the old one will use the sfCompat10Plugin

Must have for 1.2

  • Have the same level of features than the symfony 1.0 and 1.1 admin generator
  • New admin gen must work with Propel and Doctrine by default
  • It must works out of the box without the need of the activation of the sfCompat10Plugin
  • Using the new sfForm system
  • The decoupled architecture mentionned above
  • Handle credentials and access levels at a widget or column level in forms, lists and views
    • Also handle access types : editable, readable and not-visible
  • The ability to extend a theme easily for reusability
  • Use slots (placeholders) in provided templates instead of PHP include calls
  • Add a way to override the query made to populate select filters, without the need to implement a partial filter -> with the upcoming filter form it will be possible natively
  • The new admin gen must be elegant, and a particular effort must be done on usability and ergonomy
    • renamed the term "theme" by "skin"
    • provide at least two skins by default: one very simple but easily extendable and a more graphically elaborated one
  • We must provide default output-format-agnostic actions for Model Objects operations: this will ease Ajax-enabled plugins to extends admin generator UI easily
  • Remove the wildcard behavior of symfony 1.1 admin gen in filter forms
  • If a "delete" button is removed from the UI, we must disable the "delete" action as well
  • Entirely handles i18n
  • Better support for file upload
  • Ability to define different title for new and edit forms

Nice to have for 1.2

  • Capacity to create or edit existing related objects in an edit form. Visual examples are attached to this page.
  • Be able to sort and filter on foreign objects based on some columns (1:n relationship only)
  • Be able to sort and filter on foreign objects based on some columns (n:m relationship) (harder)
  • Be able to sort and filter on a calculated field value
  • Be able to sort and filter on multiple columns (implementation for 1.0 already exists, by lvanderree)
  • Add a show/view action by default
  • Have a next/prev buttons in the edit/show view
  • We might be able to generate a navigation menu (and maybe a breadcrumb) using sfAdminManager and its sfAdmin instances
  • Filters (and maybe also regular edit-pages) could benefit from combo-chaining from the generator to narrow down possibilities
    • eg. select a city by first selecting a country would reduces the number of cities

Won't have

  • Compatibility with the old admin gen system)
    • We'll try to do our best to keep the generator.yml syntax
  • New admin gen won't provide embeded javascript by default, except for pure javascript controls (if(confirm('Sure?')))
  • native support for UI Ajax framework
  • native intergation of non compatible licensed project
  • Ajaxified interface and behaviors must be provided by an external plugin


  • bschussek: Will help
  • lvanderree: Will help on foreign-keys handling
  • francoisz:
    • Will help on documentation
    • Will help defining the YAML format used for the generator.yml
  • synace, shawncplus, isleshocky77: Will help