Functions in Enfinity

Question

I notice that there are several "inline-functions" I can use to alter the value before it's printed. For example: <isprint value="#replace(data, '$', 'Fr.')#">

What I want to ask is can I create a custom functions like this? If I can, how? I know how to create custom ISML tag, but I don't know whether there's a way to create custom inline functions like that. There's nothing about it on the Enfinity manuals. If I can, that would help me cut down the code size, as I don't have to go back and forth to JSP to handle all the things that can't be handled by the ISML functions. Thanks.

Answer 1

Unfortunately there is no direct and clean way to create such ISML functions generally - at least in Intershops Enfinity Suite 6.x product line.

However, a pretty common workaround is to create "helper objects". You can for instance create a class

public class MyHelperFunction
{
    public String getPrefixedString(String prefix, String data)
    {
        return prefix+data;
    }    
}

You would then create a pipelet that puts an instance of this class into your pipeline dictionary like this

package com.test.pipelet;

import com.intershop.beehive.core.capi.pipeline.Pipelet;
import com.intershop.beehive.core.capi.pipeline.PipelineDictionary;

public class CreateHelperFunctionInstance extends Pipelet
{
    public static final String DN_HELPER_FUNCTION_INSTANCE = "HelperFunctionInstance";

    public int execute(PipelineDictionary dict)
    {
        dict.put(DN_HELPER_FUNCTION_INSTANCE, new MyHelperFunction());
        return PIPELET_NEXT;
    }
}

If this needs to be a common function available everywhere put a call to this pipelet into your Prefix-Start pipeline which is called before processing any client request ... usually called Prefix.xml but may be called differently depending on what this statement returns:

select di.domainname, p.stringvalue from preference p inner join domaininformation di on di.domainid=p.domainid where preferencename='SitePrefixPipelineName';

The boundaries of the Prefix pipeline method are requests that are not really storefront requests like in Jobs or for Mail templates. There you would have to include the pipelet described above explicitly.

However, alternatively you can also do a bit of dirty JSP magick to get an instance of this object - JSP is concidered dirty in Intershop projects most of the time but it sometimes leads to more simple code/pipelines:

<%
    getPipelineDictionary().put("HelperFunctionInstance", new MyHelperFunction());
%>

You could for instance include this in your root template to make it available throughout your ISML code. The boundaries of including this in the root template is the usage of which would issue a new SSI request. In the context of the new request you would loose your HelperFunction (you would have to re-include it).

In both cases you will now be able to call from ISML:

<isprint value="#HelperFunctionInstance:prefixedString('prefix', data)#">

I know this is not very nice and not exactly what you expected. However, unfortunately it is the only way in Enfinity Suite 6.x besides the "custom ISML Tags" = modules you already know. Those modules are used for the scenarios you describe most of the time in Enfinity suite 6.x.

Hope this helps.

Answer 2

You cannot practically. There is a special support for these ISML functions in the ISML compiler which translates your ISML into JSP. When new functions are introduced in Enfinity (IS7) the grammar of the compiler is changed and the functions come with the new release of the product. Usually additional support is added to the class AbstractTemplate which is the base class of all servlets generated out of ISML. Unless you rewrite the compiler yourself :-) you cannot add new functions.

You can do other things to improve your code, but most often two options are used:

1. ISML modules
2. ISML custom tags (classes that extend com.intershop.beehive.core.internal.template.isml.CustomTag and which are registered in module.properties file in your cartridge. E.g. peek at core\staticfiles\cartridge\config\modules.properties)

The second is officially discouraged for custom project development because the CustomTag class is internal.