On Sat, 2003-10-04 at 08:18, Terence wrote:
Bloody hell Rob, you've started me on another rant when I could be in bed ;)
*grin* glad to help out.
XSLT is a pain in the butt if you want to master it - particularly if you're going from imperative programming to declarative (maybe XPath is functional, but declaring templates is definately declarative) as many
My understanding, which could very well be incorrect, is that declarative and functional are synonymous and imperative and procedural are synonymous. Most of the literature I've read describes XSL as a functional language, and while XSL is not necessarily XSLT, it is most definitely a part.
From what I understand, procedural is a subset of imperative and functional is different from declarative but I may be wrong too. It's been a long time since I've read up on my theory. Let's just say that XSLT is very different to what us PHP dudes are normally used to ;)
PHP developers would be. It took me a good twelve months to "get it" (eg. use XPath filters and not <xsl:if/>). That didn't stop me from churning out some production applications using XSLT. You can learn the basics without mastering it and still find it plenty useful. I would argue that my XSLT skills still leave a lot to be desired, but mastery of it is still worthwhile persuing. Quite simply, XSLT has a lot of depth.
I also develop in Java and C# where I can re-use all my "template" knowledge since this knowledge is based on a standard. I plan on having a play with building web apps in C++ and Python if I get the chance (by porting the XAO concept). For the time being, it happens that I am more skilled with PHP so I will develop the XAO architecture and concept in PHP.
It's pointless splitting hairs over the capabilities/advantages of one templating language over another. If the idea of cross-technology compatability doesn't appeal to you enough to put the effort in to master XSLT, then don't master it. Everyone has their own style. XAO is for object oriented developers of XML-centric applications. I imagine it won't be everyone's cup of tea even for such a group.
Its the same reason I never bothered to master LISP. It isn't my cup of tea, generally it isn't most people's cup of tea :) But in all honesty when a project insists I use XSL(T) then I do.
<<warning: very personal opinion to follow...>>
If you *do* finally decide to master XSLT, you have to conclude that *any* other templating system is a complete/utter waste of time. (all
While this is a "very personal opinion" you state for others that "you have to conclude that ..." which changes the opinion from personal to a foredrawn conclusion of ubiquity.
exactly, and if I wasn't being so opinionated, I would not have the luxury of being so foredrawn about things. I'd have to take a more scientific and hence concervative view with adequate disclaimers declarations about the possibilities and dangers of being incorrect - like we both did about definitions of functional/declarative and imperative/procedural (pardon my bad grammar). Although I strongly suspect you're right since I don't always spend enough time on the theory.
I realise I made a mistake about assuming what "XSLT masters" will have to conclude being that I am no XSLT master myself. It was ambitious presumption based on the current trend of my experience with XSLT. And besides, it was a convenient foregone conclusion for my argument ;)
I thought I had granted myself a licence for this when I prefixed my opinionation disclaimer.
authors of ``yet another PHP templating system'', please try not to be offended). I'm not talking about features/functionality either (for which XSLT is more than adequate), I'm talking about sheer bothersomeness. ie. I'm fundamentally lazy and I couldn't be bothered learning "snazzy g.o.a.t. [proprietary] templaty goodness system" -- "crappy" or otherwise -- I don't care how fantastic it is. The reason why the PHP template has been re-invented so many times, is becuase there is something missing - IMHO, XSLT fits that gap more than "good enough". And since it is a standard, it will only get better -- it has a future. And that, my friends, it good enough for me (being that I am lazy and all).
This doesn't really affect me personally. My templating system is open source, I made it and released it without the intent of making money. While it has a business license it is only because if someone *is* going to profit from it, then consideration should trickle back to the developer. Without being argumentative, but rather to be descriptive, the reason I made my own templating system was because it satisfied my needs long ago (at which time I already had been exposed to XSLT) and by creating hooks to custom tags in PHP itself it lent itself to re-use much of the code I had already developed in PHP for one reason or another. Another reason is that by not crossing technologies too many times, it becomes much more reachable to the average "Joe" who may not have a clue about XSL, XSLT, or even the dependencies necessary to have it running in PHP (PHP didn't always bundle this technology from what I recall). Thus if Joe already knows PHP, what better way from him to at least jump into the foray of separating design from business logic with a minimal amount of effort. It took you 12 months to master XSL, some people don't have that luxury of time.
Code re-use is good. Ease of use is good. There are a lot of more than good templating systems out there (apparently around 80 since last count at that discussion thread).
One of the things about the whole XSLT vs proprietary templating systems debate is timing. There's no point arguing that people using non-standard templating systems in the past are somehow clueless. This [templating pattern] was the original killer app for the web. One of the coolest things you could do with a handy practical extraction report language was make a templating system to avoid the mundane regime that was programming to the CGI. Hence PHP was born and that's why we all love it so much.
Back on the issue of timing, XSLT is a relatively new commer, but as you pointed out, it's been with use for an adequate time now to justify adoption by the masses. It is my opinion, however, that we have moved on folks. XSLT represents a distinct and worthy evolution of the web programming paradigm. It is also my optinion that the depth of complexity in XSLT risks alienating would-be adopters. (Sorry Raditha). It is a risk - not a forgone conclusion. I, along with people like Raditha, would like to encourage web developers in general to have a little faith in standards that are our lot. We can either lament them, or leverage them. I believe our persuits will be more fruitful if we embrace them and leverage their position (as authorotative) to make all our lives easier. I would argue that it is a medium-to-long-term investment. I'll let people like Raditha argue that it is [also] of short-term benefit.
As it happens, XAO supports custom tags, but a savvy user will realise that using custom tags to expand into display logic is just downright stupid - it missing the point. Still, the facility is there to allow expansion of business logic. It seems to have CMS potential - I may be
Custom tags are not always used to expand business logic to display logic. Sometimes they are used to bundle multi tag display logic into neat little single tag display logic.
which is exactly how I was suggesting the "savvy" user would use this feature. It is also why I decided to include the feature in XAO (took me literally 15 mins to add -- including testing... the xpath version needs more testing).
More often than not, I have found JSP and CF users still mixing in the HTML and using custom tags for little more than HTML widgets. I know cos I also used to do it -- and spend plenty of time maintaining other people's code which also did it.
using it in the future "form controls" feature -- or I may decide it's crap and ignore it alltoegether :D The savvy user will always process the business payload with XSLT - hence maintaining pure separation of display logic.
IMHO the savvy user will do what is best for the task at hand.
indeed. and what people say about the savy user's practices in a macroscopic and global context isn't neccesarily mututaly exclusive.
> And while
XSLT is powerful, sometimes it's not the man for the job.
I prefer to say that it is sometimes a pain in the butt ;)
But I have a "warts'n'all" approach because the "all" is worth the warts. And in this case, the "all" includes those things like standards leveraging -- which is very high on the priority list for a lazy person like me who only could be bothered with one templating system. It's like having your cake and eating it too - well, most of it :)
Just like Java
is more powerful than PHP in many respects, it's not the right man for the job in much of what we do.
too right.
IMO, PHP has the highest usefulness-to-effort/cost ratio (when it's not bogged down in shitty APIs as is the case with it's XSLT extension).
not at all. I enjoy the opportunity to expound the virtues of community standards participation (and av a good "rant").Anyways I hope this isn't perceived as a flame or anything other than just a differing of opinions.
PS.
Stop teasing us and give us the link to your open-source solution. I may be able to poach some ideas for my open-source solution :)
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
