Development

#1687 ([PATCH] fillInFormFilter can't find form with content_type = xml)

You must first sign up to be able to contribute.

Ticket #1687 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

[PATCH] fillInFormFilter can't find form with content_type = xml

Reported by: vanchuck Assigned to: FabianLange
Priority: major Milestone: 1.0.14
Component: other Version:
Keywords: Cc:
Qualification: Accepted

Description

Because of namespace issues with DOMXPath, if you are using fillInFormFilter with content_type = xml (which people have been trying to do, in order to output xhtml-compliant code), the filter will fail, reporting "No form found in this page".

The xml option was added as a result of ticket #512.

ReeD figured out the source of the problem and proposed a solution in this thread: http://www.symfony-project.com/forum/index.php/t/6044/

The solution is to explicitly load a new namespace and use that in all queries, since it is the default namespace which is causing the DOMXPath queries to fail. Examples and comments on the PHP DOMXPath documentation page also seem to show this to be the solution that is commonly used for xhtml.

I've attached the proposed solution by ReeD as a patch. I've also tested it and found it to work.

Attachments

sfFillInForm.class.diff (1.6 kB) - added by vanchuck on 04/18/07 23:07:07.

Change History

04/18/07 22:07:56 changed by vanchuck

  • summary changed from [patch] fillInFormFilter can't find form with content_type = xmli to [PATCH] fillInFormFilter can't find form with content_type = xmli.

04/18/07 22:08:10 changed by vanchuck

  • summary changed from [PATCH] fillInFormFilter can't find form with content_type = xmli to [PATCH] fillInFormFilter can't find form with content_type = xml.

04/18/07 23:07:07 changed by vanchuck

  • attachment sfFillInForm.class.diff added.

08/03/07 22:01:29 changed by Carl.Vondrick

  • version changed from 1.0.0 to 1.0.5.

This is issue is still present. Even though symfony 1.1 is planned to sport a new form layer, it would be great to have this fix included in symfony 1.0. As it stands right now, fillin is unusable without fixing this. XHTML is the adopted markup for symfony, so it would be great to spit out valid XHTML. :-)

08/17/07 08:16:10 changed by Markus.Staab

  • version deleted.

would be nice to see this patch in the 1.0.x trunk.

additional information at http://symfoniac.wordpress.com/2007/08/16/getting-sffillinformfilter-to-output-valid-xhtml/

08/17/07 08:19:44 changed by Markus.Staab

would also be nice to have the content_type default to xml, because most of the symfony helpers produce xhtml compilant code.

08/20/07 16:13:57 changed by fabien

  • milestone set to 1.0.7.

08/20/07 16:14:12 changed by fabien

  • status changed from new to closed.
  • resolution set to fixed.

in r4882

08/20/07 16:15:28 changed by fabien

in r4883

09/07/07 09:42:24 changed by cristianbaciu

  • status changed from closed to reopened.
  • resolution deleted.

Doesn’t work with AJAX. We must add xml and doctype.

in util/sfFillInForm.class.php 

  public function fillInXml($xml, $formName, $formId, $values)
  {
    $flag = false; //did we change  $xml
    $is_xml = substr($xml,0,5);
    //add xml and doctype
    if($is_xml != '<?xml'){
      $flag = true;

      $xml_pre_1 = '<?xml version="1.0" encoding="'.sfConfig::get('sf_charset', 'UTF-8').'"?>';
      $xml_pre_2 = '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">';
      $xml_pre   =  $xml_pre_1.$xml_pre_2;

      $xml = $xml_pre.$xml;

    }

    $dom = new DomDocument('1.0', sfConfig::get('sf_charset', 'UTF-8'));
    @$dom->loadXML($xml);

    $dom = $this->fillInDom($dom, $formName, $formId, $values);
    //del xml and doctype
    if($flag){
      $xml = $dom->saveXML();
      $xml = str_ireplace($xml_pre_1,'',$xml);
      $xml = str_ireplace($xml_pre_2,'',$xml);
      return  $xml;
    }
    return $dom->saveXML();
  }

09/07/07 10:05:27 changed by cristianbaciu

corrected function: 

  public function fillInXml($xml, $formName, $formId, $values)
  {
    $flag = false; //did we change  $xml
    $is_xml = substr($xml,0,5);
    //add xml and doctype
    if($is_xml != '<?xml'){
      $flag = true;

      $xml_pre_1 = '<?xml version="1.0" encoding="'.sfConfig::get('sf_charset', 'UTF-8').'"?>';
      $xml_pre_2 = '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">';
      $xml_pre_3 = '<sf_additional_tag>';
      $xml_pre   =  $xml_pre_1.$xml_pre_2.$xml_pre_3;
      
      $xml_post  =  '</sf_additional_tag>';
      
      $xml = $xml_pre.$xml.$xml_post;

    }

    $dom = new DomDocument('1.0', sfConfig::get('sf_charset', 'UTF-8'));
    @$dom->loadXML($xml);

    $dom = $this->fillInDom($dom, $formName, $formId, $values);
    //del xml and doctype
    if($flag){
      $xml = $dom->saveXML();
      $xml = str_ireplace($xml_pre_1,'',$xml);
      $xml = str_ireplace($xml_pre_2,'',$xml);
      $xml = str_ireplace($xml_pre_3,'',$xml);
      $xml = str_ireplace($xml_post,'',$xml);
      return  $xml;
    }
    return $dom->saveXML();
  }

09/10/07 18:44:40 changed by gregoire

  • owner changed from fabien to noel.
  • status changed from reopened to new.
  • qualification set to Unreviewed.
  • milestone changed from 1.0.7 to 1.0.8.

10/01/07 07:55:53 changed by dwhittle

  • qualification set to Unreviewed.

Can you create updated patch?

10/02/07 19:02:09 changed by noel

  • milestone deleted.

Need to be really more tested. This can be discussed on the mailing list.

(follow-up: ↓ 15 ) 02/08/08 23:08:30 changed by dwhittle

  • qualification changed from Unreviewed to Design decision.

As fillInFormFilter is deprecated in 1.1, is this still an issue?

(in reply to: ↑ 14 ) 02/10/08 22:54:58 changed by cristianbaciu

  • milestone set to 1.0.12.

Replying to dwhittle:

As fillInFormFilter is deprecated in 1.1, is this still an issue?

Yes 1.0.xx is in production. :D

03/21/08 11:03:35 changed by noel

  • milestone changed from 1.0.12 to 1.0.13.

Sorry, it will be for the next release.

04/01/08 17:35:59 changed by gregoire

  • milestone changed from 1.0.13 to 1.0.14.

05/01/08 10:23:37 changed by FabianLange

just noticed that it even wont work with me on regular forms

05/01/08 10:59:10 changed by FabianLange

okay found it :-) if your input is no valid xhtml the 

content_type: xml

will prevent the dom document from being loaded. You cant see those issues because 

@$dom->loadXML($xml);

does not output them. This is required to ignore warnings on unknown entites. You could resolve this by 

$dom->resolveExternals = true;

but that would make a http connection every go. you dont want that :-)

Conclusion:

would also be nice to have the content_type default to xml, because most of the symfony helpers produce xhtml compilant code.

No we cannot do that as any incorrect xhtml content on the page will then prevent the fillin. There might be more users that prefer small xhtml errors in their page and can live with html fillin than those who want strictest xhtml by default. Those anyway just could put the content_type to the fillin.

ill check how to update the doc to point this out

05/01/08 11:25:10 changed by FabianLange

(In [8706]) updated documentation of fillin feature to explain html and xml content type. refs #1687

05/01/08 11:35:09 changed by FabianLange

  • owner changed from noel to FabianLange.
  • status changed from new to assigned.
  • qualification changed from Design decision to Accepted.

can confirm that ajax doesn't work correctly because the snippet returned is no valid xhtml thus not read by the xhtml parser

05/01/08 12:08:49 changed by FabianLange

  • status changed from assigned to closed.
  • resolution set to fixed.

(In r8707) fixed ajax response fillin, which does not include a doctype because it is returned without layout. fixes #1687

The Sensio Labs Network

Since 1998, Sensio Labs has been promoting the Open-Source software movement by providing quality web application development, training, consulting.
Sensio Labs also supports several large Open-Source projects.

Open-Source Products

Services

> More