Table Views

  • Users will also be able to create views for Entity tables
  • Views are same as the Views you create in the database
  • Users will have the option to select which fields they want to see in the view from a list of available fields assigned to the respective table

In this article

Views

Developers can create one or more Views for an Entity table.

Views in Entity Framework are similar to Views in database.

Views under Entity Framework is of very great use for the developers.

When using views, the number of entity methods and entity tables, in an application will be greatly reduced. So, need to use it wherever it can be useful.

If a table is returning large number of columns and we want only some columns to be displayed, then in such cases we can create a VIEW containing those set of columns on a TABLE.

The underlying source (target method source), need not to be a SQL table or a SQL query. Target method source can be of SP, DLL method.

Field's Description

  • Table Name

    Represents the Entity table name under which the Table Fields are get added. Here it is internal (primary and foreign key) field.

    Need to provide the name of the entity table. It should be a unique name for that application.While creating new entity table, need to follow some naming procedures.

    Name should reflect for what entity / entity method it is going to be used for.

    If the table is going to be a Request table, then suffix the name with “Request”. Example as AccountTypeRequest.

    If the table is going to be used for Read purpose, then no need to any suffix. Example as AccountType.

    If the table is going to be used for Lookup control, then can name it like AccountTypeLookup.

    If the table is going to be used for CUD operation, then can name it like AccountTypeCUD.

  • View Name Views in Nebula Framework are similar to Views in database.When using views, the number of entity methods and entity tables, in an application will be greatly reduced. So, need to use it wherever it can be useful.

  • View Description A short description on usage of this View.

  • Is Default? This identifies that this setting should be the default one for this entity table. There can be only one item, that can be set as default for that entity table. By default, this option is false.

  • Is Distinct

    If is_distinct is true, distinct values of the view columns is used for selecting the rows.
    By default, this option is false.

    The underlying query will be formed like this:

    select distinct List mclsys.view_fields.field_name from table_name

    This is useful to get any subset of (key) columns from the base table, with distinct records.

  • Is Readonly View If create/update/delete operations should not be allowed in this entity table view, then set this option to true.
    By default, this option is false.

  • Requery Every Page? In the #response temp tables, Primary keys only are stored. And at each page request, the data is queried from underlying tables for every page, by joining the primary keys from #response temp table. When this setting is added at the table level, it will be overridden with value set at the table_views level. When the setting is added at the view level, it overrides any value set at the method_tables level.
    By default this option is false.

  • Comments A little longer explanation of what that Entity object will do.

  • Row Identifier Internal field.

  • Created User User who created that Entity object.

  • Created Date Date in which Entity object was created.

  • Updated User User who updated that Entity object lastly.

  • Updated Date Date in which Entity object was last modified.

Fields in View

Here the developer needs to add the fields that were need to be used for that View.

Field's Description

  • View Name Here it is internal (primary and foreign key) field.

  • Field Name Developer need to select the field from the dropdown that need to be added for that View.

  • Field Sequence

    Need to specify the order sequence in which the fields need to be returned back from server. It should be a unique integer value.
    Though any value could be specified, it is suggested to follow that, for the first field enter field sequence as 10, second field 20, third field 30 like that. In increment of 10. This is because, when there was a need to add a new field name between the existing fields one and two, for this newly added field, you could enter field sequence as 11. If you used field sequence as 1, 2, 3…, when adding new field, in between already existing field, you would need to change the field sequence for all other fields.

  • Row Identifier Internal field.

  • Created User User who created that Entity object.

  • Created Date Date in which Entity object was created.

  • Updated User User who updated that Entity object lastly.

  • Updated Date Date in which Entity object was last modified.