SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 93

Thread: Xsl Xslt

  1. #26
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    But it was you who stated that because it seemed to take longer to produce XHTML output by using a templating system
    I said: "a PHP template ends up being more natural."

    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.

    You seem to think that execution speed is more important than development speed.
    Then you should re-read my posts. I am saying that artificially introducing XSL slows down both.

    Douglas
    Hello World

  2. #27
    SitePoint Enthusiast MickoZ's Avatar
    Join Date
    Jul 2004
    Location
    Canada, Qc
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?)

  3. #28
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    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.
    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.

    Quote Originally Posted by DougBTX
    You seem to think that execution speed is more important than development speed.
    Then you should re-read my posts. I am saying that artificially introducing XSL slows down both.
    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.

    Quote Originally Posted by DougBTX
    XSL doesn't save developer time or designer time, and results in an objectively weaker performing application.
    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.

  4. #29
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MickoZ
    Tony, can't you do your "reusable template" with let's say a PHP Based template.
    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.

  5. #30
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  6. #31
    SitePoint Addict launchcode's Avatar
    Join Date
    Dec 2004
    Location
    Bristol, UK
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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!
    Richard Davey

    Launchcode
    PHP Security Guide. Think your scripts are secure? Think again.

  7. #32
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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 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:

    - 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.

  8. #33
    SitePoint Enthusiast MickoZ's Avatar
    Join Date
    Jul 2004
    Location
    Canada, Qc
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    - 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".

  9. #34
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by launchcode
    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.
    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?

    Quote Originally Posted by launchcode
    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.
    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".

    Quote Originally Posted by launchcode
    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!
    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).

  10. #35
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Parry Sound, ON
    Posts
    725
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    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.

  11. #36
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    6 weeks
    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>
    PHP Code:
    <?php if ($mode=='read'): ?>
        <?php if ($item): ?>
            Yes
        <?php else: ?>
            No
        <?php endif; ?>
    <?php 
    endif; ?>
    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.

    Douglas
    Last edited by DougBTX; Jan 23, 2005 at 16:19.
    Hello World

  12. #37
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    692
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    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.

  13. #38
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  14. #39
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    But that would happen just once.
    An obvious downside is that only certain browsers support xslt processing and, among the ones that do, I am sure there are compatibility issues.
    There certainly is. Mozilla and IE are the only real players in that field at the moment, and they have their differences.

  15. #40
    SitePoint Addict launchcode's Avatar
    Join Date
    Dec 2004
    Location
    Bristol, UK
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    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.

    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?
    $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.

    Some designers can only work with WYSIWYG editors such as Dreamweaver. Ptui. They are next to useless (IMHO).
    Our designers are paid to do wonders with Photoshop, not XSL. This isn't going to change any decade soon and nor should it.
    Richard Davey

    Launchcode
    PHP Security Guide. Think your scripts are secure? Think again.

  16. #41
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  17. #42
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Parry Sound, ON
    Posts
    725
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    xml may have it's problem (speedwise and memory consumption)
    For me, that's just gross. I have yet to see a good excuse for this overhead.

  18. #43
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.)

  19. #44
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by HardCoded
    For me, that's just gross. I have yet to see a good excuse for this overhead.
    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

  20. #45
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Andrew-J2000
    Just to throw something in, why do the largest organizations use XSL? WallStreet, BBC, Adobe, Microsoft, MTV, Disney?
    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

  21. #46
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    Can you point out some links to where they use it, if at all?
    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.

    Quote Originally Posted by DougBTX
    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.
    Just curious why you don't have full controll over the processing? Why can't you use fragmented XML documents?

  22. #47
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Andrew-J2000
    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

  23. #48
    SitePoint Enthusiast mjlivelyjr's Avatar
    Join Date
    Dec 2003
    Location
    Post Falls, ID, US
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  24. #49
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by mjlivelyjr
    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.
    I'd say "a programmer who hasn't heard of PoEAA probably only knows basic OO."

    "Useless" is too far imo, you could always task them to convert flat HTML into XSL templates
    Hello World

  25. #50
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mjlivelyjr
    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.
    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.

    Quote Originally Posted by launchcode
    ...expecting the designers to have any grasp of XSL is, well.. sadly totally unrealistic, the tools just don't exist right now.
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •