Re: [PHP] How about a saveXHTML for the DOM?
Michael A. Peters wrote:
With respect to templating systems, I don't use them but if you have a
DOMDocument orientated template system, I don't see why it couldn't do
the same thing -
As an experiment, I took one of my pages that was a little sluggish due
to lots of database calls (sluggish on my home machine anyway) - since
the database content rarely changes for the data presented, I made a
page I can grab nightly in cron that spits out just the main content div
where all the DB calls are made.
-=-
$cached = 'species_cache.php';
$SL = file_get_contents($cached);
$SDOM = new DOMDocument("1.0","UTF-8");
$SDOM->loadXML($SL);
$elements = $SDOM->getElementsByTagName("div");
$imported_div = $elements->item(0);
$contentDiv = $myxhtml->importNode($imported_div,true);
-=-
species_cache.php
is just a text file with a div and all it's children.
Sped up the page considerably on my home machine, and works spledidly
regardless of whether or not I am sending it as html or xhtml.
So I think my technique would work with template systems.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
Raymond Irving wrote: If I remove the \r from the file using preg_replace() then it shows up just fine. I was just wondering if there was a way to suppress the \r in the xml output. Another thing that I've observed while looking at your code is that it only works best for dynamic web pages. It appears that it would not work well when using page caching or page templates. I really think having a function that generates xhtml (html compatible) output, would really eliminate all these workarounds that we will have to do in order to get the page to render inside popular web browsers. A lot of developers produce xhtml web pages that are html 4 compatible, so that they can be rendered in browsers that only supports html rendering. This is something that I think the PHP DOM should be able to support with ease. If you want to send the same page for everybody than use html 4.01 (or html 5 when it is ready) and the saveHTML() function. The only reason I don't do that is because I wish html would go away, so I generally send valid xhtml (header and all) and only provide the html as a fall back for inferior browsers. With respect to templating systems, I don't use them but if you have a DOMDocument orientated template system, I don't see why it couldn't do the same thing - as far as the DOM used to generate xhtml (via saveXML()) or html (via saveHTML()) - the only difference is the DTD and the fact that xhtml sometimes uses namespaced attributes (which may get stripped with saveHTML() anyway) That's the beauty IMHO of DOMDocument - virtually identical data in the DOM can produce valid html or xhtml - as long as you aren't using xhtml only extensions (like MathML). So it should work beautifully with a templating system, as long as the templating system is built for DOMDocument consumption. I think there are a few. How well they work with caching I don't know. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
If I remove the \r from the file using preg_replace() then it shows up just fine. I was just wondering if there was a way to suppress the \r in the xml output. Another thing that I've observed while looking at your code is that it only works best for dynamic web pages. It appears that it would not work well when using page caching or page templates. I really think having a function that generates xhtml (html compatible) output, would really eliminate all these workarounds that we will have to do in order to get the page to render inside popular web browsers. A lot of developers produce xhtml web pages that are html 4 compatible, so that they can be rendered in browsers that only supports html rendering. This is something that I think the PHP DOM should be able to support with ease. Best regards, __ Raymond Irving --- On Fri, 4/10/09, Michael A. Peters wrote: > From: Michael A. Peters > Subject: Re: [PHP] How about a saveXHTML for the DOM? > To: "Raymond Irving" > Cc: "php-general@lists.php.net" > Date: Friday, April 10, 2009, 6:35 PM > Raymond Irving wrote: > > > > Thanks for the feedback Michael. I will look into your > suggesstions. > > > > Is there an option on the DOMDocument that we can set > to not have saveXML() append to the end of the tags? > > > > This is normally the case if the html content was > loaded using loadHTMLFile() > > I think I've seen that appear in textarea as well - I > believe it has to do with the libebreaks of the application > that created the file (or in case of textarea from a form, > the line break convention of the browser). > > Does it happen when you run > > sed -i 's/\r//g' file.html > > to remove the DOS carriage return from the line breaks? > > That would be my guess. > > -- PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
Raymond Irving wrote: Thanks for the feedback Michael. I will look into your suggesstions. Is there an option on the DOMDocument that we can set to not have saveXML() append to the end of the tags? This is normally the case if the html content was loaded using loadHTMLFile() I think I've seen that appear in textarea as well - I believe it has to do with the libebreaks of the application that created the file (or in case of textarea from a form, the line break convention of the browser). Does it happen when you run sed -i 's/\r//g' file.html to remove the DOS carriage return from the line breaks? That would be my guess. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
Thanks for the feedback Michael. I will look into your suggesstions. Is there an option on the DOMDocument that we can set to not have saveXML() append to the end of the tags? This is normally the case if the html content was loaded using loadHTMLFile() __ Raymond Irving --- On Fri, 4/10/09, Michael A. Peters wrote: From: Michael A. Peters Subject: Re: [PHP] How about a saveXHTML for the DOM? To: "Raymond Irving" Cc: "php-general@lists.php.net" Date: Friday, April 10, 2009, 3:57 PM Raymond Irving wrote: > > > > --- On Wed, 4/8/09, Michael A. Peters wrote: > >> From: Michael A. Peters >> Subject: Re: [PHP] How about a saveXHTML for the DOM? >> >> saveXML() already does what is needed to provide valid >> xhtml output. > > From my test it sometimes generate this like at the end of the page elements. It also generate things like which does not work in most browsers. >
Re: [PHP] How about a saveXHTML for the DOM?
Michael A. Peters wrote:
$myxhtml->loadXML($xmlstring);
$elements = $myxhtml->getElementsByTagName("html");
$xmlHtml = $elements->item(0);
?>
forgot this tidbit -
setAttribute("xmlns","http://www.w3.org/1999/xhtml";);
$xmlHtml->setAttributeNS('http://www.w3.org/XML/1998/namespace','xml:lang','en');
}
*now* you can have your php code populate the dom by appending children
to $xmlHtml neutral to whether or not it eventually is going to be sent
as xml or html.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
Raymond Irving wrote: --- On Wed, 4/8/09, Michael A. Peters wrote: From: Michael A. Peters Subject: Re: [PHP] How about a saveXHTML for the DOM? saveXML() already does what is needed to provide valid xhtml output. From my test it sometimes generate this like at the end of the page elements. It also generate things like which does not work in most browsers.
Re: [PHP] How about a saveXHTML for the DOM?
--- On Wed, 4/8/09, Michael A. Peters wrote: > From: Michael A. Peters > Subject: Re: [PHP] How about a saveXHTML for the DOM? > > saveXML() already does what is needed to provide valid > xhtml output. From my test it sometimes generate this like at the end of the page elements. It also generate things like which does not work in most browsers. So we have to process the out string to convert things like to and There are other times when saveXML will remove the \n altogether from the code which caused tags to be displayed in a single line. In addition saveXML() does not preserve html entities. So things like © gets converted to ©. Sometimes working with saveHTML and saveXML is like being caught between a rock and a hard place. I'm trying to figure out which would be easier to do: Going from saveHTML() to XHTML Going from saveXML() to XHTML __ Raymond Irving Create Rich Ajax/PHP Web apps Today! Raxan PDI - http://raxanpdi.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
On 9/4/09 04:55, Michael A. Peters wrote: IE (still) does not properly support XHTML. It will render an XHTML page sent with the text/html mime type - but that's actually a standards violation. Is it? What standard is it violating? "XHTML Documents which follow the guidelines set forth in Appendix C, "HTML Compatibility Guidelines" may be labeled with the Internet Media Type "text/html" [RFC2854], as they are compatible with most HTML browsers." http://www.w3.org/TR/xhtml1/#media "Due to the long and distributed development of HTML, current practice on the Internet includes a wide variety of HTML variants. Implementors of text/html interpreters must be prepared to be "bug-compatible" with popular browsers in order to work with many HTML documents available the Internet. … [XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html." http://www.ietf.org/rfc/rfc2854.txt (I'm not saying it's a good idea, mark you! http://hixie.ch/advocacy/xhtml ) -- Benjamin Hawkes-Lewis -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
On Thu, Apr 9, 2009 at 12:25 AM, Michael A. Peters wrote: > I did a little reading on the issue and I don't think php 6 will fix it. > The issue is with libxml2 - it mutilates utf8 when exporting to html and php > function wraps the libxml2 function. not to mention i swore i tried saveXML and it didn't work either. but maybe it was because the output was unusable... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
On Thu, Apr 9, 2009 at 12:25 AM, Michael A. Peters wrote: > I did a little reading on the issue and I don't think php 6 will fix it. > The issue is with libxml2 - it mutilates utf8 when exporting to html and php > function wraps the libxml2 function. > > The solution? > I don't know - but perhaps using saveXML() and then using a translation tool > (maybe xslt?) to convert to HTML. > > I actually had a function I wrote using preg_replace (started out as a > wordpress plugin someone else wrote) but it could not properly handle cdata > blocks - I'll see if I can find it. > > I don't use it anymore as I use saveHTML() now for html output. > > Maybe running iconv on the output would fix it? > I tried to the best of my abilities. it looks like it was reported as a bug years ago, but classified as not a bug or something. I tried iconv, I am not the best hacker when it comes to encoding manipulation. At the moment this was the best workaround someone had posted, and I have not sanity checked that this gets into MySQL then back out on the webpage properly as UTF-8, but it -appears- to work html_entity_decode($dom->saveHTML(),ENT_QUOTES,"UTF-8"); -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
Michael Shadle wrote: On Wed, Apr 8, 2009 at 8:58 PM, Michael A. Peters wrote: Yes it should - I believe php 6 is suppose to be much better at native UTF8. At least according to some blog I read somewhere (IE don't believe me without reservation, it's third hand knowledge at best) afaik you're right, it's supposed to be fully unicode. or at least -was- however, how long until it is production stable... when i am sure someone can hack together a patch to make saveHTML unicode capable :p I did a little reading on the issue and I don't think php 6 will fix it. The issue is with libxml2 - it mutilates utf8 when exporting to html and php function wraps the libxml2 function. The solution? I don't know - but perhaps using saveXML() and then using a translation tool (maybe xslt?) to convert to HTML. I actually had a function I wrote using preg_replace (started out as a wordpress plugin someone else wrote) but it could not properly handle cdata blocks - I'll see if I can find it. I don't use it anymore as I use saveHTML() now for html output. Maybe running iconv on the output would fix it? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
On Wed, Apr 8, 2009 at 8:58 PM, Michael A. Peters wrote: > Yes it should - I believe php 6 is suppose to be much better at native UTF8. > At least according to some blog I read somewhere (IE don't believe me > without reservation, it's third hand knowledge at best) afaik you're right, it's supposed to be fully unicode. or at least -was- however, how long until it is production stable... when i am sure someone can hack together a patch to make saveHTML unicode capable :p -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
Michael Shadle wrote: i think it should also be fully utf-8 capable. saveHTML is not for me right now, and i have to run some preg_replace to remove the etc chunks, and the output is not utf-8, even though the input is. i got a workaround using html_decode_entities() or something like that but i haven't ran it to see really how well that works... but i would expect if you give the dom functions utf-8, and even specify utf-8, it should operate as utf-8 the entire time, including during save() ... Yes it should - I believe php 6 is suppose to be much better at native UTF8. At least according to some blog I read somewhere (IE don't believe me without reservation, it's third hand knowledge at best) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
Raymond Irving wrote:
Hello,
I'm thinking that it's about time a saveXHTML() method be added to the DOM
objects.
Not necessary.
saveXML() already does what is needed to provide valid xhtml output.
See the php source of http://www.clfsrpm.net/xss/dom_script_test.phps
to see how one can server-side detect whether or not to use saveHTML()
or saveXML()
XHTML is supported by all major browsers and libxml2
IE (still) does not properly support XHTML.
It will render an XHTML page sent with the text/html mime type - but
that's actually a standards violation.
so I can't see why we should be stuck with saveHTML() and saveXML(). While it's
true that some developers are using saveXML(), it does not always comply with
the XHTML standards.
Where does it deviate from xhtml standard?
xhtml is a subset of xml - if your DOMDocument is valid xhtml then the
output of saveXML() should be as well.
Another problem with saveXML() is the lack of support for HTML entities.
An xml document does not need HTML entities.
If the bro
There are many tricks out there to cleanup the output of saveXML()
What tricks are needed?
but I think having a native function would be much more efficient and faster.
What do you think?
I think it is not necessary.
There are some issues - IE
is valid xml and I believe validates as xhtml - but (at least with older
versions of Mozilla) does not render correctly. Knowing that - I always do
$xmlAnchor = $myxhtml->createElement("a"," ");
$xmlAnchor->setAttribute("id","foo");
but that's a browser bug, not a saveXML() bug.
I'm really curious to know where saveXML() fails to produce valid XHTML
when the DOM structure is valid XHTML.
Rememver, XHTML is extendable - there's MathML and SVG that many
browsers already know what to do with, and I'm sure others will be
added. Unless a saveXHTML() function can be told what to do in those
cases, what's the point?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How about a saveXHTML for the DOM?
i think it should also be fully utf-8 capable. saveHTML is not for me right now, and i have to run some preg_replace to remove the etc chunks, and the output is not utf-8, even though the input is. i got a workaround using html_decode_entities() or something like that but i haven't ran it to see really how well that works... but i would expect if you give the dom functions utf-8, and even specify utf-8, it should operate as utf-8 the entire time, including during save() ... On Wed, Apr 8, 2009 at 7:01 PM, Raymond Irving wrote: > > Hello, > > I'm thinking that it's about time a saveXHTML() method be added to the DOM > objects. > > XHTML is supported by all major browsers and libxml2 so I can't see why we > should be stuck with saveHTML() and saveXML(). While it's true that some > developers are using saveXML(), it does not always comply with the XHTML > standards. Another problem with saveXML() is the lack of support for HTML > entities. > > There are many tricks out there to cleanup the output of saveXML() but I > think having a native function would be much more efficient and faster. > > > What do you think? > > > __ > Raymond Irving > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
