Sign In/My Account | View Cart  
advertisement


Listen Print Discuss

Migrating to XForms
by Paul Sobocinski | Pages: 1, 2, 3

Phase 3: Finalizing the Output

As you've hopefully noticed, we haven't actually called the function that runs the parser. This is what we do next:

/*A*/
if (!xml_parse($parser, $input["body"], true))
{
    $error = xml_error_string(xml_get_error_code($parser));
    $line = xml_get_current_line_number($parser);
    die("HTML error: " . $error . " , line " . $line);
}
xml_parser_free($parser);

/*B*/
$outhead = "<$f"."model>".$outhead."</$f"."model>";
$finaloutput = $input["top"].$input["head"].$outhead.$input["middle"].$outbody.$input["bottom"];
if (NSPACES_ON)
    $finaloutput = str_replace("<html","<html xmlns:f='http://www.w3.org/2002/xforms'",$finaloutput);

/*C*/
$outfile = "output.html";
$fh = fopen($outfile, "w");
if (!fwrite($fh, $finaloutput))
    die("Failed to write to file.");

A: xml_parse() is what puts the gears in motion -- we pass the variable representing the parser and the input that we wish to parse as the first two parameters, respectively. The third parameter is set to false if we want to pass the input in smaller chunks (this is done when the input is very large and a lot of processing is required). In our case, we will be parsing the input in one go, so we set the third parameter to true. If xml_parse() returns false, it encounters an error and is unable to finish parsing the input. When this happens, we use the xml_get_error_code() function to find out what happened, and xml_get_current_line_number() to find out where it happened. The final parser-related function, xml_parser_free(), removes the parser resource from memory. This is only done once we're finished with the parser entirely.

B: As previously mentioned, $outhead contains all the XForms elements that need to be added to the <head> tag of the output XHTML. However, before we do this, we encase all of this in a <model> tag to indicate that they are XForms tags. Now, we stick the file segments back together (as shown in Figure 1) and store the end result in $finaloutput. Before storing our result in a file, we add the namespace declaration to the <html> tag, using str_replace(). This function was explained when we used it in Phase 1.

C: Now that we have our translated form, we need to put it into a file. fopen() defines a file handler, which tells PHP that we will be doing something with a file. In this case, we will be writing to it, so we pass a parameter of w (the first parameter is the name of the output file). The function that does the actual file writing is fwrite() -- we pass the file handler we declared earlier, along with the data we wish to write. We produce an error message if the write fails.

At this point, we have consolidated the translated XHTML and written it to an output file. This marks the end of Phase 3, and the completion of the parser.

Scaling the Parser

What has been provided here are the rudimentary building blocks for a complete HTML to XForms translator. As explained earlier, the parser can be easily scaled to handle all possible HTML form elements and translate them into XForms. In addition to the introductory XForms article mentioned earlier, you may find this link useful: XForms for HTML Authors. It explains in detail how to use XForms to provide all features available with HTML forms.

All the files that were discussed (including the main translator) are available below:


Comment on this articleShare your experience in our forums.
(* You must be a
member of XML.com to use this feature.)
Comment on this Article


Titles Only Titles Only Newest First
  • From XHTML to XForms
    2006-11-20 06:14:24 Alain_COUTHURES [Reply]

    Thank you for promoting XForms.


    In fact, I am also an XSL-T fan (and not PHP which remains me of Unix scripts, when I was younger...) and I know there might big difficulties to interpret dirty HTML pages.


    So, to transform HTML to XHTML (and then allow XSL-T transformations), why not use HTML Tidy ?


    Discussing method versus purpose is rarely a good idea. About XML, it is not exactly the same because XML is tended to be universal !...


    So, if you rewrite the PHP code using an XML Notation, it will be perfect ! (joke) (but is it a joke or just the future of programming ?)

  • XHTML
    2006-11-02 00:35:39 iconara [Reply]

    "Our goal here is to take an XHTML document containing one or more standard forms, convert the forms into XForms format while preserving all of the information, and generate a new XHTML document as a result."


    It's funny then, that you bother with preprocessing things like checked, diabled, since they wouldn't be allowed in an XHTML document anyway.


    What you have done in this article is showing us how we can write a simple XML transformation utility. I have a better idea, since we are transforming XML (XHTML) into XML, why not use XSL, and get the transform engine for free. Just write the rules and you're done. I bet it would be around 20 lines of XSL, instead of this mess of half-readable PHP (not all your fault, PHP is notoriously hard to make readable).


    XSL isn't even mentioned in the article, come on isn't this XML.com?

    • XHTML
      2006-11-02 06:10:58 sobes [Reply]

      Hi there, thanks for your feedback.


      It's funny then, that you bother with preprocessing things like checked, diabled, since they wouldn't be allowed in an XHTML document anyway.


      True. However, they are quite common in an HTML document containing standard form tags. Therefore, we handled these cases so we could preserve all information in the original HTML forms document.


      What you have done in this article is showing us how we can write a simple XML transformation utility. I have a better idea, since we are transforming XML (XHTML) into XML, why not use XSL, and get the transform engine for free. Just write the rules and you're done. I bet it would be around 20 lines of XSL, instead of this mess of half-readable PHP (not all your fault, PHP is notoriously hard to make readable).


      PHP allows us the flexibility of handling input files that are either XML, XHTML, or even poorly written HTML. XSL would only work for XML input. As mentioned, HTML forms rarely fit this input requirement. Admittedly, at some points in the article I should have used the term, "HTML" instead of "XHTML." Sorry for the confusion.


      XSL isn't even mentioned in the article, come on isn't this XML.com?


      The purpose of the article was to show how PHP can be used to migrate existing HTML to XForms, not to discuss the various ways that this could be done. More time could have been spent explaining why this implementation strategy was chosen over another (e.g. you mention XSL), but this would mean less time spent on explaining the actual implementation.


      As far as the topic and its relevance, XForms is an XML implementation that is frequently covered on XML.com. In addition to the references in the article, check out Getting Started with XForms (http://www.xml.com/pub/a/2003/12/30/xforms.html) and Interactive Web Services with XForms (http://www.xml.com/pub/a/2001/09/26/xforms.html) .


      Paul Sobocinski
      (author)