Modules of Content Management Systems and their Reusability

Transcription

1 Modules of Content Management Systems and their Reusability Michal JAKUBÍK Slovak University of Technology Faculty of Informatics and Information Technologies Ilkovičova 3, Bratislava, Slovak republic Abstract. There are a lot of theories about reusability of parts of information systems. Narrower sphere of reusability of software components is websystems module reusability and concrete using done modules of content management systems. And where are the bounds of using components with content management systems? What are advantages and disadvantages of reusability components of CMS to generate front end designs and how to prepare component to make it easy to reuse. All these questions are very subjective and not easy to answer. 1 At the beginning In the context of reusability we should distinguish reusability in websystems and websites. When you are creating website, first thing you have to create for your customer is a graphic layout. In this phase your client says OK, start working. Now begins phase of your developers. There are two possible views of reusable templates. Graphic template and its reusability is a little bit hard to reuse, because every costumer wants to have original layout and original styling of his website or intranet websystem. Supervisor: RNDr. Valéria Šimáková, Institute of Informatics and Software Engineering, Faculty of Informatics and Information Technologies STU in Bratislava M. Bieliková (Ed.), IIT.SRC 2005, April 27, 2005, pp

2 2 Templates Modules of Content Management Systems and their Reusability Programming template Programming template is something different. Here are modules that are always used and you can use this template every time and on every project. For example let s talk about menu. In every application there have to be menu. Without menu is the application and especially websystem unusable. Concerning to the website, simply said, the menu is listing of all available and accessible sites and subsites of your web. Fig. 1. Part of sitetree of website When you have more languages in your web, alternation of sites-listing in levels is required. When you created a complex template for creating the sitemenu you won. Because if in your complex template you separated generating front-end part (HTML code) and logical part - database queries and their processing, reusability of this module is finished. When you want to reuse this module you just copy logical part and front-end part will be changed and styled another way. The next example that is in CMS systems used very often. This module is news content part. The logical functionality is here nearly every time the same. Here is valid the first rule of reusability of modules separate front-end part from logical part. In modules like news or events there are sometimes needs to change logical or database part, because every costumer wants to store another data or a little bit other functionality. But mostly changes are not bigger than add one column into database and generate this column on front-end.

3 226 Michal Jakubík On every CMS site there you can always find module called sitemap. This module generates list of structured names of sites and subsites. Fig. 2. CMS sitemap module in default language In default language there are names in default language in this case there is German. But most of sites there are more than one default languages. On this site there are two languages. The second one is English. Fig. 3. CMS sitemap module in English This case is very similar to the module menu. The same is logical functionality, different is only HTML code. What will happen when we use the same module to generate menu and sitemap? The answer, in this case, is nothing. When our menu

4 Modules of Content Management Systems and their Reusability 227 module is done really completely, you have to create only a HTML class that calls logical part (classes) of module implementation. So the reusability of module is here completed twice. Because there are two functionalities in one project for nearly zero costs (the costs of reuse development). 2.2 Graphical template And what about development of graphical template of a website? The whole website in most cases we can shift into 4 parts. The top, menu (mostly on left site), the content part and footer. In the top there is a transcription image. When in the top part there is defined functionality then it is mostly only an image changer. The menu part is described by its name menu part. In the content we can find all information of the website and the footer is some kind of menu which is not included in menu part. This is word described graphic template of most websites. This is easy to implement in HTML with place holders of functionality. Fig. 4. Classic HTML template

5 228 Michal Jakubík Instead of place holders will be generated functionality. For example placeholder for menu module is <!-- ###MENU### -->. The CMS parser takes the template and these places will be replaced with code which is generated by module. If we want to create another project with the same layout (not styling) we will use this template and the only thing to change will be css file and the top image. This way is cheaper than to create a new HTML code for whole template and we are 100% sure that the old template was optimized for alternate browsers. 3 Conclusions Finaly the result is that the well made template is useable every time. Possibly one template is useable in one project twice or more times. Functionality of one module can be used more than once. The best case is when the template is made complex and universal and the possibility of resell to another costumer is high. Difference between programming template and graphical template is only in multitude of usability. You cannot use one graphical template in one project more than once. So why don t we reuse components by websystems too? It spares time and money. References 1. Cohen, M.: Typo3 Template Basics Skårhøj, K.: Modern Template Building (Part 1) Part_1.pdf 3. Skårhøj, K.: Modern Template Building (Parts 2 and 3) Part_2-3.pdf 4. Skårhøj, K.: TypoScript reference