Slashdot Mirror
Web Development - The Line Between Code and Content?
markmcb asks: "I help design a LAMP web site and I'm constantly plagued by trying to decide on what level should I separate functional code and markup. Depending on what you read, some say embedding HTML in your PHP scripts [or Perl, or Java, or Ruby, or Python, etc] is bad while others say it's no big deal. However, seldom are any practical applications of such code cited. How is your site built? Do you mix HTML with your code? If not, how do you overcome the simple and easy method of doing so? Lastly, what performance gains/losses have you noticed by doing so?"
In general, I disagree. Zope use a page template language that works like this:
First, you write plain HTML:
Let your design guys work on it until it looks pretty. Then you embed template code into the HTML:
Zope calls a method named "customerlist" in the same directory (for our purposes here) and gets a list of dictionaries (Perl: hash tables) as results. Then, it loops across that list. For each row, it writes out a tr tag (without the "tal:" stuff), replaces the string "Jim" inside the first td tag with the value of the "firstname" key from that row, does the same for the "lastname" key, and closes the tr. If your method returns one row, Zope writes one row. If it returns 1,000, Zope writes 1,000.
But the beauty is that the marked up template is still valid HTML that can be edited in Dreamweaver or whatever it is your web design guys like. They can do whatever they want to it, as long as they leave the "tal:" stuff alone. Then you, the programmer, write the "customerlist" method that pulls from a database, fetches from an Active Directory server, parses out of an email - whatever you think is appropriate. You don't care how the web guys write the HTML, and they don't care how you write the code.
The real magic, though, is that any page on the site can call your "customerlist" method and mangle the output as it sees fit. If someone decides they want to see lastname come first, they just write the HTML; you don't touch a line of your code. Similarly, if you replace your MS-SQL backend with PostgreSQL, your web team doesn't even need to know. They just use the results without caring where they came from.
If you can't see why this is code reuse nirvana, you don't have a very good imagination. In theory, this works great. In practice, it's even better.
Dewey, what part of this looks like authorities should be involved?
I'm part of a student-run group at my high school that is in charge of developing and maintaining our school's website, servers, and other infrastructure. This past fall, we began redoing our school's site which, up until that point, was a mish-mash of ASP and HTML. The code was ridiculous - in fact, if we ever get bored, we like to look at the old code for a good laugh. However, we put a lot of thought into different techs that could be used to redo the site. We considered PHP, ASP, Ruby-on-Rails, Python, and different Java solutions. In the end, we chose Apache Struts - it offers an incredible level of abstraction, but it works wonders for development.
Struts works by seperating business logic, actions, and markup. If, in the future, we decide we want to ditch Struts, we can keep the BL and the markup and throw out the actions for whatever we choose to replace it with.
More importantly, however, this allows us to keep code and markup seperate, allowing the backend team to tweak the code as they see fit and the layout team to likewise play with the JSPs.
In my personal practices, I generally do my damndest to keep code and markup seperate. If I'm using PHP, for instance, I'll write a simple template class that I can use to feed data into HTML without fusing the two together. It keeps things organized and (most of the time) headache-free.
I hope I've offered some useful insight - best of luck to you.
-WeAz