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?"
I taught myself to script perl a few years ago, and no one told me one way or the other. So I decided to embed the html a bit in the code, and I really can't think of a good reason why it would be bad to mix the html, unless its for the sake of the clarity of the code.
I had to implement an intranet site using zope/plone which seemed to prefer a separation, but I saw no reason for it, except the obvious use of templates, and just went ahead business as usual. So i think this is just a matter of preference.
I personally find it easier to integrate (X)HTML with my PHP. When I've needed to store them seperately, though, I've seen no performance differences and I highly doubt that there would be anything significant. PHP is fast.
Then again, I've never used Perl, Python, or Ruby for web development. Perhaps they're different.
ROMANES EUNT DOMUS
BTW, if you're looking for a nice framework for Java web development I highly recommend Stripes. I stumbled across it last year and it is much nicer to use than Struts!
My web pages break down as such...
I build a content page using HTML and CSS. No tables unless it is to display data. Trying to make it as clean as possible.
I then move any HTML that repeats throughout the site (usually header and footer) into includes.
I then create the functions that will build my menus and populate the content. I put these into classes.
Call the class in the header include. Call the functions where apporpriate, and viola! I have five documents: CSS file, header, footer, class/function file, and then all the other pieces that are left in the original HTML document. Usually I will end up with a six document that has all the javascript, if necessary.
Technically, you could build the header and footer to be functions, and cut down to two documents, but I have found that to be a bit of overkill, as usually the stuff in these are not very dynamic.
Now, there may be some HTML in my functions. After all, if the function is going to put out HTML, then it probably needs HTML in it. But I try not to build any function-type code into the HTML. The nice thing about this set up is the core HTML document needs virtually no maintenance, and can be used for every single content page, assuming you are passing which page you need to the appropriate function.
The world moves for love. It kneels before it in awe.
I use eGroupWare which was forked from phpGroupWare. Both of these have a utility called "eTemplates" which does all the HTML for you. Try it, you'll like it, productivity is awesome, something like several pages of working, tested, debugged, HTML per day.
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've tried sticking to MVC in a desktop application I'm working on, and I've found it quite hard to integrate the three layers."
/. poster).
Allen Holub agrees with you. So do others TOP may be an alternative (Tablizer is a
I used XML Query templates for a project recently (there are quite a few implementations of XQuery, both proprietary and open source).
:-)
I found that development was fast (although I already knew both XQuery and XML in general) and that once my XML Query expressions passed through the compiler (static type checking is your friend) they mostly worked first time, so that I had something working in an hour and a reasonably robust site within a day.
There's a page about the image search in particular at http://www.fromoldbooks.org/Search/about.html although it's fairly high level.
Using XML as an integration language, and either XQuery or XSLT to generate HTML where needed, really does help to enforce separation. An advantage of XQuery is that the implementations are getting pretty fast, and are beginning to use indexes for multiple files or database access.
Disclaimer: I work full-time for W3C, and we publish both XML and XQuery
Live barefoot!
free engravings/woodcuts
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
If your businesslogic breaks when you change the site layout then embedding HTML in your business logic clearly was a bad idea. Doing so gets you up and running soon but you pay the price later when doing maintenance.
Putting some time and effort in separating logic and presentation is not a novelty. The MVC pattern dates from the seventies. The n-tier server architecture was invented shortly thereafter. These two are now well accepted architectures for separating logic and presentation.
As for performance. Code that mixes everything together tends to be naive in multiple ways, including performance, security, extensibility, etc. Optimizing performance generally requires using caching, pooling and other types of strategies. These are hard to retrofit in monolithic single tier systems. Again there's no absolute truth here: you just may be the genius that gets it right in one go.
So it all depends on the question are you the guy who's doing the maintenance and/or will you be there when the shit hits the fan when somebody else tries to do it for you. If so, you are probably better off doing a proper job. On the other hand, out of control IT projects are a great way to milk stupid customers. Many IT businesses have built their empire on that kind of incompetence and billions of dollars still change hands annually for software projects that are over time, over budget and ultimately disappointing.
Jilles
We're using Zope/Plone in my organisation to replace our current intranet system. So a couple of months ago I went over to India to get some training on the system. Had I ever used, seen or even heard of tal templating before? Nope. Guess how long it took me to pick it up? Uhm... about one afternoon. Seriously. It's a frickin' templating language, how hard can it be?
And in my organisation, I'm not the coder, I'm the designer, who according to your rather patronising post, couldn't possibly master a new templating language. Well guess what, I can, in about 3 hours. Happily. You're a professional coder who regularly deals with Java or C++ or C# or Python or Ruby or whatever, and you're going to sit there and whinge like a schoolgirl about "having to learn a new language"? Chrissakes. Just spend 2 or 3 hours learning it, everyone's happy and guess what, as a bonus you've got one more bullet point for your resume.
And yes, if your designer deletes code, then your designer sucks and needs replacing with a better one, don't just stereotype the entire designer role. We're not all like that. In fact, to be honest, I've barely met any web designers who don't dabble in at least a little bit of PHP/ASP/Perl/whatever.
And yes, tal will let you colour alternate rows easily.
Yikes, that designer sounds like a nightmare to work with.
I myself am a designer, and I often run into the opposite problem: developers inserting nasty old broken HTML into my carefully-laid-out templates. It's not that I can't work with their jsp and php files, it's not that I don't have the time to do whatever it is that needs doing. Usually, it's just that they're in a hurry and don't bother to ask me to change or add something. Then I see the final app running one day and wonder what the hell happened.
(To be fair, though, the guys I worked with who did this have moved on to other jobs now.)
Your fantasies contain the seeds of important concepts.