![]() |
Help | ![]() |
![]() |
One of the strongest features of In-link is that it is completely template-based, meaning that the entire engine's look and its output for the front-end users can be modified, customized and integrated into any web site. In simple words, you can take In-link and in less than one hour you could easily make it look like a part of your web site. In-link has built-in template editors that allow you to modify any visual element of the engine. In fact, In-link templates are so flexible that you can create your own template files, have nested templates, declare your own tags, i.e. customize the output in any way or form. In-link template engine goes even beyond standard headers and footers functionality; In-link themes even support Macromedia Dreamweaver templates. Customizing a program's output has never been any easier.
In-link's templates even support PHP in them, along with JavaScript and any HTML tags. The parsing engine features caching that significantly improves the performance of the entire system. In-link's new template parsing engine has earned a wide recognition as a revolutionary solution for web-based products.
In-link's front-end consists of a set of templates (located in “themes/” on your server in the In-link’s directory) called a theme. The themes are stored in sub directories of the theme folder. The name of the folder a particular theme is stored in is the name In-link will use in addressing the theme in the system. With the use of themes, the Administrator may easily change the front-end look, feel, and functionality by specifying the theme in the admin interface.
Themes are sets of template files and a cascading style sheet file that can all be edited in any text editor or by using the In-link’s built-in editor. The themes are located in "themes\" directory in your In-link directory. You can download new themes from our web site or add and modify your own. Just place them in their own directory under "themes\" and use the Administration Panel to switch between them.
Templates can be nested within each other and In-link does a recursion check to eliminate a possibility of crashing your system. Also, In-link caches frequently used templates for increased performance.
In-link’s In-tags are special tags that are located in template files and represent where the insertion of In-link’s dynamic output will take place. In another words, In-link parses the theme templates consisting of regular HTML and In-tags and replaces In-tags with dynamically generated values. The output represented by an In-tag could be anything from a link name, navigation menu, a page header or even an entire nested template inserted into the template in place of the In-tag.
In-tags consist of special single-ended markup tags, similar to HTML tags, except in the format: <%In-tag%>. The tags are organized into sets (e.g. links <%link_*%>, categories <%cat_*%>, navigation <%nav_*%>, etc., where “*” represents a logical element or a value of a link, category, etc. In-tag sets serve only as a mnemonic device; the set an In-tag belongs to does not effect how In-link handles the tag. In-tags come in one of two formats: Static In-tags and Variable In-tags.
See also: Appendixes | In-tag Dictionary
Format: <%tag_name%>
Static In-tags are predefined in the In-link system or in a module. Static In-tags usually insert a simple text block into the page (e.g. <%stats_hits%> will display the total number of link hits in the system)—however, some static In-tags will execute and insert more advanced output (e.g. <%insert_links%> will insert a block consisting of numerous links matching the link results for that page).
Some static In-tags are customizable in the admin utility. More advanced tags such as <%insert_links%> allow for greater customization.
See also: See also: Appendixes | In-tag Dictionary
Format: <%tag_type:parameter%>
Variable In-tags are not predefined in the system—only the tag type is predefined. (e.g. <%include:%> is defined in the system, however, the tag type with its parameter is not <%include:search%>
Variable In-tags are completely customizable. You have the ability create the content for the variable In-tag so you have absolute control over the functionality of the tag. The parameter sent to an In-tag varies with what tag type you are calling.
Includes the code from the parameter in place of the tag
Parameter is the name of the file to include without its extension
The files for this tag type must be in themes/currently_selected_theme
Example: to include search.tpl into an other file, the tag <%include:search%> should be used
Displays the contents of a desired language variable. The text displayed to the user depends on the current language pack selected.
Parameter is a PHP variable name from the language files
Example: to insert the message contained in $lu_error_404, the In-tag <%language:lu_error_404%> is used. If the Bulgarian language pack is currently selected, <%language:lu_error_404%> would display “Stranicata ne moge da bade otvorena.”
See also: See also: Appendixes | In-tag Dictionary
In-link's entire front-end is controllable via themes. Themes are located in “themes/currently_selected_theme”. The files in the directory are called templates and end with the .tpl extension. The contents of the template files vary with the type of theme you implement—with either theme style however the core structure is HTML. Templates may contain HTML, JavaScript, In-tags, or PHP source.
In-link ships with two themes: “default” and “Dreamweaver”. Both themes are just examples of how a theme system can be structured in In-link in order to meet all requirements for a site maintenance. Even though, there is no coded-in division for the type of themes, nor there are any limitations of what one theme type can do versus the other, we prefer to divide all the themes into two categories distinguishing different logic in their structures. One of the themes (default) is most likely to be preferred by a system administrator who is more comfortable working from a telnet session and a notepad, who appreciates the power of updating one header in a template and having dynamically updated layouts in the entire system. The second theme “Dreamweaver” is more likely to be preferred by someone who is more familiar with WYSIWYG editors such as Dreamweaver, who would prefer using Dreamweaver libraries and templates and would allow Dreamweaver do the job of updating multiple files.
This is a theme where all the templates are structured using the include tags for headers, footers and other elements that can be nested. The default theme is structured around a base template for each of the pages (index.tpl, add_cat.tpl, mod_link.tpl, etc.) and then includes for common code segments (search.tpl, user_menu.tpl, login.tpl, etc.). This theme
This theme has the advantage that the Administrator may use the template editor in the admin utility to make a change to a template that will affect any page that includes it—however, if the admin wants to design a theme in this style using a WYSIWYG editor, the page must be broken into multiple template files and will no longer be visually editable.
This is a template set structured for use in a WYSIWYG editor and utilizing Dreamweaver templates and libraries. The Dreamweaver theme is designed for editing in Macromedia Dreamweaver 4. All pages are structured around a Dreamweaver Template (See Dreamweaver’s documentation for more on Dreamweaver Templates, Library Items) with internal HTML for each page’s unique content and included Library Items for reused elements. Templates in this format have the advantage of being fully editable within a WYSIWYG editor — however, if a reused element such as the search box needs to be changed, the templates must either be taken local and edited using Dreamweaver’s Libraries, or each page that uses that element must be changed in the template editor.
This is an alternative template set containing minimum number of features and layouts. This theme is probably the best theme for learning In-link or for putting together a small In-link driven site quickly. Although, some of the more advanced interfaces and functionality is not included in this theme, it can always be added later, when you are more accustomed to working with In-link themes.
Language sets are contained in the "languages\" directory of the In-link installation. The entire system output is located in centralized language files and can be easily edited in any simple text editor or built-in In-link language file editor. You can easily modify any system messages in the sets or even create your own language sets. You can even change the browser language encoding for the entire system. Additional language sets are available for download on the In-link site.
Modules allow for the easy addition of new functionality to In-link. Modules can extend the functionality of your entire In-link system my allowing you to use custom tags in the templates. Adding this extra feature that your web site needs can be now done without having to modify any of the existing code. Just upload a new module to the “modules\” directory in your In-link directory and it will be automatically configured for the use with the system.
! Use extreme caution with modules and please use them at your own risk. Modules have access to all In-link system variables and routines and they must be written in a compatible and compliant format in order to work properly. Do not download and install modules from a source you don’t trust as they can potentially represent a security risk for your site. All of the modules distributed by Intechnic Corporation routinely undergo tests and security checks; other modules may not.
In-link supports full integration into Macromedia Dreamweaver 4. Using Dreamweaver In-link Templates (tpl) differs from the standard In-link Templates in many ways. The most distinct difference is that all tpls are fully compiled and are fully editable in a WYSIWYG method (the only exception is the insert In-tag, these do not display as compiled code, but instead as an ASP tag).
Dreamweaver tpls have the benefits of easy modification within the Dreamweaver environment, reduction on server load, and remain updateable in a fashion similar to the standard tpls.
In order to use Macromedia Dreamweaver 4’s ability to update links automatically, library items, and templates, the user must first configure the Extensions.txt file.
1. Locate Dreamweaver’s configuration directory. This is in ”c:\Program Files\Macromedia\Dreamweaver 4\Configuration” on Microsoft Windows by default—however, your mileage may very.
2. Open Extensions.txt in the configuration directory.
3. You will see a file similar to this:
HTM,HTML,SHTM,SHTML,STM,SSI,JS,XML,LBI,DWT,ASP,CFM,CFML,TXT,PHP,PHP3,PHP4,LASSO,JSP:All Documents
HTM,HTML:HTML Documents
SHTM,SHTML,STM,SSI:Server-Side Includes
JS:JavaScript Documents
XML:XML Files
LBI:Library Files
DWT:Template Files
CSS:Style Sheets
ASP:Active Server Pages
CFM,CFML:Cold Fusion Templates
TXT:Text Files
PHP,PHP3,PHP4:PHP Files
LASSO:Lasso Files
JSP:Java Server Pages
4. “,TPL” must be added to the first line and the end of the list of extensions—but before “:All Documents”
5. Your line should now look like this:
HTM,HTML,SHTM,SHTML,STM,SSI,JS,XML,LBI,DWT,ASP,CFM,CFML,TXT,PHP,PHP3,PHP4,LASSO,JSP,TPL:All Documents
6. “TPL:In-link Template File” must be added on a new line at the end of the file.
7. Your completed Extensions.txt file should now look like this:
HTM,HTML,SHTM,SHTML,STM,SSI,JS,XML,LBI,DWT,ASP,CFM,CFML,TXT,PHP,PHP3,PHP4,LASSO,JSP,TPL:All Documents
HTM,HTML:HTML Documents
SHTM,SHTML,STM,SSI:Server-Side Includes
JS:JavaScript Documents
XML:XML Files
LBI:Library Files
DWT:Template Files
CSS:Style Sheets
ASP:Active Server Pages
CFM,CFML:Cold Fusion Templates
TXT:Text Files
PHP,PHP3,PHP4:PHP Files
LASSO:Lasso Files
JSP:Java Server Pages
TPL:In-Link Template File
8. Save and close “Extensions.txt”
9. If Dreamweaver is open, it must be restarted.
10. Note that these steps do not require the addition of “.tpl” to the extensions list under File Types/Editors in the Preferences. Merely adding the extension in preferences will not allow link updating in Dreamweaver 4.
It is highly recommended that
“.tpl”
be added to the list of extensions to not be rewritten under Code
Rewriting in the Preferences.
It is important to make a distinction between the templates supported within Dreamweaver and the templates used by In-link. Dreamweaver Templates are files that end with a .dwt extension and are used by Dreamweaver to allow multiple web pages to use an identical design but contain different content and allow design changes to be applied to all pages that use the dwt. In-link Templates are files that end in a .tpl extension and are used be In-link to format the information from the In-link engine for presentation to a user. Throughout the Dreamweaver integration chapter, Dreamweaver Templates will be referred to as dwts and In-link Templates will be referred to as tpls to avoid confusion.
This section is meant only as a brief introduction to the dwt file format—if further information is required, please consult the Dreamweaver help file.
Dreamweaver’s template system consists on standard HTML with special HTML comments that Dreamweaver recognizes as editable sections in the format of <!-- #BeginEditable "templateName" --> and <!-- #EndEditable -->. When edited within Dreamweaver, the only section of the page that is editable is the text/code between the editable opening and closing tags. When a change is made to a dwt that other HTML files use, that change is applied to those HTML files as well. It is important to emphasize that the full code is present the HTML file—it is not linked to the dwt in any way other than the editable section tags.
This section is meant only as a brief introduction to the lbi file format—if further information is required, please consult the Dreamweaver help file.
The limitation to Dreamweaver’s template system is that all pages look the same sans the content. If a developer wanted to add an element (e.g. a navbar, a login box, copyright information) to some of the pages that use a certain dwt, but not all of the pages that use that dwt, he/she would have to add this information manually. If the developer then needed to make a change to that element, he/she would have to change each element manually. To overcome this limitation, Macromedia introduced Library Items (.lbi). Library Items contain a code segment that may be inserted into an HTML page (regardless if the page is based off a dwt or not) and remains easily updateable via Dreamweaver’s update engine. Library items contain only a code segment, when applied in a web page, they contain that code segment surrounded by <!-- #BeginLibraryItem "/path/to/library/folder/libraryFileName.lbi” --> and <!-- #EndLibraryItem -->. When an lbi is edited within Dreamweaver, all pages using that lbi are updated to reflect the changes made to the lbi.
When creating Dreamweaver-based tpls, though you are still creating tpl files—the content is wholly based on dwts and lbis. Rather than having a header and footer to establish a similar look to all your pages, you now use one (or more, if multiple page styles are needed) dwt to set the style of the pages. Rather than having a tpl file for elements that are not integrated into the dwt, you now have lbis that are integrated into you tpls and/or dwts.
Using a lbi in a dwt can have undesired effects and is only recommended for advanced users.
You’ve configured the Extensions.txt file, and now you want to start your first Dreamweaver tpl theme set—so now what?
A few special tpls are required for the insert In-tags. The following tpls are required:
list_links.tpl
top_links.tpl
pop_links.tpl
new_links.tpl
pick_links.tpl
search_links.tpl
mod_links.tpl
link_count.tpl
Once tpls have been created, do not edit the tpls in any other method than through Dreamweaver (including the admin utility). Aside from this, your new Dreamweaver tpls may be used in the same methods as standard In-link tpls. Further information on Macromedia Dreamweaver 4 may be obtained from http://www.dreamweaver.com.
Any templates may contain regular PHP code and even entire programs that will be parsed and executed by In-link. This also gives the ability to enhance the functionality of In-link directly from the template files. For more information on PHP, please refer to the official PHP documentation (http://www.php.net)
! By using PHP in your templates, similar to modules, you can access any system variables and routines which can be potentially dangerous. Please, use caution when including PHP in In-link templates.