Symfony 1.1 documentation
starting point
# Checkout the current symfony book $ svn co doc/branches/1.1/book
What to update ?
Here is a list of subjects that have changed, and the related chapters to update. If you want to start updating a particular point, put your name aside a subject so that we don't make conflicts.
Flash attributes(chapters 6 and 19)Refactored storage system(chapters 6, 17 and 19)Actions can now end by renderPartial() or renderComponent()(chapter 7)sfWebRequest now has an isMethod() method (if($request->isMethod('post')))(chapters 6, 9, and 10)Support for many-to-many relationships in fixtures(chapter 16)Escaping strategies are now only 'on' and 'off'. Watch out in the 'performance' Chapter, where we advise to deactivate it - it no longer has an impact on performance(Chapters 7, 18, 19)make php symfony the default way to call the CLI everywhere in the doc- propel-init-crud does not exist anymore, use propel:generate-crud --generate-in-cache instead (Chapter 14)
- Scaffoldings now use the new form syntax
syntax of batch files(Removed from chapter 6, detailed in chapter 16)Use of a third-party framework no longer needs a bridge, just register additional autoloading callableAbility to execute an action on a selection of entries in the admin generator(chapter 14)- Config changes
Remove mentions of Spyc- Incorrect YAML files now throw a helpful error message
- Symfony can auto-check that it can run (check_configuration.php checks PHP version, extensions, etc.)
- The project and application configurations are now classes, offering convenient methods to customize the project directory structure and loaders
- An application can access another application's configuration
Factories(chapter 6 and 17)- Removal of singletons
- removal of 'logging.yml' (chapters 6, 16, and 19)
- new cache framework (chapters 7, 12, 13, 15, 17, and 18)
new unified interface for all cache classesmore classes. In 1.0: File and SQLite. 1.1: File, SQLite, APC, eaccelerator, xcache, memcache(chapter 19)big changes in function cache. It now takes a cache instance(chapter 18)i18n cache is now also configurable in factories.yml(chapter 13, 19)- Ability to remove the cache from another application (Waiting for the ability to switch app conf)
The view cache manager now accepts wildcards in the remove() calls, whatever the caching factory you usePartials and components in cache can now add JavaScripts? and stylesheets in the main response(no need to document it, it was a sf 1.0 bug)- New general caching factory, for your non view-related caching needs (Not implemented)
- autoloading
- No more need to clear the cache when addind a new class (only when ProjectConfiguration? debug=true)
- routing
Routing cache layer(chapters 9 and 19)Token separator in routes is no more limited to '/'(chapters 9 and 19)- PJS and multiformat
- The routing class is not a singleton anymore - that means that an application can have access to another application's routing objects
How to register a new routing rule in a plugin(Chapter 17)
- i18n
- I18n now uses the same caching techniques as the view, for faster-than-ever template generation
- A new task can find untranslated text strings in templates and add them to the dictionaries (symfony i18n:extract)
- Another new task can find text strings without () in templates and report them (symfony i18n:find)
- XLIFF and gettext dictionaries can now be in multiple directories
- The I18n class is not a singleton anymore
- logger
- filter chain (recheck what is described in chapter 6)
Explain where the compat10 plugin is needed(Chapters 6, 10, 14)- Validation changes ? (chapter 6)
- Create a chapter 10bis for the New Form Framework
- Forms are now classes
- Form Widgets represent the view layer. The subframework provides more widgets than symfony 1.0 had form helpers.
- Native and easy handling of validation, fillin, request binding
- Native CSRF protection
- Native file upload validation
- Support for nested validations and widgets
- ORM changes
- Propel has been updated, and is now a plugin, bundled by default with symfony 1.1. Update paths
Behaviors can now be declared directly in the schema(chapter 8)A schema can be overridden by another one(chapter 17)- New configure:database task to update both the propel.ini and databases.yml dsn from the command line
- More hooks in the code - that means more opportunities for extensions and behaviors
- Better i18n support ($article->getTitle('fr'))
- Improved dump/load, dealing with FK seamlessly
- YAML schema generated from a database is now more readable
- Support for the new Form subframework
- Propel Inheritance is now supported (see #3473)
- ->initialize methods
- Improved tests
- A performance tool allows to measure the speed difference between each version of symfony - objectively
- CSS3 selectors are now supported in the sfDomCSSSelector (:contains(), :first, etc.)
- web debug
- More information in the Web Debug Toolbar (PHP extensions, sfUser attributes, etc.)
New CLI task systemRemove mentions of PakeCheck all calls to CLI and replace with the new syntaxIntroduce the CLI syntax (help, unordered named options)(Chapter 16)Explain how to embed tasks in a plugin(Chapter 17)
- New plugin system (Chapter 17)
- New CLI syntax
- Supports dependencies between plugins
- New options for more control over what you install (--install_deps, --release, --stability)
- Support for the REST API of a PEAR channel (?)
Replace the explanation of Mixins by an explanation of the new event system(Chapter 17)List events
- No more constants.php (chapter 19) and new method to customize directory layout
Try to explain behaviors without Mixins- Total decoupling of objects
- Better exceptions
Alternative schema capabilities (behaviors in the schema, overriding an existing schema, alternative syntax)(chapters 8 and 17)- improved error500 and unavailable page things need documenting - r8271 and r8272
batches: in sf 1.1, the best way to create a batch is to create a task class. That way, you have option and parameter support for free and the task is launcheable via the symfony CLI
You will find a detailed list of changes in the code at branches/1.1/UPGRADE
Fabian's review comments
Chapter 1
PHP 5 -> PHP 5.1(it confuses slightly to read about php 5, when the requirement is 5.1. although i know the name of the thing is php 5)- ORM Part:
Propel should be described as default plugin. Doctrine as addon-plugin note from Francois I think Chapter 1 is a little early to talk about that. You need to know about ORMs, plugins, and a lot more to be able to make something out if this piece of information. fabian: fine with me, just noticed that it indicates a strong propel binding, which is no longer intended to be
Chapter 2
Module tree structure subchapter: remove "valdidate/" folder from code, table and note
Chapter 3
PHP 5.0 requirement -> php 5.1Sandbox file needs to be versioned as well. also download link needs then adjustments: http://www.symfony-project.org/get/sf_sandbox.tgzalso the sandbox version number is then probably not 1.0.0: "symfony version 1.0.0"- is the list of included third party components still correct?
"Installing the Symfony PEAR Package" chapter needs later more up to date numbers (version filesize etc)- Also in the checking out the path needs to be adjusted (depending on time of change change also .com to .org)
- Setting up-application needs to be checked for new symfony CLI commands
- Typical problems lists that the memory limit should be 16M. But I think somewhere else (and also in my envs) 32M is recommended
Chapter 4
Module Skeleton Chapter: Remove validate directory reference- Markdown issue in listing 4.7, 4.8, 4.9, 4.11, probably caused by the single quote
Chapter 5
- Project Configuration -> is the propel configuration still there?
- Module Configuration remove or rewrite the valdiation part here (i guess remove, as validation is not configured, its programmed)
Chapter 6
- Listing 6.8: Update how to obtain "framework core objects"
Singleton Explanation Note: Rewrite or drop?- Listing 6.31,6.34 remove web_debug: ~ (no longer a filter)
- "The Filter Chain" refers to the web debug filter sometimes, bad example as this is no longer a filter :-)
Chapter 7 -> no motivation yet to do. too many changes :-)
Chapter 8
- generally contains much that will collide with the propel 1.3 change. any precautions we want to take now (or ignore it atm)
- Right in start: rephrase how propel is integrated into symfony to indcate this more loose coupling
- are/will the CLI commands the same? or are they different for propel being a plugin now
- how is the sfPropelPager currently shipped. Part of sf? own plugin, part of the sfPropelPlugin?
- perhaps the "Propel in symfony" could be moved up to explain the integration