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. > 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. > 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. > 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. > 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. And while XSLT is powerful, sometimes it's not the man for the job. 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. Anyways I hope this isn't perceived as a flame or anything other than just a differing of opinions. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
