| SitePoint Sponsor |
I said: "a PHP template ends up being more natural."Originally Posted by Tony Marston
I never said anything about not using templates - if you can point out what made you think that, then I'll try and clarify for you.
Then you should re-read my posts. I am saying that artificially introducing XSL slows down both.You seem to think that execution speed is more important than development speed.
Douglas
Hello World
Tony, can't you do your "reusable template" with let's say a PHP Based template.
I have not looked at your reusable template. But I guess you have one to show list for example and that template use a generic structure.
You could build a template in PHP and pass it a generic structure too.
Can't you? ;-)
(Of course XSLT has the best argument that you can use it with any language, if that is what you doing it is good and efficient in term of developpement time, however just answer if you see any problem redoing your thing with any kind of template system?)
You seem to be saying that using a templating system to generate HTML uses more machine resources than not using a templating system, and this loss of speed is not a good thing and should be avoided.
If it produces faster execution times to output HTML directly from each script, then why on earth do people use any type of templating system at all? The answer is speedier and therefore cheaper development. It is quicker to assemble the data and give it to a template to generate the HTML than it is to write your own code within each script to generate it. The fact that it takes slightly longer to execute is irrelevant if the execution times are acceptable.
I disagree. Configuring an XSL engine is a one-time operation, not something that each developer has to repeat time and time again. Creating the library of XSL templates is a one-time operation, not something that each developer has to repeat time and time again. Creating XML files and passing them to XSL stylesheets does not require any developer effort if the development infrastructure manages that automatically. It is an investment that will produce more benefits the more it is used and reused. It is an investment just like the creation of a development infrastructure. It allows the developers to spend most of their valuable time in coding the business rules, not the presentation logic.
Yes, there is a cost in runtime performance, but this is outweighed by a large saving in developer costs as well as shorter development times.
I probably could, but I do not have the time or the inclination for such an academic exercise. I have a set of templates that work, and work very well I might add, so I see no need in replacing them.
academic exercise? How'd you go about putting your data to the template... A positive, working example would strengthen your case and point of view, rather than simple (blindly I might add) that it can be done.
Just to make an off the cuff remark that it can be done is just being crazy. Anyone can make a claim of this or that, what we need is examples. I do not see any such examples on your website that doesn't use XSL.
Where is the prove huh? huh?
I'm not entirely sure that Tony needs to validate his claim by producing a PHP Template version of his XSL system to compare against, it would be as he suggests a rather academic process because we all know what the outcome will be (i.e. several magnitudes faster). But I don't believe he is disputing this, just merely saying that his current approach works for him - which it obviously does.
We may not all agree with the approach, but that doesn't make it wrong.
Personally I disagree with the argument of "too slow? buy more hardware" as that just smacks of not actually correctly scoping the project in the first place. I don't believe many of my clients would buy the excuse of "get another server" because I decided to use a method to create their site that was significantly more inefficient than it could have been. But I guess the smaller the system the less noticeable this is anyway.
As for why we don't all code our scripts in C rather than PHP, I honestly believe it's a common misconception that "C is always faster", that simply isn't true for all cases. My biggest issue with XSL as it stands now is that with a current PHP template system I can give the template to the designers and let them loose on it and get a nice working set of templates back again and the work is done. Add the extra time of converting that into XSL and you literally double the workload - and expecting the designers to have any grasp of XSL is, well.. sadly totally unrealistic, the tools just don't exist right now. Who knows, maybe in 4-5 years this will be a different scenerio!
I really have no interest in the template wars (and personally use several different systems depending on need). However I do want to note a few things about the quote above:If it produces faster execution times to output HTML directly from each script, then why on earth do people use any type of templating system at all? The answer is speedier and therefore cheaper development. It is quicker to assemble the data and give it to a template to generate the HTML than it is to write your own code within each script to generate it. The fact that it takes slightly longer to execute is irrelevant if the execution times are acceptable.
- The reasons that people use template systems are varied, but "speedier and therefore cheaper development" is not always the case. Allowing non-programmers to build/change the site presentation or allowing multiple "skins" are more usual reasons. Both of those often cause slower and more expensive development.
- It is not necessarily "quicker to assemble the data and give it to a template to generate the HTML than it is to write your own code within each script to generate it." In fact, using PHP as a scripting language only (eliminating separate controller and model) has consistently proven to be the fastest way to develop.
- I agree that "The fact that it takes slightly longer to execute is irrelevant if the execution times are acceptable." However, development time and execution speed are only two of many factors, including extensability, maintainablity, interoperablity, etc. that might affect design choices.
- As to "a PHP template ends up being more natural." I hear this argument from all sides: OOP is more natural, Procedural is more natural, PHP temeplates, HTML templates, XSTL, etc. etc. "Natural" really means what comes most easily to a person, and that depends on their programming background and depth of knowledge of the myriad of design methodologies.
- Developpement time is better, as functionnality is the most important thing. But there is case where time is important. If it takes 12 seconds to display, it is not acceptable in most case (unless it is a big report that play with a lot of data). But you said acceptable and that is bound to anything ;-)
- I have not asked Tony to code his reusable template in PHP, I was just trying to say with a question: "We can do reusable template in about anything, not just XSL".
In some cases being able to produce an application in 6 weeks is more important than waiting 6 months. If performance starts becoming a problem then you have to compare the costs of rewriting the software or adding in more hardware. If you can achieve the same speed increase by spending $1,000 on hardware or $5,000 on a programmer which would be more cost effective?
It is in most cases. You try writing a complex piece of functionality in PHP, then do the same in C and you will see a BIG difference. That is why the core functionality of PHP is written in C and not PHP itself. C code runs faster, bit it is more expensive to produce. PHP code is cheaper to produce, but provided that the execution time is acceptable it does not matter that it is slower. It is a simple matter of "how much speed are you prepared to pay for".
If a designer cannot code in XHTML and CSS then he/she is second rate. Designers have to keep up with modern trends, so if a designer cannot use XSL to generate XHTML from XML he/she is still with the dinosaurs.
Some designers can only work with WYSIWYG editors such as Dreamweaver. Ptui. They are next to useless (IMHO).
Nonsense. Their jobs are to design pretty things so that all my wonderful programming work doesn't look like it was designed by a programmer. I don't care if they use Photoshop or Dreamweaver or Notepad or MS Paint. I consider it MY job to make sure everything gets output as valid XHTML and CSS and reasonably-sized web-ready images. THe people who can design pretty things and the people who can wrangle XSL are not the same people (although I'm sure that there's a small intersection) and we shouldn't expect them to be.
You could do it in 4 weeks if you used PHP templates instead of XSL templates
HTML Code:<xsl:when test="$mode='read'> <xsl:choose> <xsl:when test="$item='T' or $item='t' or $item='Y' or $item='y' or $item='1'"> <xsl:text>Yes</xsl:text> </xsl:when> <xsl:otherwise> <xsl:text>No</xsl:text> </xsl:otherwise> </xsl:choose> </xsl:when>This doesn't show the code Tony had to write to convert PHP's true to 'T', 't', 'Y', 'y' or '1' before he sent it to his template engine. Without an intermediate XML stage, we have less coding to do.PHP Code:<?php if ($mode=='read'): ?>
<?php if ($item): ?>
Yes
<?php else: ?>
No
<?php endif; ?>
<?php endif; ?>
Douglas
Last edited by DougBTX; Jan 23, 2005 at 16:19.
Hello World
Has anyone had any real experience with letting the browser perform the xslt transformation? You send an xml file containing xml-stylesheet instruction and let the browser do the work.
An obvious downside is that only certain browsers support xslt processing and, among the ones that do, I am sure there are compatibility issues.
On the other hand, offloading the template processing to the client could reduce server load considerably. Furthermore, sending only the xml data seems like it might reduce the amount of data actually transferred which again would reduce server load.
Just wondering if anyone has tried this in practice.
If you want to give it a try, you can take a look here: http://www.w3schools.com/xsl/xsl_browsers.asp
I still tend to supporting IE 5.5 where this won't work so well (in the examples you'll see IE6/Mozilla links and IE 5 links) but if you only need to support IE 6 it might work. Whether you get any benifit or not... I can't really see any. If you needed an XML stream (RSS for example) anyway, then there may be an argument for attaching an XSL style sheet, but even then just some CSS would probably be enough for most needs.
You might get faster server side performance, but remember that the user will have to download your XSL too now. Whether that cost makes up for the performance gain server side, I don't know.
Douglas
Hello World
But that would happen just once.You might get faster server side performance, but remember that the user will have to download your XSL too now. Whether that cost makes up for the performance gain server side, I don't know.
There certainly is. Mozilla and IE are the only real players in that field at the moment, and they have their differences.An obvious downside is that only certain browsers support xslt processing and, among the ones that do, I am sure there are compatibility issues.
Don't even go down that route. If you thought browsers had trouble with CSS differences, wait until you see them try and parse XSL. It's an absolute nightmare.Has anyone had any real experience with letting the browser perform the xslt transformation? You send an xml file containing xml-stylesheet instruction and let the browser do the work.
$5000 on the programmer, because throwing the extra money at the hardware doesn't get rid of the root cause of the problem which will grow exponentially as the site increases in use.In some cases being able to produce an application in 6 weeks is more important than waiting 6 months. If performance starts becoming a problem then you have to compare the costs of rewriting the software or adding in more hardware. If you can achieve the same speed increase by spending $1,000 on hardware or $5,000 on a programmer which would be more cost effective?
Our designers are paid to do wonders with Photoshop, not XSL. This isn't going to change any decade soon and nor should it.Some designers can only work with WYSIWYG editors such as Dreamweaver. Ptui. They are next to useless (IMHO).
xml may have it's problem (speedwise and memory consumption) but afaik it is the only widely supported interface between coders and designers.
tools to generate xml are available in every self-respecting environment, this way the coders can generate it without too much pain.
on the other side the designers only have to learn 1 template language and can focus on what they can do best: design (doesn't matter if they do it for the php or the java division). There are even wysiwig editors that support xml/xsl.
For me, that's just gross. I have yet to see a good excuse for this overhead.xml may have it's problem (speedwise and memory consumption)
we're obviously in 2 camps:
the ones that think it's worth the overhead.
the ones that don't think it's worth the overhead.
time will tell who is right.
(could write things about programmers moving from assembler to c and operatings system that only ran on a specific platform but won't draw that parallel.)
Just to throw something in, why do the largest organizations use XSL? WallStreet, BBC, Adobe, Microsoft, MTV, Disney?
Most current PHP templating solutions are not feasible in a clustered load balanced environment, now to beg the question, why go for an XSL based templating solution? With effective caching aspects as mentioned above are pretty insignificant.
Off Topic:
Just to fuel the debate
Can you point out some links to where they use it, if at all?
I'm betting the only time they expose XML/XSL is when they have no control over what is done with the data, whether between teams or between companies. If you have control over where the data comes from, and where it goes, the best bet would be to take the most efficient technology and use that. If you don't, the second best option is to use a technology which everyone has access to, here, XML.
In a heavy load environement, you would want to cache as much as you can anyway. For things that you don't cache, you would want the processing to be as efficient as possible. As above, if you have full control over the proccessing, you are not forced to use slow XML systems.
Douglas
Hello World
XSLT on Wall Street
Content management at Ministry of Sound (I beleive this is XSL based, been- a while since I read it)
BBC, I was reading about yesterday, after receiving an of email of a prospective position, they bought a company that developed the system in C, shame I cannot recollect the URL, however the system requirements were four clustered servers? Including a Proxy Server for content cache.
Adobe
MTV you'll have to take my word for it, as i'm currently developing their internal site and its currently running on clustered enviroment utilizing PHP5. (PHP5 was their request).
Microsoft (I'm too lazy to find the other references)
Disney started an open source initiative, although a quick search cropped up with syzygy. The origional was a java implementation, although this is going back a couple years from when I last looked.
I'm not sure I quite follow what you mean with the following statement. However it entirely depends on your definition of efficiency, or rather the definition of the projects definition of efficiency. These are entirely different matters, whether performance is an optimal factor, extensibility, or other factors. As I lightly mentioned current templating systems did not fit for MTV, current caching systems did not fit the requirements either.
Just curious why you don't have full controll over the processing? Why can't you use fragmented XML documents?
Perhaps replace "control" with "responsibility" in my last post.
If a script is responsible for getting data from a database to HTML, then that's what it should do, not generate XML in the middle somewhere. If the script is just responsible for getting data out of the database so that other scripts can convert the data into HTML, PDF, etc, then yes, XML is "the standard".
My reading of the thread so far has been that we are talking about the first case rather than the second - though even with the second case, you still have the issue of generating the XML. In the general case, I would say that a script geared to generate XHTML using PHP templates could easily be converted to one which generates arbitery XML just by swapping out templates. If YAGNI applies, starting off using PHP templates to generate XHTML will keep it simple, and if you need to extend it to talk with non-web-browser XSL clients, that will work too
Douglas
Hello World
I also enter the ring and say that Dell at one point used XML/XSL on their site. This was a few years ago and who knows what they use now. In any case I have a book that actually talks about several XML technologies (can't think of the name off the top of my head, I can tell you when I get back home though) in the back they did several case studies of software that leveraged XML technologies and Dell's CMS for their site was listed as one that uses XSL.
A few other comments, I think XSL is an appliable technology, the base of knowledge isn't quite as large for it however so on the average it is a little bit more expensive for companies to use. However for companies with deep pockets and lots of hiring power it is definantly a viable (and apparently used?) option. I doubt that I would recommend the local pizza shop to use an XML based site, chances of a developer local to my area that could refactor or change the code would be slim and I think alot of other people here are in the same situation. It shouldn't be discounted though.
Also, saying that a designer that doesn't know how to use XSL is useless is somewhat silly. It's about the same as me saying a programmer that hasn't read PoEAA is useless. Which I don't think is true either.
Mike Lively
Digital Sandwich - MMM MMM Good
Off Topic:
I'd say "a programmer who hasn't heard of PoEAA probably only knows basic OO."It's about the same as me saying a programmer that hasn't read PoEAA is useless
"Useless" is too far imo, you could always task them to convert flat HTML into XSL templates
Hello World
I second that, but I'll add that it's also silly to discount XSL on the basis that it's too difficult for designers to learn. I worked as a developer for a small shop where we had only one designer. He's a whiz with photoshop, but we never pigeon-holed him as a guy who should be protected from the scary world of XSLT, much less application code. Granted, we're a bit of a special case (as is the designer)...being a small shop almost requires the tech staff to have overlapping responsibilities. In fact, I have yet to work in an atmosphere where there are people exclusively devoted to photoshop, html/css/javascript, php/asp, sql, or system admin.
Like every other technology, proper use depends on proper expertise. If you have a designer or team of designers who choke on their tongues when asked to learn something new, then XSLT probably isn't something you want to invest much time/money in. On the other hand if you have some reasonably intelligent designers who are willing and able to pick up new technologies, then the familiarity barrier can easily be overcome. Of course this assumes that XSL was a reasonable choice of technology in the first place.
I squirm everytime I hear someone say "XSL is too hard for designers". I'll concede that there are many designers who DO rely heavily on such tools (I assume launchcode meant WYSIWYG tools), but all designers are not created equal. Not all designers will perish without a graphical tool to rely on. The best are quite effective at both creating pretty pictures and hacking out straight HTML, CSS, javascript, and even XSL.
Posting Permissions
Bookmarks