Describe a computed attribute once -- get the items.xml dynamic persistence snippet, the DynamicAttributeHandler class, and its Spring bean.
🔒 Your code never leaves your browser — everything is generated locally from templates, no AI, no server round-trip.
trainingcore/src/com/prospect2p/core/handlers/MyAttributeAttributeHandler.javapackage com.prospect2p.core.handlers;
import de.hybris.platform.servicelayer.model.attribute.DynamicAttributeHandler;
import de.hybris.platform.core.model.product.ProductModel;
import java.lang.String;
public class MyAttributeAttributeHandler implements DynamicAttributeHandler<String, ProductModel> {
@Override
public String get(final ProductModel model) {
// TODO: compute the value of this attribute
return null;
}
@Override
public void set(final ProductModel model, final String value) {
throw new UnsupportedOperationException("attribute is a read-only dynamic attribute");
}
}
A dynamic attribute in SAP Commerce (Hybris) is an items.xml attribute with persistence type="dynamic" -- instead of being stored as a database column, its value is computed on the fly by a Java class (a DynamicAttributeHandler) every time the attribute is read (and optionally written).
The handler implements DynamicAttributeHandler<ValueType, ModelType> with get(model) and set(model, value), and is wired to the attribute via the attributeHandler bean id in items.xml -- the platform calls get()/set() transparently whenever code calls the generated getter/setter on the model.
Use a dynamic attribute when a value should always be derived (from other attributes, related items, or external state) rather than stored -- e.g. a discounted price, an aggregated rating, or a computed status flag that must never go stale relative to its inputs.
Avoid it for anything expensive to compute that gets read often (it recomputes on every get() call, with no built-in caching) and for values that genuinely need their own query-able, indexable database column -- those should be real persisted attributes instead.
No -- persistence type="dynamic" means there is no database column at all. The value is computed fresh by the handler's get() method every time it is read, and (if read/write) written via set() to wherever the handler chooses to persist it, if anywhere.
Yes, and it's the most common case -- set modifiers write="false" in items.xml and have the handler's set() throw UnsupportedOperationException, exactly as this generator does by default.
Java generics don't allow primitives as type arguments -- a handler for a boolean-like value must declare DynamicAttributeHandler<Boolean, ...>, not <boolean, ...>, even though the getter still returns a primitive-compatible wrapper.
Yes, but be careful of call chains and performance -- each nested dynamic attribute read triggers its own handler, so a get() that reads several other dynamic attributes can get expensive quickly with no caching layer in between.
A Populator runs once, explicitly, when converting a model to a DTO in one specific code path. A dynamic attribute is invoked implicitly every time its getter is called, from any code, anywhere -- it behaves like a real model attribute rather than a one-off conversion step.