Customising a block template, for different circumstances
----------------------------------------------------------------------------------------

Composr has a concept called a 'block'. Blocks are essentially building blocks that can be inserted into a Comcode page in order to add the aforementioned interactive and date-bound functionality that is so important to a modern website. Templates are the HTML file that determines the template of a page. Thus a page in Composr site is the comcode page with templates incorporated in it. In Composr templates are also defined as blocks , thus we can make use of it in different comcode pages and which provides re-usability of the code. This block concept help us to make use of a template block in different looks in different context. The easiest way to do this is by using 'SET' symbol of tempcode. In Composr there is a separate language for the template coding which is called tempcode. Thus for doing effective editing to the template we need to know the tempcode.

Let's set up a contrived situation just to make the explanation simple...

Let's imagine on a Comcode page we are displaying the main_quotes block twice, and it should look different each time. We could do it like this...

{$SET,main_quote_display_method,A}[block _="A"]main_quotes[/block]{$SET,main_quote_display_method,}
{$SET,main_quote_display_method,B}[block _="B"]main_quotes[/block]{$SET,main_quote_display_method,}

This puts a setting in 'main_quote_display_method' to identify our "display method", and unset it after the block is called. The pattern repeats for each display of the block.

We had to do a little fudge with the _="A" and _="B" stuff. This is to stop Composr internally caching the block's displayed Tempcode into a single unit while it is generating the page. All we have done is set a non-existent parameter ("_") to a different value each time to cause Composr to not try and optimize things for us. We could have actually used any random parameter names and values, there's no real relationship with the values we stored in main_quote_display_method.

And then alter the BLOCK_MAIN_QUOTES template like...

{$GET,main_quote_display_method}

{+START,IF,{$EQ,{$GET,main_quote_display_method},A}}

<strong>Random quote:</strong> {CONTENT}

{+END}

{+START,IF,{$EQ,{$GET,main_quote_display_method},B}}

{CONTENT} (our random quote)

{+END}

{+START,IF,{$NEQ,{$GET,main_quote_display_method},A,B}}
<section class="box box___block_main_quotes"><div class="box_inner">
{+START,IF_NON_EMPTY,{TITLE}}<h3>{TITLE}</h3>{+END}

<blockquote class="quotes_block">
{CONTENT}
</blockquote>

{+START,IF_NON_EMPTY,{EDIT_URL}}
<ul class="horizontal_links associated_links_block_group">
<li>{EDIT_URL*}</li>
</ul>
{+END}
</div></section>
{+END}

We have latched onto the value of main_quote_display_method, providing different output if it has values 'A' or 'B', or the normal Tempcode for the template if it is neither A nor B.

Note:
--------
Also there might be some other solutions like:

- Using the 'MATCH_KEY_MATCH' or '_GET' symbols to distinguish by URL parameter, if the different block layouts are for different URLs

- If the issue is with a shared template rather than a block, the '_GUID' parameter is usually passed in different for each different place the template is used, so you can base logic around that value.

- If the particular block supports template sets, you can differentiate based on this. For example, the menu block allows you to specify the 'type' of the menu, which determines which templates will be used. You can therefore invent your own new 'type' of menu and store the HTML for it in a new set of templates.

- Sometimes there is a particular template parameter value that you can tie your logic into. For example, if we are making the NEWS_BOX template look a little different for a particular news category, we can rely on the CATEGORY parameter carrying the name of that news category.