Smartlets are modular, flexible building blocks. They make it possible to write fully self-contained, modular applications, have built-in Ajax support while being very suitable for scriptless environments, are localizable, and, last but not least, have a tremendous ease of deployment.
Still, there was room for improvement on a number of levels.
When developing Smartlets, you will have to decide what to parametrize (using Smartlet Properties). You will want to have consumers of the Smartlet set a number of parameters that will determine what the Smartlet will look like and/or behave. When the list of properties grows larger however, there inevitably comes a point where you will have to decide where to go from there.
In iXperion 1.3, there are a few new things you can do at this point:
Smartlets now support a model for subclassing code blocks. Suppose you have a Smartlet that displays an event calendar. Now, you can have a translation format each event, but let the consumer of the Smartlet subclass that translation by adding a local translation in the scope of the consuming page.
Sometimes, a number of parameters work together as a group. Setting just one parameter just makes no sense without changing others. In iXperion 1.3 you will be able to create, store and use so-called Smartlet parameter sets.
Many Smartlets can be considered as widgets. Some of them will be standalone apps that have their own input and output, but other Smartlets are in fact controls. Controls expose events that can be consumed externally. In iXperion 1.3, Smartlets can expose and consume events.
Using the event model will allow you to further modularize your Smartlets, making re-use much easier. It will result in smaller, compact and specialized Smartlets that work together.
As you know, Smartlets come with their own CSS, stored in the ClientData subfolder. A link to this CSS is automatically included in consuming pages. In iXperion 1.3, the convention will be that a Smartlet should be published with separate CSS items for functional and for graphical rules. Also, a skin property is added that will always be rendered as a CSS class in the Smartlet HTML output. This skin can be set using the boxskin parameter, or by setting the smlConfig_DefaultSkin global buffer.
Just make a copy of the skin CSS and edit it for each new skin:
Skin.css:
| Smartsite SXML |
|
|---|---|
{smartlet.nameselector()} {
color: white;
background-color: red;
}
|
|
CoolBlue-Skin.css:
| Smartsite SXML |
|
|---|---|
{smartlet.nameselector()}.coolblue {
color: #000;
background-color: #5ef
}
|
|