Moslate Parameters

The category helps you organizing the Moslate. It can also be used for exporting Moslates of a certain category. The publishing of categories or in which cateogry a Moslate is does not have any influence of it's use though.

This optional parameter is also provided for organization purpose only.

The name identifies a Moslate. When the parameter "Activation" is set to "Normal" it will be called by its name. You should keep the name unique.

The template code is the actual content of the Moslate. Its meaning depends on what is set for the parameter "Mode".

Like everything on Joomla/Mambo, a Moslate need to be published if you want to use it. If you know you don't use a certain Moslate you may want to unpublish it so that no one else might be able to use it accidently.

The ordering of Moslates is partly provided for your own organization. Since version 0.2b it will not be used for the order of activating Moslates when "Activation" is set to "Normal" anymore. It will however influence the order when executing Moslates using one of the other activation methods.

By setting an access level other than "public" you could restrict the use of a Moslate to "special" users for example. Unlike the access level of a content item, not the logged in user is used to determine the rights, but the creator of that content item.

The default for "Data Var" is "data", which would mean that a parameter called that way would receive it's content. In the following example, the data parameter would be set to "some content":

{samplemoslate}some content{/samplemoslate}

If this field is empty, you cannot pass data to a Moslate. In that case the following two lines would be equal:

{samplemoslate/}
{samplemoslate}

The mode tells Moslate what to do with the template code. See the following table for the meaning of each.

mode
name	template
	output	code
Ignore Parameters	<b>- $name -</b><br/> <i>[$data]</i><br/>
	- $name - [$data]	{testmode1 name="title1"}content1{/testmode1}
Replace Parameters (PHP like)	<b>- $name -</b><br/> <i>[$data]</i><br/>
	- title1 - [content2]	{testmode2 name="title1"}content2{/testmode2}
Replace Parameters (EL like)	<b>- ${name} -</b><br/> <i>[${data}]</i><br/>
	- title1 - [content3]	{testmode3 name="title1"}content3{/testmode3}
Eval as PHP	echo "<b>- $name -</b><br/>"; echo "<i>[$data]</i><br/>";
	- title1 - [content4]	{testmode4 name="title1"}content4{/testmode4}
Eval as PHP (Return Output)	return "<b>- $name -</b><br/>". "<i>[$data]</i><br/>";
	- title1 - [content5]	{testmode5 name="title1"}content5{/testmode5}
Include PHP	testmode.php
	- title1 - [content6]	{testmode6 name="title1"}content6{/testmode6}
Call Function	mosMoslateAPI::sampleEchoFunction
	content7	{testmode7 name="title1"}content7{/testmode7}

By using the activation parameter one could set in which case the Moslate should be activated. Usually this should be set to "Normal" but in certain cases - like maybe your own Email Cloaking Mambot - you might want to set it to something like "Every Content". See the following table for more details.

activation
name	description
Normal	The Moslate will be activated as previously described (by using its named tag).
Every Mos-Tag	The Moslate will be activated when ever you use the Mos-Tag (by default: {moslate}) - if you choosed to clear the Mos-Tag it will behave like "Every Content".
Every Content	The Moslate will be activated for every content item.
Every Intro Text	The Moslate will be activated for every content item when the intro text is displayed only.
Every Full Text	The Moslate will be activated for every content item when the full text is displayed.

For a demonstration you may want to see Test Activation.

Left and right white spaces will be removed before data is passed to the Moslate.

When setting this to "Yes", other Moslates can be passed within parameter values. (Though, a better solution would be to use logic and to pass variables using EL.)

When setting this to "Yes", other Moslates can be embedded and will be evaluated before getting passed to this Moslate. The htmltext-Moslate is an example where this might be set to "No".

The output will be evaluated. You could call other Moslates this way.

This will be used by the logic Moslate "tiles:getAsString". It usually makes sense for custom Moslates which will call other logic Moslates.

This will include the logic include file once. Using this flag will save you from adding it to the includes manually and it will not export it. All logic Moslates are using this flag, but you usually do not need it for your own Moslates.

This might be set to "Yes", if you want to have a new page scope created for this Moslate. This will prevent overwriting variables with the same name.

By setting this flag to "Yes" one could use the Expression Language (EL) within parameters. The logic include file will automatically be included if this is the case.

Same as "eval parameters (EL)" but for the data. This is for example used for sql:query.

Using this option will automatically set logic variables for all parameters within the current page scope (if logic scope is set to "Yes" within the new page scope).

An EL could possibly result in an object or array. But if your Moslate expects strings only you may use this option to have them automatically converted to strings.