Visual elements

The Visual Elements API provides an affordable way to create views with user sensible data. Visual Elements relies on names given to those parts to be controlled.

The most common example arises when creating a template that needs to know who is viewing it, so can render more or less content. With Visual elements you will give a name to the sensible parts and create a configuration file. The API will do the rest.

Visual Elements is stored as a JSON file in /WEB-INF/elephant/conf and can be edited using BaaS -> Tools -> Files -> Configuration -> JSON.

Controlled attributes against user

Every visual element will be checked against user his allowed social groups, grouping values, administration attributes. As a result, the API will tell if the user can have access to the element or is a simple visitor (an authenticated user with no specific permissions for the element).

First case, insert by iteration

The method allowed(user) returns a sorted collection of allowed elements for user. Inside the template you will iterate the collection, check its name and insert the content. The sort order is also part of the API and is specified in the configuration file.

The image gives a very simplified example of iteration. Does not show how to implement the iteration within the template. Usually you will check the visual element name against the expected name for content. Example, if visual-element-name equals content-name then add the content.


Second case, check against the API

Instead of iterating a collection, you can check directly against any given name. The method getElement(name, user) returns, if allowed for user, the visual element with the given name.


The sub elements

As you probably already noticed, both cases include the possibility of sub elements. A sub element is a visual element that fully depends on its parent. The allows(name, user) returns true when the element name can be shown to user.

To understand sub elements utility, think about form actions. The parent element is an HTML form and the buttons represent actions. Using the API, each button can be conditioned by the allows(action_name, user) method.

Another example, imagine you have a determined list of users. Now, you're not sure whether show user's name and company, or only company's name. And you're quite sure this will be something that will vary among your customers. Using the API, you can relay on an easy to edit configuration file.

Adding specific entities

The whole Elephant system heavily uses entities. Entities are groups of related information and have a full Entities API to relay on. In order to use entities with the Visual Elements API, you need to implement the VisualEntityCheck interface. Consists in a single method check(property, value, entity, user) and returns a boolean.

Attributes
Some attributes are deprecated

In the long run, Scripting will completely substitute most of the Attributes within Visual Elements.

Visual elements attributes are ORed. The constraints will be interpreted as if condition A or condition B ... are fulfilled by the current user, the requesting element will be shown.

Generic attributes

Generic attributes apply to any visual element node.

Attribute

Description

Required

name

The attribute name is used in templates to identify or locate the attribute.

label

Label points to a resource key. May be used as a caption for the attribute values.

order

Is a numerical that forces the sort order of elements returned in allowed method.

role

Must conform the syntaxis specified in Security .

eval

Allows complex constraints using scripting. See Scripting .

syndications

ORed social group identifiers the user needs to be assigned to. See Social groups .

groupings

ORed contact groupings the user needs to be assigned to.

businessSyndications

ORed social group identifiers the company or center where the user belongs, needs to be assigned to. See Social groups .

businessGroupings

ORed contact groupings the company or center where the user belongs, needs to be assigned to.

visitor

The user is authenticated.

admin, worker, student, hhrr

True or false ORed constraints indicating that the user must be an administrator, a working person in a company, a student in a center or a responsible for human resources in a company or center.

subElements

Children elements of current visual element. Mainly used when a visual has subelements with constraints.

Per module attributes

Per module attributes address those features unique to the entities in this module. Per module attributes sum to the generic attributes.

Dossier and Dossier category

Attribute

Description

Required

phases

Array of ORed phases, representing current project phase.

roles

Array of ORed participation roles: PARTICIPANT_OWNER, PARTICIPANT_ASSISTANT and PARTICIPANT_SUBJECT.

discriminators

Array of ORed participation discriminators.

directOwner

True or false value indicating whether the user is directly assigned as owner.

participates

True or false value indicating whether the user is participating, despite the role or attribute assigned.

branchAdmin, showAllAttachments, showParticipants, showAllIssues,
receiveAllEmails, bindingVote, driver, coordinator, beneficiary,
offerer, research, funding, support, consortium

True or false ORed constraints indicating the participation attribute with the same name.