Bay 12 Games Forum
Finally... => Creative Projects => Topic started by: Jookia on February 15, 2010, 06:09:05 am
-
I'm making an experimental CMS in PHP. Using XML for the data and letting the theme to do HTML, allowing much greater flexibility.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="themes/red/post.xsl"?>
<page>
<properties>
<name>XMLCMS</name>
</properties>
<content>
<post>
<name>First post is this!</name>
<body>
THIS IS A FIRST POST
</body>
</post>
<post>
<name>Second post title is this!</name>
<body>
THIS IS A SECOND POST
</body>
</post>
</content>
</page>
Produces this with my theme.
(http://i46.tinypic.com/o7psw5.png)
Since the themes are a set of 'rules' in XSLT, the browser caches the rules and only downloads the XML data (which is the only thing that changes), thus loading pages way faster as you already have the stuff downloaded, your computer just has to assemble it in to a page.
-
Slick. I'm looking at doing something very similar for a project for work.
Only thing I'd worry about is performance. Does PHP's XML library use C under the hood?
-
PHP only generates the ata from the SQL database (not yet, but soon) then echos it to the page with XML tags and crap, then the browser puts everything together.
The point is, if I finish this up to a point, this'll allow WAY more cool themes since there's no real style, everything is just data passed to the current theme.
-
Ah, I see. I'd never seen that behavior before; I was looking at doing a server-side transform to HTML. Looks reasonably flexible, although perhaps not as much as something like Drupal's PHPTemplate (a problem with my design, too).
-
REAL MEN USE DJANGO
-
Also it'd be easier on the server as most CMSs generate the HTML. Look at this page, all this HTML was generated as you loaded it instead of a set of rules that you downloaded. The computer should be doing the HTML, not the server. Gosh.
-
Isn't that kinda the point of doing your themes in CSS and providing the structure in HTML? You can update the page without reloading the CSS.
For generated pages I also find that I have more potentially useful data than I do on the created HTML, so you'd still have to parse everything server side and only provide the minimal dataset. Even then I'm not sure you'll get much, if any, saving on page weight.
Possibly I've misunderstood what your trying to achieve though?
-
The HTML isn't downloaded more than once.
-
The HTML isn't downloaded more than once.
But the data is in the XML which is downloaded again and so the weight is approximately the same.
-
Ugh, it's hard to explain.
-
The HTML isn't downloaded more than once.
But the data is in the XML which is downloaded again and so the weight is approximately the same.
This is incorrect. Sending semantic XML is cheaper over the long run than fully decorated HTML; the XSLT is cached and you'll save both server memory and cycles because you're constructing only the XML document instead of building the entire HTML structure every time.
On most sites you'd see a CMS on, you can expect 5% to 20% overhead reduction in bandwidth and maybe a few percent of cycles and memory. Not a lot, but nice if you have it available.
-
This is incorrect. Sending semantic XML is cheaper over the long run than fully decorated HTML; the XSLT is cached and you'll save both server memory and cycles because you're constructing only the XML document instead of building the entire HTML structure every time.
I'll agree it's possible, but not certain, you'll get a saving in the XML weight. Writing HTML vs XML in the output is of limited difference as you will have to do the same processing so you know what data is required for the page so I think the processing and memory will be similar. If you don't process it then you'll have to send more data because it could be potentially needed by the system.
Of course if the client only requested the blocks of data it knew it needed then you could shift processing that way but then your more into the whole client side scripting aspect which is slightly off topic.
The overhead on high load server tends towards cycles (or memory if you have heavy cache strategies in place) rarely bandwidth, and if you have your scaling done correctly then your bottle neck is database writes, which leads to the need for either document databases rather than relational ones or smart sharding schemes which is again off topic. Of course less bandwidth use is always good as you can get faster response times and we can only wait and see if that is the case here.
I'd be happy to give the CMS a try though.
Only thing I'd worry about is performance. Does PHP's XML library use C under the hood?
It does :) not that it matters in this case. Most extensions, and the core of the language are c based, also once you start using things like APC you have very little overhead from interpreting the PHP while the cache stays warm.
-
This is incorrect. Sending semantic XML is cheaper over the long run than fully decorated HTML; the XSLT is cached and you'll save both server memory and cycles because you're constructing only the XML document instead of building the entire HTML structure every time.
I'll agree it's possible, but not certain, you'll get a saving in the XML weight. Writing HTML vs XML in the output is of limited difference as you will have to do the same processing so you know what data is required for the page so I think the processing and memory will be similar. If you don't process it then you'll have to send more data because it could be potentially needed by the system.
Nope. All you have to do is send the XSLT once--and it's built offline as the template--and use it to transform the XML documents your web server serves. Go look at Drupal's PHPTemplate and tell me how much of that isn't boilerplate that could be sent once and forgotten about.
Of course if the client only requested the blocks of data it knew it needed then you could shift processing that way but then your more into the whole client side scripting aspect which is slightly off topic.
You're thinking of AJAX crap. Any modern browser will just cache the full-page XSLT and transform the XML as it's received.
The overhead on high load server tends towards cycles (or memory if you have heavy cache strategies in place) rarely bandwidth,
And this significantly reduces them because you are doing all your block placement, format decoration, etc. on the client size.
-
Do you plan on reducing the verbiage of your xml format to further save on transmit costs at the expense of human readability?
-
And this significantly reduces them because you are doing all your block placement, format decoration, etc. on the client size.
Except this is all done in CSS and so true anyway. Which goes back to the point about the data in the XML and the fact there is no real indication it will be any less than the XHTML.
-
Do you plan on reducing the verbiage of your xml format to further save on transmit costs at the expense of human readability?
No.
-
And this significantly reduces them because you are doing all your block placement, format decoration, etc. on the client size.
Except this is all done in CSS and so true anyway. Which goes back to the point about the data in the XML and the fact there is no real indication it will be any less than the XHTML.
Again, no. The transforms are sent to the browser once and cached there.
-
And this significantly reduces them because you are doing all your block placement, format decoration, etc. on the client size.
Except this is all done in CSS and so true anyway. Which goes back to the point about the data in the XML and the fact there is no real indication it will be any less than the XHTML.
Again, no. The transforms are sent to the browser once and cached there.
Possibly. But CSS and js files are also cached by many browsers. You will be sending uncompressed and verbose xml. is there really that big a difference between:
<page><properties><name>XMLCMS</name></properties><content><post><name>First post is this!</name><body>THIS IS A FIRST POST</body></post><post><name>Second post title is this!</name><body>THIS IS A SECOND POST</body></post></content></page>
and:
<html><head><title>XMLCMS</title></head><body><div class="title">XMLCMS</div><div class="post"><div>First post is this!</div><div>THIS IS A FIRST POST</div></div><div class="post"><div>Second post title is this!</div><div>THIS IS A SECOND POST</div></div></body></html>
If you really wanted to save bandwidth for decoration, you can serve data to the browser as JSON and assemble it with javascript...
{"properties":{"title":"XMLCMS"},"content":{"posts":{"First post is this!":"THIS IS A FIRST POST","Second post title is this!":"THIS IS A SECOND POST"}}}
If you really want to make a difference in bandwidth, you should do something like that. Likewise you can arrange your code to separate css and js from your html files so they are cached. But if you are just doing this to exercise your programming muscles? by all means, go for it. But it won't be significantly more bandwidth and processor efficient than well built html.
-
Best results:
A C(or other compiled language) program that downloads just the new/edited posts in one of 256 entirely diffrent compression formats, whatever one gets the best size, and then extracts it into the local-PC board set.
Due to the processing involved, this would only be the best solution when the bottleneck is transmission speed. Maybe that is how the interplanetary BBS system will work, the servers on each planet using that for communication and others getting the pages in more standard HTML/IPML(interplanetary markup language) from the local server?
But still, a program that caches posts as well as the layout and assembles it, only downloading new posts and edits would be the most optimal solution, discounting the program itself's download...
-
But still, a program that caches posts as well as the layout and assembles it, only downloading new posts and edits would be the most optimal solution, discounting the program itself's download...
I'm getting a little off topic here but pretty much you can do this with something along the lines of Comet (http://en.wikipedia.org/wiki/Comet_%28programming%29). It requires some modification to the standard way you setup a webserver to allow the high connection counts required but it allows you to send only the latest changes. And as your almost certainly using JavaScript to do it then sending the data as compressed JSON is the default and cheaper than XML.
-
I'm using XSLT to do it.