Populator/Converter Generator

Map model attributes to DTO properties once -- get the Populator class, its Spring bean, and a new or extended converter wiring.

🔒 Your code never leaves your browser — everything is generated locally from templates, no AI, no server round-trip.

Extension name

Java base package

SAP Commerce version

Source model class is required.
Target DTO class is required.
Add at least one field mapping.
New converter bean id is required.

Source model class

Target DTO class

Field mappings

Converter

Mode

New converter bean id

trainingcore/src/com/prospect2p/core/populators/ProductPopulator.java

package com.prospect2p.core.populators;

import de.hybris.platform.core.model.product.ProductModel;
import de.hybris.platform.commercefacades.product.data.ProductData;
import de.hybris.platform.converters.Populator;
import de.hybris.platform.servicelayer.dto.converter.ConversionException;

public class ProductPopulator implements Populator<ProductModel, ProductData> {

    @Override
    public void populate(final ProductModel source, final ProductData target) throws ConversionException {
        // TODO: no field mappings configured
    }
}

Generated scaffold. Review and test before using in production.

What is a Populator/Converter in SAP Commerce?

A Populator in SAP Commerce (Hybris) is a small class implementing Populator<Source, Target> with one method, populate(source, target), that copies/derives fields from a model (or another DTO) onto a target DTO. A Converter composes one or more populators and the actual "new instance" creation into a single reusable conversion step -- typically a bean extending/parented on AbstractPopulatingConverter.

This split exists so individual field-mapping concerns stay small and composable: a converter's populator list can mix OOTB populators with your own, and the same populator can be reused across multiple converters that happen to need the same mapping.

When to use it

Use a new populator + converter when you're introducing a DTO that doesn't already have an OOTB converter -- e.g. a custom facade-layer Data object for a new feature.

Use "extend an existing converter" when you want to add one or two extra fields onto an OOTB DTO (like ProductData) without forking the whole OOTB converter -- appending your populator onto its existing list via Spring's list merge keeps every other OOTB field mapping intact.

Files generated

The populator class implementing Populator<Source, Target>, with populate() setting each mapped property.
A Spring bean registering the populator.
Either: a new converter bean parented on abstractPopulatingConverter with a targetClass and a populators list referencing the new populator -- or an XML snippet that merges the new populator into an existing OOTB converter's populator list.

Step-by-step: how to use the output

Copy the populator class into <extension>/src/<package>/populators/.
Copy the <bean> elements into your extension's -spring.xml.
If extending an existing converter, double-check the existing bean id against the OOTB extension's own spring XML for your platform version -- bean ids occasionally change between versions.
Call the converter from your facade/controller code (converter.convert(model) or convertAll(models)) and confirm the new field(s) show up on the resulting DTO.

Common mistakes

Forgetting merge="true" on the <list> when extending an existing converter -- without it, the list replaces the OOTB converter's populators instead of appending to them, silently dropping every other field the converter used to map.
Giving the new converter bean (in "new converter" mode) the wrong targetClass -- it must be the concrete DTO class the converter instantiates, not an interface or the source model class.
Relying on field order in the populator list to fix a conflict -- if two populators both set the same property, whichever runs last wins, and that ordering isn't always obvious at a glance.
Writing business logic (calculations, remote calls) directly inside populate() instead of delegating to a service -- it makes the populator hard to unit test and hard to reuse outside the converter.

Frequently asked questions

Why not just set DTO fields directly in a controller instead of using a Populator?

Populators are reusable across every converter/controller that needs the same mapping and are independently unit-testable. Scattering the same source->target field logic across multiple controllers is exactly what the populator/converter pattern exists to avoid.

What does AbstractPopulatingConverter actually do?

It implements the boilerplate of Converter<Source, Target>: creating a new target instance (via targetClass), then running every populator in its list against (source, target) in order. Your converter bean just supplies targetClass and the populator list.

How do I append a field to an OOTB converter like ProductConverter without breaking it?

Redeclare the same bean id with itself as parent and a populators list using merge="true" -- Spring appends your new <ref> to the inherited list rather than replacing it. That's what "extend an existing converter" mode generates here.

Can a populator call another populator?

Not directly -- populators are meant to be flat, composable units invoked by a converter's list. If one mapping depends on another, either combine them in one populator or make sure the converter's list order puts the dependency first.

Do I need @Override on populate()?

It's not required by the compiler, but yes -- it's good practice and this generator includes it, since it immediately flags a typo in the method signature (wrong generic types) as a compile error instead of a silently-unused method.

Related tools

What should we write next? Vote