On Wed, Oct 30, 2002 at 10:52:06PM +0000, Lusercop wrote: > On Wed, Oct 30, 2002 at 02:07:12PM +0000, David Cantrell wrote: > > Remember, all software sucks*. But to say that "embedding application code > > in markup leads to a poor (or non-existant) seperation of concerned, > > typified by spaghetti code" is to talk bollocks. > > * - and absolutism in software sucks absolutely? > Erm. I'm afraid I don't agree, please explain how embedding application code > in page rendering information can *not* lead to a lack of separation between > the two.
I would argue that seeing that the presentation is part of the application, then the code in the presentation is part of the application code. This is regrettable, but unavoidable. It should of course be kept to a minimum. But you'll do that anyway so that you can have interchangeable interfaces such as a web interface and a curses interface. Seperate the heavy lifting from the presentation by all means. That's a Good Thing. > I'm not quite sure what your definition of "spaghetti code" is. But I include > in mine: chasing all over for the file containing the relevant module/method/ > function definition. Oh well in that case, any use of modules is spaghetti. There's at least six different places that I might find perl modules on this 'ere machine, with a completely stock installation of perl 5.6.1. > As I've argued above, I think your starting point, that "it's possible to > write non-spaghetti embedded templates" is actually flawed, due to what I > consider to be spaghetti code. Your definition would seem to be flawed, as above, and would in fact lead to the conclusion that introducing what seperation we can between logic and presentation is a bad thing. > In your examples, such things as "where does > this hash get initialised" are important, and are then "spaghetti" in terms > of following them. It was a trivial snippet, not a full application. I can't be bothered to post a full application, which would show the data coming from elsewhere. > What Tim is saying, and FWIW, I think I agree with him on this, is "use the > right tool for the job". Excellent. My problem is that the "business logic" gives me this 'ere data structure, and it needs to be displayed prettily. I know, I'll use the Practical Extraction and Reporting Language. Sounds like the ideal tool for the job. > It's very easy to say "well, my way solves the > problem of chopping up the carrots", and it does, however, it's not in the > long term the best way of doing things. In the same way, using a templating > system which properly separates code and data will help you in the long run, > though it be more effort in the short, but you will get yourself into trouble > if you don't. Actually, I don't recall it being any effort in the short term either. Creating the tiny templating system was no more work than a simple CGI of the same sort of size. FWIW, it's 49 lines of code, including comments, and is not limited to HTML. -- Grand Inquisitor Reverend David Cantrell | http://www.cantrell.org.uk/david Considering the number of wheels Microsoft has found reason to invent, one never ceases to be baffled by the minuscule number whose shape even vaguely resembles a circle. -- anon, on Usenet
