[Tutorial - PHP] An idea for a CMS

[gaburieru]

I've always thought that making templates for CMS/Blogs could be easier. But can it be so easy that you won't have to learn anything additional (except for HTML/CSS) AT ALL?

I recently came up with the idea.
"What if you could parse HTML into PHP, instead of the otherway around that moste CMS do today?"

I say you can! THIS (http://simplehtmldom.sourceforge.net/) handy little piece of AWSOMENESS let you do that. In short, it crawls the DOM of a html-document and edit it. The designer would only have to read the docs and assign proper id/class for the elements.

The CMS could insert the navigation into <ul id="nav">.

Instead of this:
<ul>
<?php print_navigation() ?>
</ul>

Developing this on your own would be hard though...

GIMMIE FEEDBACK!!

[Eris]

PHP isn't difficult. If you don't understand enough PHP to use it, then you don't understand enough about dynamic web programming to be doing dynamic web programming, and constitute a danger to yourself and others.

It isn't just enough to accidentally slap together code that does approximately kinda what you sorta like it to do, you need code that you know excactly what it does and does not do. Anything else would be a security nightmare.

But if you want point-and-drool web design, ruby on rails should be up your alley:

Gzj723LkRJY

[div]

@Fist of Internet Justice: Just curious - have you ever worked with Ruby on Rails? It seems pretty hyped, but it might be actually useful too.

Also, I've never understood the point of these pre-written CMS scripts that keep popping up. Well, actually, I understand the point of them, but it always feels like more work to properly "configure" them than it is to just write your own framework/code based on whatever you're actually trying to accomplish.

In regards to "parsing HTML into PHP," why not just use "include" statements? A lot of "template" systems seem overcomplicated. Include a common HTML header, footer, layout, etc. The point of templating is to have one consolidated chunk of HTML for a given purpose. I've always thought that it makes a lot more sense to just learn HTML rather than use some convoluted half HTML/CSS, half PHP thing.

...And that's not to shoot down your idea. It's an interesting concept, really. The problem with it is that I don't think it's a good idea for someone to make something without sufficiently understanding how the back-end actually functions. You'd end up needing to know how to write the HTML/CSS such that the PHP script would know what to do with it, which would likely be about as complicated as just writing the PHP yourself, if that makes sense. I think I just restated what Fist of Internet Justice said, basically.

@gaburieru: If you want to try writing something like this, I'd be willing to help. It would be a fun project.

[TodPunk]

It would be a good excercise in templating, and might be more useful from a security standpoint. If they get the raw html file, it still looks like something, and doesn't have any dynamic data in it. No PHP code gets out, etc.

All in all, I agree with Cerebral, it's probably just as over-complicated as any other templating/themeing system, but probably easier for people to understand in the layman ways of things.

[Eris]

@Fist of Internet Justice: Just curious - have you ever worked with Ruby on Rails? It seems pretty hyped, but it might be actually useful too.

It is a bit over-hyped, but it does definitely have strong benefits over PHP since it's strictly Model-View-Controller based. . It's forces a degree of structure that's possible in PHP, but very seldom actually implemented.

And since it's so well structured, it can do a lot of grunt work for you as well, which is pretty nice.

[TandooriDude]

The HTML DOM Parser sounds pretty handy actually, saves a lot of writing.

A little off topic but why haven't many CM systems started implementing ajax yet? It would be awesome if forums were real time, and open a whole new world of opportunities for the users and administrators. Is it just too much data processing to handle in real time?

[Eris]

The HTML DOM Parser sounds pretty handy actually, saves a lot of writing.

A little off topic but why haven't many CM systems started implementing ajax yet? It would be awesome if forums were real time, and open a whole new world of opportunities for the users and administrators. Is it just too much data processing to handle in real time?

The problem with Web 2.0 is that it is insanely bandwidth intensive. Since AJAX is a request/response system, the clients need to poll for status updates, as there is no way for the web server to tell this to the clients without them asking for it. And to get things running smoothly, they need to do this very often (like once a second). Adding to this, the way most webservers are written, this also entails a database request per request, which drains server power even more.

[TandooriDude]

True, I was thinking of a far fetched approach with xml, haha. Replacing the data in the child node using php, under the "forum name" parent everytime the topic is changed in someway.

Server requests would be something small like once per second, but since its a xml tree-based operation it wouldn't have to read through the server to find+replace, just the xml file.

I'm really new to php and ajax haha, I just like thinking bout it in a pseudo way. Would reading and writing to an xml file be possible with a forum? Just for the "topic" updates (like what updates normally when the page is refreshed).

[Eris]

You use DOM scripting for that. Something like



<script language="javascript">
foo = function() {
var message = document.createTextNode('Hello World');
var b = document.createElement('b');
b.appendChild(message);
document.getElementById('hello').appendChild(b);
};
</script>
<body onLoad="foo()">
<div id="hello"></div>
</body>


Which results in a page that looks like


<body>
<div><b>Hello World</b></div>
</body>


This is of course a pretty stupid way of doing that, but the point is that it works just as well from any javascript function -- including the handlers of AJAX responses.

Just google DOM Scripting in Javascript and you'll find tons of resources.

[TandooriDude]

Ah sorry, I just meant is it less bandwidth intensive to use xml for constantly updating information?

Still a stupid pseudo idea haha.

[Eris]

Ah sorry, I just meant is it less bandwidth intensive to use xml for constantly updating information?

Still a stupid pseudo idea haha.

It's how you would normally do it when you use AJAX, so no, it's not less intensive.