A week of symfony #135 (27 July -> 2 August 2009)

August 2, 2009 · Published by Avatar of Javier Eguiluz Javier Eguiluz

Symfony deprecated this week several helpers, settings and classes in the 1.3 branch. All these features will be removed in symfony 1.4 and are explained in the new deprecation guide

Development mailing list

Development highlights

  • r20545: [1.2, 1.3] fixed linked data when using multiple dirs in propel:data-load task
  • r20546: [1.3] reverting preExecute() and postExecute() methods miss sfWebRequest argument
  • r20548: [1.3] renamed "Cancel" to "Back to list" in the CRUD and admin generators
  • r20550: [1.2, 1.3] fixed mkdir() usage in sfValidatorFile
  • r20564: [1.3] rewrote sfTesterResponse::checkForm() so it works with widgets that render multiple form elements
  • r20566: [1.3] deprecated sfNoRouting and sfPathInfoRouting classes
  • r20567, r20568, r20569, r20570, r20571, r20572, r20574, r20594: [1.3] moved deprecation information to a new file
  • r20573: [lime 2.0] added missing info() method to LimeOutput classes
  • r20595: [1.3] made the plugins always loaded in the same order when using enableAllPluginsExcept() method
  • r20690: [lime 2.0] annotation support can be enabled in included files
  • r20692: [1.3] updated symfony CSRF token generation and checks to use BaseForm
  • r20693: [lime 2.0] implemented new method lime_debug()
  • r20694: [lime 2.0] implemented new method lime_debug()
  • r20695: [lime 2.0] added type hint to assert* methods
  • r20698, r20699: [lime 2.0] implemented contains() and containsNot()
  • r20705: [lime 2.0] implemented assertSame() and assertNotSame() for LimeTesterArray
  • sfDoctrinePlugin:
    • r20681: [1.2, 1.3] fixed widget class selection to work with latest doctrine development which added the possibility of a string column with a length of null
    • r20706: [1.3] added a --migrate option to sfDoctrinePlugin tasks
  • ...and many other changes

Development digest: 199 changesets, 28 bugs reported, 18 bugs fixed, 7 enhancements suggested, 6 enhancements closed, 12 documentation defects reported, 13 documentation defects fixed, and 46 documentation edits.

Documentation

New developers for hire

  • Arsic Dragan (arsicd [at] gmail [dot] com): is a 25 year old web developer with 5+ years of experience with PHP, 2 years developing web applications with symfony. Currently employed in Serbia.
  • 3mlabs: we are a professional team that develops web products with Symfony.

New symfony bloggers

Plugins

  • New plugins
    • tmCsvPlugin: a plugin for reading from the CSV file format.
    • sfHtmlLawedPeytzPlugin: an alternative to HTMLPurifier and Tidy for HTML Validation and escaping.
    • sfDependencyInjectionContainerPlugin: fully integrates the dependency injection container into Symfony.
    • sgLESSPlugin: implements LESS CSS (http://lesscss.org/) functionality and features: it allows to define variables, mixins (for any type: class, id, tag), nested rules, arithmetic (color on color, color on number, number on number), scope, comments, importing and more things to come.
  • Updated plugins
    • sfTabMenuPeytzPlugin: added a priority setting if there is multiple matches with the same score
    • pkMediaPlugin: requirments patch that allows periods in media tags, no longer displays a warning if there are no results in the selected items, first round of PDF support
    • pkToolitPlugin: validation error with charset, use data() to determine whether we've already upgraded a select element to a pillbutton
    • pkContextCMSPlugin: support for engines, improved readability, fixed 256 bug which broke glowing in IE, rooted but non-FQDN URLs with a front end controller need their own special case, refactored pkContextCMSRoute (moved most of the code to pkContextCMSRouteTools and added experimental implementation of pkContextCMSDoctrineRoute class), support for generating engine route links from a non-engine page
    • sfViewableFormPlugin: fixed mapping of global form errors to array
    • psToolboxPlugin: improved default values management
    • sfPhpunitPlugin: coding standard assignments, added task for generating stub classes for functional tests, added possibility to run a functional test with PHPUnit and not with lime directly, cleanup and other improvements, changed relative path for shell scripts and a syntax error, restructured test stub templates, added possibility to define custom templates, removed unused group field of unit test case template, added test for target option, fixed relative path for require_once call in unit test template, updated documentation, switched to require_once calls in templates
    • sfUnobstrusiveWidgetPlugin: added option draggable_item on Many Ajax Search, added new CSS properties for fully clickable button when sorting is disabled, using text instead of innerHTML for searching, added CSS in uo_widget_form_select_many in "multiselect" transformer, changed tolerance for draggable items, fixed related_choice JS behavior, added method_attributes to sfUoWidgetFormDoctrineSelect widget, added "animate" config in drop line menu JS behavior to enable or not animation, fixed multiselect JS behavior CSS
    • sfExtjsThemePlugin: lots of fixes with ComboBoxAutoLoad as a grid editor, changed sf_format router to append instead of prepend so it would come after most other routes, fixed date column problems, fixed a problem with foreign column list editors
    • sfDatagridPlugin: first doctrine release
    • sfAdminDashPlugin: updated _login.php to check if CSRF token is actually enabled
    • sfDoctrineGuardExtraPlugin: fix form validation move doctrine validators to post validators
    • swToolboxPlugin: added getSortBy and getOrderBy, improve swMail classes
    • wspPingdomPlugin:
      • added report status and report via enum classes
      • added class for cause enum
      • fixed Fatal error: SOAP-ERROR: Encoding: object hasn't 'pageNumber' property
      • added PingdomApiReportGetNotificationsRequest, PingdomApiReportGetNotificationsResponse, PingdomApiReportGetNotificationsResponseItem classes
      • added getNotificationsReport method to PingdomApiClient
      • added PingdomApiReportGetOutagesRequest, PingdomApiReportGetOutagesResponse and PingdomApiReportOutageEntry classes
      • added getOutagesReport method to PingdomApiClient
      • added PingdomApiReportGetRawDataRequest, PingdomApiReportGetRawDataResponse and PingdomApiReportRawDataEntry
      • added getRawDataReport method to PingdomApiClient
      • added PingdomApiReportGetResponseTimesRequest, PingdomApiReportGetResponseTimesResponse, PingdomApiReportResponseTimeEntry and PingdomApiReportCheckStateEntry
      • added getResponseTimesReport method to PingdomApiClient
      • PingdomApiReportGetCurrentStatesResponse now uses correct object
      • setter for class members now return their instance
      • added dynamicly planned tests to wspPingdomTest
      • added resources folder
      • moved PingdomApi into resources
      • moved PingdomApiClient and PingdomApiExceptions into library
      • lib/pingdom is now useable without symfony
      • added several documentation links to Pingdom API and completed PHP-Doc
    • pkImageConverterPlugin: support PDF as an input format via gs

New symfony powered websites

  • PrepMe Test Prep: (English) personalized online test preparation for college admissions tests (SAT
  • Roxolar: (English) solar energy estimator for residential and commercial use; marketplace for buyers, installers and lenders to connect
  • FourFour: (English) an online platform that enables independent bands and musicians to easily create and manage their official artist website in minutes
  • TwitOrNot: (English) Hot-or-Not application dedicated to Twitter tweets
  • Ladies First: (Italian) Ladies First no-profit team's events and earty subscription site
  • Talk WeBank: (Italian) italian community for WeBank bank
  • TripShake: (English, and Italian) a Q&A website that connects travellers with locals and destination experts
  • The Source CookBook: (English) a CookBook to keep and show your source code snippets

They talked about us

Published in #A week of symfony

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Avatar of andreas
andreas said on Aug 3, 2009
Hi,

just out of interest - this is the first time I read about a 1.4 version, is there more info about what's planned for this? The only info I could find was this post and the milestone in trac.

Asking because I think I recall 1.3 was supposed to be the last of the 1.x releases.

Cheers,
Andreas
Avatar of Matt
Matt said on Aug 3, 2009
1.4?? Can you please look at making another long-term-supported version? I was expecting 2.0 sometime this year!

1 year support just isn't enough. It's fine for the first 6 months, maybe, but after that we'll start projects for our clients that will go live with an unsupported version of Symfony, and upgrading them will cost us money. Please can you tell us if 1.3 or 1.4 will have a long support life?
Avatar of beleneglorion
beleneglorion said on Aug 3, 2009
i have read somewhere that the 1.4 version is the 1.3 version where all the deprecated features have been removed
Avatar of halfer
halfer said on Aug 4, 2009
I am interested in the deprecation of form helpers. To be honest, I am wondering whether some of our existing applications should ever be upgraded to the Symfony Forms system. This is partly because I haven't yet understood the Forms system, and that in turn is because I can hardly spend the time to look at it! But the main reason is that some of our systems chunter happily away with no maintenance requirements or fixes required from one year to the next. Accordingly I would be placing a large unexpected burden on the business by registering a substantial upgrade requirement on things that should (and could) just be left alone.

For those of us who are happy to keep some applications doing forms "the manual way", is it the idea to make it increasingly difficult to do this, or will it just be a case of loading (and tweaking) the legacy plugin?
Avatar of Fabien
Fabien said on Aug 4, 2009
@Halfer: Deprecation messages are a great way to tell people what is the old way of doing things and what is the new way. When starting a new project, you won't need the 1.0 compat plugin anyway. So, the goal is to release symfony 1.4 just after 1.3. It will be exactly the same release as symfony 1.3 minus all deprecated code. That way, people starting a new project won't carry over the overhead of the old legacy code. The next version after 1.4 will be 2.0. Also, symfony 1.4 will be the next LTS release.
Avatar of halfer
halfer said on Aug 7, 2009
I agree that deprecation messages are useful. But my chief concern is that our business may not want to dedicate time converting from the old forms system (1.0) to the new one (1.2+). Accordingly for some projects, we will be stuck on 1.2. Since we have one website with many modules, we will either have to mix 1.2 with 1.4 using mod_rewrite tricks, or keep everything on 1.2 even after it has gone out of support.

If there are solid ways to mitigate against this - aside from the obvious of upgrading all the forms systems! - do please let me know.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.