Package com.onec.ui

Interface EntityView


public interface EntityView
Per-entity UI definition, authored in code and discovered as a Spring bean — the "view" layer of the framework. Override a surface method to take control of how that entity's screen is composed; anything you don't define falls back to the auto-generated default. The framework resolves these into a renderer- agnostic view model and compiles it to DivKit (or any future target), so you shape the UI from code without writing any frontend.
 @Component
 class PropertyView implements EntityView {
     public Class<?> entity() { return Property.class; }
     public void list(ListSpec list) {
         list.columns("displayName", "address", "defaultNightRate")
             .label("defaultNightRate", "Rate / night");
     }
 }
 
  • Method Summary

    Modifier and Type
    Method
    Description
    default void
    Custom action buttons for this entity — on the list (toolbar / per-row) or the record detail.
    default boolean
    Whether this entity gets a discussion thread (the /api/comments panel) on its detail surface.
    The domain class (catalog or document) this view customizes.
    default void
    Per-field hints for this entity — order, visibility (list/form/detail), group, width, widget — using the same field(...) DSL as the layout.
    default void
    inputs(InputSpec inputs)
    Custom input fields for this entity's list toolbar — a date picker, dropdown, text or number field shown next to the action buttons.
    default void
    list(ListSpec list)
    Customize the list/table surface.
    default String
    The profile/persona id this view applies to, or null (default) to apply to every profile.
  • Method Details

    • entity

      Class<?> entity()
      The domain class (catalog or document) this view customizes.
    • profile

      default String profile()
      The profile/persona id this view applies to, or null (default) to apply to every profile. A profile-specific view lets you build a radically different screen for a persona; the resolver prefers it over the default. Composition is just Java — subclass another view and override a surface.
    • list

      default void list(ListSpec list)
      Customize the list/table surface. Default: auto-generated columns.
    • fields

      default void fields(EntityConfigBuilder fields)
      Per-field hints for this entity — order, visibility (list/form/detail), group, width, widget — using the same field(...) DSL as the layout. Field config lives here now; the layout's section calls are pure placement. Applies to the default view; a profile-specific view can override.
    • actions

      default void actions(ActionSpec actions)
      Custom action buttons for this entity — on the list (toolbar / per-row) or the record detail. Each runs arbitrary server logic (.handler(...)) or just navigates (.navigate(...)). Default: none.
       public void actions(ActionSpec a) {
           a.action("recalc").label("Recalculate").icon("calculator").scope(ActionScope.DETAIL)
            .handler(ctx -> { service.recalc(ctx.id()); return ActionResult.refresh("Recalculated"); });
       }
       
    • inputs

      default void inputs(InputSpec inputs)
      Custom input fields for this entity's list toolbar — a date picker, dropdown, text or number field shown next to the action buttons. An input doesn't filter the list itself; its current value is passed to the action handlers via ActionContext.input(String) when a button is clicked. Default: none.
       public void inputs(InputSpec in) {
           in.input("asOf").label("As of").type(InputType.DATE);
       }
       public void actions(ActionSpec a) {
           a.action("report").label("Report").scope(ActionScope.TOOLBAR)
            .handler(ctx -> ActionResult.message("Report as of " + ctx.input("asOf")));
       }
       
    • comments

      default boolean comments()
      Whether this entity gets a discussion thread (the /api/comments panel) on its detail surface. Opt-in and per-entity: the default is false, so an entity has no comments until a view turns them on — you choose exactly which catalogs/documents support discussions. The global onec.comments.enabled switch still gates the feature as a whole; this picks where it appears. Override to opt in:
       @Override public boolean comments() { return true; }
       

      Resolved per entity (not per profile): if any of an entity's views opts in, its detail carries the panel.