Templates without frameworks...

Templates o.o

Posted 09 June 2009 - 01:55 PM

Greetings

Anyone know the best way to create a template that I can easily change without using a framework? I expect to start working on a project soon and I'll really need something like this...I used to use Dreamweaver for this sole purpose, actually, but recently I had to reinstall Vista and now I CBA....

So...any ideas? I don't really wanna take the time to learn an entire framework right now, if it's avoidable...

Replies To: Templates o.o

Re: Templates o.o

Posted 09 June 2009 - 02:07 PM

What are you looking for in a template?

I start all my php code with the assumption that I'll have a class definition followed by session_start, some code to determine if an objects been created and stored in a session variable, create it if necessary, then controlling code, and finally store the session variable(s). I have some small example files that I sometimes edit to speed things up, but other than that, the major part of writing the code is creating the methods.

Re: Templates o.o

Posted 09 June 2009 - 02:24 PM

Well, since you're asking in the php forum, you must not mean css. If you don't have a framework, then it's really up to how you write your code. I know there's a school of thought against this, but I like to put my html in my methods because that allows me to change things in multiple places simultaneously by changing a single method.

Re: Templates o.o

Posted 09 June 2009 - 02:38 PM

You could do that, but I tend to look at php as a batch file. It gets run and it's done. Then it gets run again, and it's done. For this reason, I rarely (never?) see a need to have an extra class hanging around. I rarely extend one either. I'll just toss the needed methods into my class. I suppose that could be using extra memory, especially when I store an object in a session variable...

Re: Templates o.o

I'm actually talking about the ability to massively edit the looks and layout of a site without a framework XD

Well, that doesn't really narrow it down any. You're going to have to be a little less general.

There are plenty of ways to do templates in PHP. After all, PHP itself can be used as a template system. For example, this article describes how you can build a simple, light-weight template engine using regular PHP files as your templates. You can do the same thing in a slightly less organized way simply by include()ing template files in the appropriate places. The best approach depends on what you need and how your application is structured, but everything you need is built right into plain, vanilla PHP.

Re: Templates o.o

Posted 09 June 2009 - 03:05 PM

The OOP method would be the cleanest... after that a dynamic CSS sheet would be in order to make the visible changes ... and a easy way of making a dynamic CSS sheet is actually laying it out like a PHP file

<?php
header("Content-type: text/css");
?>

that at the beginning of a PHP file will turn its contents into a CSS sheet from there you can either organize it in OOP or a simple switch...

Personally i cannot stand tables ... i absolutely DESPISE them ... and saying that DIVS are easier ( in my opinion ) to style anyways...

This may not even be what your looking for but i thought i would chime in ....

Re: Templates o.o

Here's the styling class from our BB/Forum system (not yet released...). It's fairly simple so can easily be adapted for very simple use, the only real function you'll need to call is parseTemplate.

It's fairly powerful in that it can read files, it will "compress" the data it outputs, perform simple conditional statements, output PHP Variables, contain and output blocks (repeated data defined in code as an array).

Re: Templates o.o

The thought of searching through pages of that to alter something makes me shudder. I'd much rather go through well-written OOP.

What do you mean by "well-written OOP"? Are you referring to putting HTML markup directly in your class methods?

It would be interesting to see an example of what you're talking about. No offense intended, but I have a hard time imagining what you could be doing that wouldn't make the code harder to maintain. This type of template is pretty much standard. It provides all the functionality you need in a template system (because it's all built into PHP anyway), it can be reused in different parts of the application, and it allows for a sharp separation between business logic and presentation logic. I'd be very interested in hearing exactly what you think is wrong with it and what you think would be better.

Re: Templates o.o

Posted 09 June 2009 - 04:51 PM

Well, I just did a tutorial on creating dynamic drop downs that I'd like to get your opinion about. I did it as function and the idea was that it could be made part of a class. With a little work it could be more generalized to allow more than one set of dynamic drop downs. Lots of html in that!

I don't think there's anything wrong with a template necessarily, but I have a hard time with the idea that the designer shouldn't be expected to know or at least understand OOP. That, and adding a CSS file, an include or two, and a framework/template in order to make things easier seems to always add to the confusion instead. People get lost trying to figure out where things are.

On the other hand, if I put some html in a method it's there for a reason, and I can usually see the reason right away. Maybe it's because I'm the only one working on my own code though. Still, I think most people here are able to follow things I write without much difficulty.

Edit:
I think that my basic approach is that an object may contain some business logic (I hate that phrase!) but most of the real decision making is done in the controlling code. Here's an example that seems to scale well for me:

The business logic is primarily after session_start(), and the object exists to do that logic's bidding, whether it be to calculate a value or output it. That's why it seems strange to me to look for a way to separate them. They're already separate!

Re: Templates o.o

...I have a hard time with the idea that the designer shouldn't be expected to know or at least understand OOP.

Are you talking about web designers here, as opposed to developers? If so, then I think you're just flat-out wrong. There's a reason the two job titles are separate - different skill sets and responsibilities. It's not the designer's job to be messing with back-end classes and they shouldn't be expected to understand them. In fact, the entire reason we even have things like Smarty is that many groups don't want the designers writing PHP code at all, let alone modifying classes.

Quote

That, and adding a CSS file, an include or two, and a framework/template in order to make things easier seems to always add to the confusion instead. People get lost trying to figure out where things are.

Well, you're certainly right that adding layers of abstraction makes the code harder to follow on the initial reading. If you're looking at an unfamiliar codebase, a straight-forward approach is much easier to follow. But that's not the point. The goal should be long-term maintainability, not making things easy for new programmers. In my experience, adding abstractions and separating concerns gains you more in the long run than it costs in ramp-up time for new developers.

Quote

That's why it seems strange to me to look for a way to separate them. They're already separate!

Well...sort of. As you descibe it, you have indeed separated the "business logic" from the display logic. However, you've instead coupled the display code with your domain object, which, while different, really isn't any better.

Actually, it's funny you should use the rectangle example. On "Uncle Bob" Martin's page on the SOLID principles, the link for the Single Responsibility Principle uses this exact same example. Basically, a class - particular a domain object - should have a distinct purpose, i.e. one reason to change. The rectangle class doesn't really need to know how to display itself. There are any number of ways you might want to display the rectangle data, depending on the context. Having to change the rectangle class every time you want to try a new way becomes unmaintainable in the long run. It's better to just delegate that responsibility completely.

I have a few thoughts/suggestions on that. I don't mean to be critical - I think it's great that you're contributing to the community - it's just that I would have done it very differently.

First, one thing that really bothers me is all the strings of HTML and Javascript code. Just drop out of PHP mode, for crying out loud! I don't mean to single you out, but I've noticed that a disturbing number of people in this forum like to echo out HTML code from PHP. Maybe it's a personal preference thing, but this just drives me crazy. My biggest gripe is that it defeats tool support. Any good code editor or IDE will do syntax highlighting (and maybe even intellisense and code completion) for HTML and Javascript code in PHP files if they're outside the <?php ?> blocks. With code in strings...not so much. Also, I just find it harder to read, what with having to worry about escaping quotes and concatenation and whatnot.

Moving on to more substantive issues, I don't necessarily have any problem with encapsulating all of this in a function call if your intention is for people to use it as a drop-in menu component. That can be a useful technique in certain circumstances. However, I don't really see how what you have is any different than a simple template. All you're doing is echoing out a bunch of code and doing a little processing to massage the input into the format you want - which isn't really necessary because it could just as easily be made the responsibility of the caller. It's just doing the same thing with different syntax. And as far as making this a class method goes, absent any context, it's not at all clear to me why you'd want to do that.

What's more, I really don't think there's any need to do this in PHP at all. There's nothing here that really needs to be done on the server-side, so I don't see why you couldn't do the whole thing in straight Javascript. Instead of using PHP to generate a bunch of Javascript arrays, it seems to me you could just as easily have passed in a Javascript object literal as your input. Not only would the code be clearer, but it would also be usable from any server-side language, because the caller just needs to generate JSON. In fact, this kind of smells like the sort of thing you'd write a jQuery plugin for.

Re: Templates o.o

Posted 10 June 2009 - 08:53 AM

AdaHacker, on 10 Jun, 2009 - 10:54 AM, said:

Quote

...I have a hard time with the idea that the designer shouldn't be expected to know or at least understand OOP.

Are you talking about web designers here, as opposed to developers? If so, then I think you're just flat-out wrong. There's a reason the two job titles are separate - different skill sets and responsibilities. It's not the designer's job to be messing with back-end classes and they shouldn't be expected to understand them. In fact, the entire reason we even have things like Smarty is that many groups don't want the designers writing PHP code at all, let alone modifying classes.

Yes and no. I wouldn't expect a web designer to modify the back-end methods, but I would expect them to be able to modify a class method that contained html output. If you really wanted to keep them separate, you could have class_two extends class_one and one class has the output and the other the business logic. No need to go any further.

Quote

That's why it seems strange to me to look for a way to separate them. They're already separate!

AdaHacker, on 10 Jun, 2009 - 10:54 AM, said:

Well...sort of. As you descibe it, you have indeed separated the "business logic" from the display logic. However, you've instead coupled the display code with your domain object, which, while different, really isn't any better.

I think it's better because it's simpler, and it achieves the same goal without adding overhead.

I have a few thoughts/suggestions on that. I don't mean to be critical - I think it's great that you're contributing to the community - it's just that I would have done it very differently.

Well, it is more to demonstrate the concept than anything else. I'd want to generalize it a bit more before adding it to a class. It would be good to be able to have more control over divs and values/options, etc.

AdaHacker, on 10 Jun, 2009 - 10:54 AM, said:

First, one thing that really bothers me is all the strings of HTML and Javascript code. Just drop out of PHP mode, for crying out loud! I don't mean to single you out, but I've noticed that a disturbing number of people in this forum like to echo out HTML code from PHP. Maybe it's a personal preference thing, but this just drives me crazy.

It's definitely a preference thing. I learned to program before there was html, and when I see people break out/in of/to php it makes my skin crawl. To me, html is just data like any other. You echo/print it to a device, which then does what it does with it. It isn't code in the sense of a program, at least until it gets to the client side, so treating it like code just adds to the confusion. While an editor can help, just looking at that makes my eyes glaze over.

AdaHacker, on 10 Jun, 2009 - 10:54 AM, said:

What's more, I really don't think there's any need to do this in PHP at all. There's nothing here that really needs to be done on the server-side, so I don't see why you couldn't do the whole thing in straight Javascript. Instead of using PHP to generate a bunch of Javascript arrays, it seems to me you could just as easily have passed in a Javascript object literal as your input.

I did it using php because I saw people asking how to do it in php. Also, I'm not as good in javascript, probably because I tend to view javascript as a necessary evil with its inherent insecurity and browser compatibility issues. I'll look into it though!