Two Ways to Show Rows
Every SAPUI5 developer hits this fork in the road: do you reach for sap.ui.comp.smarttable.SmartTable or build a plain sap.m.Table bound to an OData model? Both render rows. They differ wildly in how much work they hand you for free.
Smart Table generates its columns, filters, and personalization UI from OData metadata annotations. You point it at an entity set and it builds the UI around it. The catch: it only works when the backend serves proper annotations, and it drags in the sap.ui.comp library.
When Smart Table Is the Right Call
If your backend exposes SAP annotations — com.sap.vocabularies.UI.v1.LineItem and friends — Smart Table is almost unfair. One XML control gives you sorting, filtering, column personalization, export to Excel, and variant management with zero boilerplate.
Smart Table trades control for speed. When the annotation story is strong, it cuts days of table work down to hours.
<mvc:View xmlns:comp="sap.ui.comp.smarttable"
xmlns:mvc="sap.ui.core.mvc">
<comp:SmartTable id="OrdersTable"
entitySet="SalesOrders"
tableType="ResponsiveTable"
useExportToExcel="true"
useVariantManagement="true"/>
</mvc:View>That snippet is the whole view. Columns, filter bar, and the settings dialog all come from annotations. Say you have a Fiori Elements-style backend with maintained annotations — this is your fastest path to a consistent UI.
When sap.m.Table Wins
Plain sap.m.Table gives you full control over every cell. You define the columns, the templates, and the behavior. It works with any model — OData, JSON, or a local array — and carries no annotation dependency.
<Table items="{/Products}">
<columns>
<Column><Text text="Product"/></Column>
<Column><Text text="Price"/></Column>
</columns>
<items>
<ColumnListItem>
<cells>
<Text text="{Name}"/>
<ObjectNumber number="{Price}"
numberUnit="{Currency}"/>
</cells>
</ColumnListItem>
</items>
</Table>Freestyle apps with custom designs, mixed data sources, or pixel-specific layouts belong here. Anything annotations can't express — custom status coloring, embedded charts per row, drag-and-drop — needs the manual table.
Use sap.m.Table when the design is custom or the data isn't annotation-rich. Use Smart Table when consistency with Fiori Elements UX matters more than pixel control.
A Practical Decision Checklist
- Annotations available? Yes → lean Smart Table. No → sap.m.Table.
- Need personalization and variants? Smart Table ships them; on sap.m.Table you build them yourself.
- Custom cell rendering? sap.m.Table's template aggregation is the flexible option.
- App size budget? sap.ui.comp adds weight. For a tiny app, manual tables load faster.
- Team skill? Smart Table needs annotation knowledge; sap.m.Table needs binding and templating knowledge.
One hybrid pattern works well in practice: Smart Table for the main list (free filters and variants), with custom columns injected via the beforeRebindTable event when you need a cell the annotations can't describe.
Final Take
Neither control is better in the abstract. Smart Table is a productivity multiplier on annotation-rich backends; sap.m.Table is the flexible default everywhere else. Match the tool to your backend's annotation maturity and your design's custom requirements.
Which one do you reach for first — and has a Smart Table ever fought you on custom columns? Share in the comments.