Rehabilitation XML / XSLT Technologies
Hello, Habr. Some time ago we implemented in our CMS, along with our own template engine, which was already available by that time, also XSLT. Because there are great and real advantages in XSLT for developers, studio owners, and even site owners. But the reaction of our partners was divided into opposing opinions: some had been waiting for this for a long time and were glad of the appearance of such an opportunity, others questioned the relevance of XSLT, citing poor performance as an argument, which allegedly entails using XSLT.
It is clear that everything new always has supporters and opponents, and their time will judge them. Therefore, there was little point in unleashing a XSLT vs tpl or Smarty religious war at that time. But we found that it turns out that one of the leaders of the Russian CMS market with enviable persistence writes and writes everything about the alleged insolvency of XSLT as a mass technology and is ready to consider it only in the context of specific tasks. This negatively affects the minds of some uninitiated developers about XSLT.
On the other hand, the recent major European IT exhibition CeBIT showed us that the majority of serious Western CMS (both box and internal platforms) use XML / XSLT as a single unified standard. Still, the Russian IT market is slightly slower than the western one in terms of the speed of introducing new technologies. Against this background, to say that XSLT sucks, as long as the whole world uses it, is not very useful and correct.
')
Therefore I, having registered on Habré, I will begin with attempt of rehabilitation of unfairly offended XSLT. In my opinion, the responsibility of the CMS market participants is just to promote modern technologies and be a kind of technological flagships. And do not discredit them, even if you did not manage to implement them or do not like them. You can not read those who already know about XSLT or even use. This article is for those who are not yet in the subject or in doubt. Those who do not agree - please do not arrange holivar. Everyone has the right to express their opinions.
All the technological advantages of XSLT are based on the core concept embedded in it - the complete separation of business logic and presentation logic. Mixing models of representation and models of business logic is the programmer’s deadly sin. And only a person with very low qualifications will not agree with this. At the same time, for example, the rather popular Smarty template engine, not only allows you to implement business logic in the template, at the presentation level, but also pushes the developer to this, tempting him with a quick solution of the momentary task. What this will lead to later is an unstructured chain of relations between templates and scripts, which grows like a snowball and eventually becomes uncontrollable. As a result, a change, for example, of a single method that is used in a template, will cause the entire template to “fall”.
Any expansion tasks become comparable to “writing from scratch” even for the developer who initially led the project. Not to mention that it becomes impossible to transfer this project to another developer. Thus, the advantages of using an alienable CMS can be partly leveled using Smarty, since in a complex and even more unusual implementation it makes the created project inalienable from its developer. A change of developer in most cases will mean that “rewriting from scratch”, which, paradoxically, in this case will be more profitable than the labor costs for studying the “alien” code. Obviously, this decision is not optimal, and will entail the next batch of quite substantial financial injections.
Therefore, it is not necessary to talk about the low cost of ownership of a serious project created using such a template. Of course, if the project is small, there are no changes in developers, or you need to quickly make and forget - Smarty is more suitable.
It is also necessary to note the “fool-proof” vulnerability, if Smarty is used in the CMS - a low-level implementer “using” Smarty can easily write a query to the database directly in the template and crash the entire system.
An important characteristic of CMS native tpl template engines is their individuality, since in most cases, they are written for each specific CMS. Each individual template requires a preliminary study from the implementer, and this increases the cost of development.
As a result, Smarty in practice shows itself to be simple, customary, but not very flexible, inextensible, poorly alienable from the developer, and also potentially unsafe. These shortcomings always accompany the confusion of business logic and data presentation model. And from this point of view, Smarty and others like it are the antithesis of XSLT technology, which, in fact, was created in order to eliminate all these shortcomings.
Technology reliability
1) XSLT is a long-established industry standard supported by the W3C. It is developed by a large team of professional developers. The technology is constantly improved and updated due to quality support. All over the world, XSLT has long been perceived as a typesetting standard, in Russia it is used on such large projects as Yandex, Moy Krug and others.
Security
2) The strict separation of business logic and data presentation model will under no circumstances allow the coder to “kill” the entire system if he has access only to templates.
Flexibility
3) XSLT allows you to reuse the results of work already done. Once a template that has been installed on XSLT, it does not keep the functionality of business logic and its development on it, so it is freely scaled and transferred to other projects.
4) For typical operations, it is enough to create a template only once and use it from project to project. An example from practice: a partner studio received an order to develop 3 sites of a car dealership for various brands of cars. The creation of the first site took about 2 months, the second site, taking into account new improvements, was developed in 1 month, the third site was raised in 2 weeks. Due to the fact that the technology itself has already been done, the sites need only be “decorate” (ie, change the design). Once a problem is solved, next time it takes 2-3 times less time, even with the introduction of new functions.
Availability, clarity, low cost of development
5) In our experience, a coder familiar with only HTML and CSS, the development time of a project on XSLT from scratch will average about a month and a half. Moreover, if he is studying XSLT in isolation from other project tasks, he can master it in a week and a half. For comparison, the same layout designer can master the tpl-template engine of a specific CMS on average over a week, and mastering the project will take him the same month. But the XSLT maker-up needs to be mastered only once, and each individual tpl-template engine draws a separate study. Therefore, after the development of the first project on XSLT, we can talk about savings at the implementation stage.
Alienability
6) Any XSLT layout maker can recycle the alien XSLT template. The technology is standard, the transition from one developer to another is not a problem, which ensures the project’s alienability and significant savings in the cost of ownership of the project.
Extensibility
7) Editing an XSLT template does not involve intervening in business logic and analyzing the structure of relationships that could be used in a template if it were on Smarty. Therefore, for example, changes in business logic will not lead to the collapse of other patterns. This already has room for consistent expansion, since all links are structured and can be modified. Extensibility with this approach becomes much less labor-intensive, and the cost of ownership of the project again decreases.
With the current requirements of customers it is very difficult to submit a project that does not require further development and expansion in the future. XSLT is now the best standard that allows you to anticipate the development of the project and lay the possibilities for the future.
8) Some tasks solved in XML + XSLT simply and efficiently are represented as a minimum non-trivial without XSLT.
For example, using XSLT you can build decentralized services (in particular, the popular in the context of Web 2.0 mash-up), you can use to build cluster systems (of course, this does not apply to CMS). Sharing content with other resources based on XML-format allows you to use other people's services on your own website. Moreover, if this third-party service “falls”, then nothing will happen to the site - data can be taken from the cache for some time, and then this service may no longer be displayed for the rest of the site’s overall performance. The Smarty approach described above, due to the developed and unstructured connections, will contribute with a high degree of probability to “leg” along with the very third-party service and the entire site as a whole.
Native XML support
9) The abundance of XML data that you often need to use in a project is our reality. The XSLT template engine is a native parser for XML, and all other solutions are a bicycle.
Performance and speed
10) One of the “flaws” that some developers put in the “blame” of XSLT is that it cannot solve the problems of business logic. It is difficult to imagine a more absurd statement. In this sense, imposing a database on XSLT and requiring high speed is as absurd as playing a 5.1-disc drive through the speaker of a regular TV and at the same time requiring Dolby Surround. XSLT, by definition, does not have to do this; it was created only to implement a view. But the business logic should prepare the data that he needs to display the page. And if she prepares them, then the speed of XSLT questions can not arise, because you only need to transmit what will be displayed on the page (in most cases, 10-50 goods). If you make a complete transformation of the base for 10 thousand products into XML, and then apply the XSLT transformation to this, then the performance results will be very sad. The concept of separating business logic and presentation on which XSLT is based will be completely raped. It is not surprising that with the approach described by Sergei Ryzhikov, he will not show miracles of performance and speed.
Unfortunately, there are no ideal people / products / technologies. XSLT is no exception.
Debugging a template on XSLT, if it makes a mistake, may require the developer to make significant efforts to find and fix it. In this case, even any unclosed tag leads to the inoperability of the entire template. Therefore, XSLT requires special care from the developer, accuracy and attention to detail.
Another limitation on the mass use of XSLT in Russia is called by many a significantly higher wage level of the XSLT layout designer compared to the HTML layout designer. This is partly true, but in many ways the situation is artificially injected. At one time, the layout on divas was as exotic as XSLT now seems to many. But this did not prevent her from becoming widely used due to real advantages over tabular layout. And the shortage of specialists in marvelous layout quickly filled the market. Therefore, the emergence of XSLT-maker-ups is a matter of time, with the apparent superiority of XSLT over other existing template engines.
For a novice developer, dealing with tpl templates is often easier. But at a certain stage of the development of the project, the use of XSLT becomes justified from both a technological and an economic point of view. Therefore it is necessary to give developers a choice between tpl and XSLT. But developers themselves need to understand that progress is inevitable and the massive distribution of XSLT is a matter of time. The whole world went this way and should not be ignored. Therefore, the sooner developers begin to master XSLT, the more money they will earn in the future.
It is clear that everything new always has supporters and opponents, and their time will judge them. Therefore, there was little point in unleashing a XSLT vs tpl or Smarty religious war at that time. But we found that it turns out that one of the leaders of the Russian CMS market with enviable persistence writes and writes everything about the alleged insolvency of XSLT as a mass technology and is ready to consider it only in the context of specific tasks. This negatively affects the minds of some uninitiated developers about XSLT.
On the other hand, the recent major European IT exhibition CeBIT showed us that the majority of serious Western CMS (both box and internal platforms) use XML / XSLT as a single unified standard. Still, the Russian IT market is slightly slower than the western one in terms of the speed of introducing new technologies. Against this background, to say that XSLT sucks, as long as the whole world uses it, is not very useful and correct.
')
Therefore I, having registered on Habré, I will begin with attempt of rehabilitation of unfairly offended XSLT. In my opinion, the responsibility of the CMS market participants is just to promote modern technologies and be a kind of technological flagships. And do not discredit them, even if you did not manage to implement them or do not like them. You can not read those who already know about XSLT or even use. This article is for those who are not yet in the subject or in doubt. Those who do not agree - please do not arrange holivar. Everyone has the right to express their opinions.
XSLT, Smarty template engines and internal tpl boxed CMS.
All the technological advantages of XSLT are based on the core concept embedded in it - the complete separation of business logic and presentation logic. Mixing models of representation and models of business logic is the programmer’s deadly sin. And only a person with very low qualifications will not agree with this. At the same time, for example, the rather popular Smarty template engine, not only allows you to implement business logic in the template, at the presentation level, but also pushes the developer to this, tempting him with a quick solution of the momentary task. What this will lead to later is an unstructured chain of relations between templates and scripts, which grows like a snowball and eventually becomes uncontrollable. As a result, a change, for example, of a single method that is used in a template, will cause the entire template to “fall”.
Any expansion tasks become comparable to “writing from scratch” even for the developer who initially led the project. Not to mention that it becomes impossible to transfer this project to another developer. Thus, the advantages of using an alienable CMS can be partly leveled using Smarty, since in a complex and even more unusual implementation it makes the created project inalienable from its developer. A change of developer in most cases will mean that “rewriting from scratch”, which, paradoxically, in this case will be more profitable than the labor costs for studying the “alien” code. Obviously, this decision is not optimal, and will entail the next batch of quite substantial financial injections.
Therefore, it is not necessary to talk about the low cost of ownership of a serious project created using such a template. Of course, if the project is small, there are no changes in developers, or you need to quickly make and forget - Smarty is more suitable.
It is also necessary to note the “fool-proof” vulnerability, if Smarty is used in the CMS - a low-level implementer “using” Smarty can easily write a query to the database directly in the template and crash the entire system.
An important characteristic of CMS native tpl template engines is their individuality, since in most cases, they are written for each specific CMS. Each individual template requires a preliminary study from the implementer, and this increases the cost of development.
As a result, Smarty in practice shows itself to be simple, customary, but not very flexible, inextensible, poorly alienable from the developer, and also potentially unsafe. These shortcomings always accompany the confusion of business logic and data presentation model. And from this point of view, Smarty and others like it are the antithesis of XSLT technology, which, in fact, was created in order to eliminate all these shortcomings.
10 arguments for XSLT
Technology reliability
1) XSLT is a long-established industry standard supported by the W3C. It is developed by a large team of professional developers. The technology is constantly improved and updated due to quality support. All over the world, XSLT has long been perceived as a typesetting standard, in Russia it is used on such large projects as Yandex, Moy Krug and others.
Security
2) The strict separation of business logic and data presentation model will under no circumstances allow the coder to “kill” the entire system if he has access only to templates.
Flexibility
3) XSLT allows you to reuse the results of work already done. Once a template that has been installed on XSLT, it does not keep the functionality of business logic and its development on it, so it is freely scaled and transferred to other projects.
4) For typical operations, it is enough to create a template only once and use it from project to project. An example from practice: a partner studio received an order to develop 3 sites of a car dealership for various brands of cars. The creation of the first site took about 2 months, the second site, taking into account new improvements, was developed in 1 month, the third site was raised in 2 weeks. Due to the fact that the technology itself has already been done, the sites need only be “decorate” (ie, change the design). Once a problem is solved, next time it takes 2-3 times less time, even with the introduction of new functions.
Availability, clarity, low cost of development
5) In our experience, a coder familiar with only HTML and CSS, the development time of a project on XSLT from scratch will average about a month and a half. Moreover, if he is studying XSLT in isolation from other project tasks, he can master it in a week and a half. For comparison, the same layout designer can master the tpl-template engine of a specific CMS on average over a week, and mastering the project will take him the same month. But the XSLT maker-up needs to be mastered only once, and each individual tpl-template engine draws a separate study. Therefore, after the development of the first project on XSLT, we can talk about savings at the implementation stage.
Alienability
6) Any XSLT layout maker can recycle the alien XSLT template. The technology is standard, the transition from one developer to another is not a problem, which ensures the project’s alienability and significant savings in the cost of ownership of the project.
Extensibility
7) Editing an XSLT template does not involve intervening in business logic and analyzing the structure of relationships that could be used in a template if it were on Smarty. Therefore, for example, changes in business logic will not lead to the collapse of other patterns. This already has room for consistent expansion, since all links are structured and can be modified. Extensibility with this approach becomes much less labor-intensive, and the cost of ownership of the project again decreases.
With the current requirements of customers it is very difficult to submit a project that does not require further development and expansion in the future. XSLT is now the best standard that allows you to anticipate the development of the project and lay the possibilities for the future.
8) Some tasks solved in XML + XSLT simply and efficiently are represented as a minimum non-trivial without XSLT.
For example, using XSLT you can build decentralized services (in particular, the popular in the context of Web 2.0 mash-up), you can use to build cluster systems (of course, this does not apply to CMS). Sharing content with other resources based on XML-format allows you to use other people's services on your own website. Moreover, if this third-party service “falls”, then nothing will happen to the site - data can be taken from the cache for some time, and then this service may no longer be displayed for the rest of the site’s overall performance. The Smarty approach described above, due to the developed and unstructured connections, will contribute with a high degree of probability to “leg” along with the very third-party service and the entire site as a whole.
Native XML support
9) The abundance of XML data that you often need to use in a project is our reality. The XSLT template engine is a native parser for XML, and all other solutions are a bicycle.
Performance and speed
10) One of the “flaws” that some developers put in the “blame” of XSLT is that it cannot solve the problems of business logic. It is difficult to imagine a more absurd statement. In this sense, imposing a database on XSLT and requiring high speed is as absurd as playing a 5.1-disc drive through the speaker of a regular TV and at the same time requiring Dolby Surround. XSLT, by definition, does not have to do this; it was created only to implement a view. But the business logic should prepare the data that he needs to display the page. And if she prepares them, then the speed of XSLT questions can not arise, because you only need to transmit what will be displayed on the page (in most cases, 10-50 goods). If you make a complete transformation of the base for 10 thousand products into XML, and then apply the XSLT transformation to this, then the performance results will be very sad. The concept of separating business logic and presentation on which XSLT is based will be completely raped. It is not surprising that with the approach described by Sergei Ryzhikov, he will not show miracles of performance and speed.
On the disadvantages of XSLT.
Unfortunately, there are no ideal people / products / technologies. XSLT is no exception.
Debugging a template on XSLT, if it makes a mistake, may require the developer to make significant efforts to find and fix it. In this case, even any unclosed tag leads to the inoperability of the entire template. Therefore, XSLT requires special care from the developer, accuracy and attention to detail.
Another limitation on the mass use of XSLT in Russia is called by many a significantly higher wage level of the XSLT layout designer compared to the HTML layout designer. This is partly true, but in many ways the situation is artificially injected. At one time, the layout on divas was as exotic as XSLT now seems to many. But this did not prevent her from becoming widely used due to real advantages over tabular layout. And the shortage of specialists in marvelous layout quickly filled the market. Therefore, the emergence of XSLT-maker-ups is a matter of time, with the apparent superiority of XSLT over other existing template engines.
Findings.
For a novice developer, dealing with tpl templates is often easier. But at a certain stage of the development of the project, the use of XSLT becomes justified from both a technological and an economic point of view. Therefore it is necessary to give developers a choice between tpl and XSLT. But developers themselves need to understand that progress is inevitable and the massive distribution of XSLT is a matter of time. The whole world went this way and should not be ignored. Therefore, the sooner developers begin to master XSLT, the more money they will earn in the future.
Source: https://habr.com/ru/post/22018/
All Articles