Class StudioMetaUtils

java.lang.Object
com.axelor.studio.utils.StudioMetaUtils

public final class StudioMetaUtils extends Object
Utilities for meta views.
  • Method Details

    • findView

      public static AbstractView findView(String viewId)
      Find view by xml view id.
      Parameters:
      viewId - the view id
      Returns:
      AbstractView or null
    • findView

      public static AbstractView findView(String name, String type, String model)
      Find view by given name, type and model
      Parameters:
      name - view name
      type - view type
      model - view model
      Returns:
      AbstractView or null
    • findView

      public static AbstractView findView(String name, String type, String model, String module)
      Find view by the given name, type, model and module.
      Parameters:
      name - view name
      type - view type
      model - view model
      module - module name
      Returns:
      AbstractView or null
    • findView

      public static AbstractView findView(String name, String type, String model, String module, String jsonModel)
      Find view by the given name, type, model, module and custom model.
      Parameters:
      name - view name
      type - view type
      model - view model
      module - module name
      jsonModel - custom model name, required for custom model views
      Returns:
      AbstractView or null
    • findModuleView

      public static AbstractView findModuleView(String name, String type, String model)
      Find the module-authored base view by name, type and model — the highest-priority view that is NOT owned by a Studio project, NOT computed and NOT an extension. Used to diff against when exporting or deploying a Studio view extension, so the diff is never computed against the Studio view's own deployed snapshot (which would always be empty once the view is deployed), nor against a computed view — a computed view is recomputed from scratch on every recompute (base + every current extension, Studio's own included), so once Studio has deployed once it would contaminate every diff after the first with Studio's own prior change.

      Extension rows are excluded explicitly: they share the base view's name, type and model, and an <extend> fragment carries no view body at all — diffing against one yields garbage. They also routinely share the base view's priority, so before this filter the tie was broken by whatever the database happened to return first.

      Parameters:
      name - view name
      type - view type
      model - view model
      Returns:
      AbstractView or null
    • findModuleComposedView

      public static AbstractView findModuleComposedView(String name, String type, String model)
      Find the module-authored view as the application would compose it without Studio: the base view of findModuleView(java.lang.String, java.lang.String, java.lang.String) with every module-authored extension applied on top.

      This — not the bare base view — is what a Studio view's content must be diffed against. The designer is seeded from the composed view, so its stored schema already contains whatever the module extensions contribute. Diffing that against the bare base re-derives those contributions as Studio's own changes, and since the module extensions are still active they then compose in twice: fields and panels appear duplicated, and nodes whose position shifted get dropped and re-inserted.

      Studio-owned extension rows are deliberately left out, so each Studio app keeps producing an extension that is independent of every other app's — see findExtensionViews(com.axelor.meta.db.MetaView, boolean).

      Parameters:
      name - view name
      type - view type
      model - view model
      Returns:
      AbstractView or null
    • findModuleComposedView

      public static AbstractView findModuleComposedView(String xmlId, String name, String type, String model)
      As findModuleComposedView(String, String, String), but pinned to an exact base view when xmlId is given.

      A Studio view's content records the xmlId of the view the designer was seeded from. Name, type and model can match several rows, so without the pin the diff could be computed against a different view than the one being edited. An xmlId that no longer resolves (the module dropped or renamed it) falls back to the name/type/model lookup rather than failing the deploy.

      Parameters:
      xmlId - the exact base view to diff against, or null to resolve by name/type/model
      name - view name
      type - view type
      model - view model
      Returns:
      AbstractView or null
    • findExtensionViews

      public static List<MetaView> findExtensionViews(MetaView view, boolean includeStudio)
      Find the extension views that apply to the given base view, ordered the way the view loader composes them: by module resolution order, then by descending priority within a module.

      Same identity/group match and module-resolution ordering as ViewGenerator's own (private) extension lookup, reimplemented here with one fix that can't be made in core: groups are compared with null treated as empty. MetaView.groups has no field initializer, so a brand-new row queried back within the same session that just created it (e.g. a Studio extension row this method has to pick up) still has a null collection, while a freshly-loaded row's is an empty (not null) set — Objects.equals would call those unequal and drop a same-transaction extension that has no explicit groups.

      Parameters:
      view - the base view
      includeStudio - whether Studio-owned extension rows participate; true when recomputing the live view (Studio's own change must be in it), false when building a diff source (it must not be)
      Returns:
      the ordered extension views