Getting sfFillInFormFilter to output valid xhtml

August 16, 2007

Huh? a bug!The sfFillInFilter is really useful for form repopulation and often saves a great deal of time, but if you’ve worked with it you may also have noticed that, after a form repopulation, all of your xhtml-compliant code is transformed to regular html and thus breaks validation.
I noticed this on a project of mine where some parts of the site would render slightly different after a form repopulation, which caused me to investigate this topic a little bit.

Initially reported for symfony 0.6
, it resulted in the addition of the „content_type“ parameter for the 1.0 release. If the parameter passes „xml“, DomDocument in sfFillInFormFilter will load and save XML rather than regular HTML. This seemed to work at first but with some time passed, another serious issue showed up with „xml“ as „content_type“ set. The form repopulation won’t work because the specified form cannot be found by the sfFillInFormFilter. This issue existed for quite some time.

In April 2007, ReeD started a forum thread about this issue and quickly found out that the DOMXPath cannot select elements of an XML document with default namespace defined.
With some help from vanchuck a patch was created and attached to trac, but as of today wasn’t included in trunk.

Testing

To show you how symfony behaves with and without the patch applied, i performed a small test with a fresh symfony 1.0.6 installation, a simple form with a few input fields and a small YAML validation file which just enables the sfFillInFormFilter and passes the form name to it:

fillin:
  enabled: true
  param:
    name: register

With the form put on a valid xhtml page, repopulated and redisplayed again, all of the self-closing tags like <input … /> are now converted to it’s non-selfclosing counterpart.
By adding the „content_type“ parameter and setting it to „xml“:

fillin:
  enabled: true
  param:
    name: register
    content_type: xml

the output is valid xhtml, but symfony now throws an „No form found in this page“ error and the form fields are not repopulated.

With the patch (which is mentioned above) applied to sfFillInForm.class.php and the same validation files as before, it will still needs the „content_type“ parameter set to „xml“. Without the paramter it still won’t find the form and repopulate it. But if the parameter is passed, sfFillInFormFilter will find your form and finally output valid xhtml!

Summary

To summarize it a little bit, here are three possible solutions that i came up with to get valid xhtml in symfony 1.0:

  1. Not using xhtml for your page.
  2. Not using sfFillInFormFilter.
  3. Applying the patch and always setting the „content_type“ parameter to „xml“ in your validation files.

Since most of the build-in symfony helpers are using xhtml, it can be quite hard to migrate your code to regular html. You’ll either have not to use or rewrite them, which can take quite a time.
Not using the sfFillInFormFilter seems nice at first, but can be very time-consuming if you have forms with many fields to repopulate.
By using the patch you’ll always have to remember to set the „content_type“ parameter to „xml“ in your validation files.

Or maybe just wait for symfony 1.1 with its new and shiny form layer? You decide it! but for now i just hope that i could clear up this topic a little bit.
Please take some time and state your opinion in the comments, thanks!

Advertisements

5 Responses to “Getting sfFillInFormFilter to output valid xhtml”


  1. […] Getting sfFillInFormFilter to output valid xhtml […]

  2. Diego Drigani Says:

    Hi, i have the same problem in discuss. But, no find the patch mentioned. Please do u tell me where i find it?

    Thanks.

  3. symfoniac Says:

    This should be fixed within one of the recent versions of symfony, but i’ve heard that there’re now problems with ajax-validation


  4. Confirmed, when using sfFillInFormFilter with AJAX failed form validation the error still occurs.

  5. Fabian Lange Says:

    Hi *,
    just applied a fix so that the fillin will work on Ajax Responses when content_type is set to xml correctly.
    You will have that fix from 1.0.14 on


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: