The user interface plays an important role to reach make the user feel comfortable. To adjust it, you will need lots of modeling and little bit of coding here and there.
An online database comes with a default menu which allows access to the index from where the generic workflows start. Every online application, tailored to one user group, receives its own custom main menu which provides quick access to their pages and tasks. When customizing a main menu you create links and sub menus on the fly or reuse them, if they already exist.
Hint: Do not use a static link to point to a service without any parameters! It is better to use a service menu item, so you save work in case you rename the service!
The first entry of the main menu is also the start page of the store. When you are using static links for menu items, you may not use an absolute URL as a first entry, as this would redirect the user away from the store on entry. Topincs will simply ignore that menu item. In this case your start page will be the next valid entry. Revisit the menu factsheet and provide a URL within the store to fix that problem.
Users have a deeper relationship with their domain than view and edit. They want to do things:
To accommodate those needs Topincs introduces context menus. A context menu entry can either be a service connection or a dynamic link. The first one binds the topic in focus to an argument of a service. It is created by declaration. The latter needs a few lines of code to simply create a link within the web database and e.g. prefills a form with values derived from the context (time, date, user). Context menus are accessible on the page of a topic as well as on right-clicking links to the topic. Conditions may be specified under which entries of a context menu are inactive or hidden.
Hint: If a topic has neither a name nor a responsible label rule, the id will be used as a label. Sometimes this is enough.
The label of a topic can be a computed value. It is recomputed on change, so that it is always correct. Label rules are created in the User interface Index linked in the Admin menu. They work on one or more topic types and use a tiny piece of PHP code to specify the computation of the label. The code is the body of a method of a transient domain class. So
$this is a tobject and you can access the normal interface of its topic type. Sounds complicated? Watch the video and see how easy it is.
// 2021, Switzerland, Maria, Ball return sprintf( "%s, %s, %s, %s", $this->get_year(), $this->get_country(), $this->get_child_name(), $this->get_gift() );
// Johannes Gutenberg $this->get_first_name() . " " . $this->get_last_name()
Check it out
Label rules can be varied depending on the perspective by scoping them with a role type and optionally a language. Usually some segments of the unscoped label rule needs to be left out since it is given in the context.
Check it out
Hint: Drag and drop does not work on a select box, but to the right of it.
The order in which statements are presented in a topic or form page can be influenced by an occurrence of type Field order on the topic type. The field order can be edited on the page of the topic type. You need to take care to only add constraints that belong to the topic type or a super type thereof.
The sort order of instances can be controlled for the following aspects of the web database:
The predefined alphabetical sort order is case insensitive, so it does not matter whether the first letter is lower case or upper case. The sorted topic list appears natural to humans. Custom sort orders – on the other hand – use the result of a given computation rule for a case sensitive comparison. The programmer can simply make it case insensitve by lower casing the result in the computation rule.
By default counter players are displayed as a link with a label. In some cases it makes more sense to just display all the information on a counter player directly in the page. There is two settings to easily activate this behavior in form and factsheet: Displayed as data sheet and Displayed as row. The first one displays information vertically, the second one horizontally. Row display does works well for topic types with up to seven constraints.
If users should not see certain fields, either to simplify the user interface or for security reasons, there is generally three approaches:
You have seen multiple ways how to tailor the user interface to you needs, but this is just the tip of the iceberg. There is a many options for you left to explore. Try them out and see if it helps you. If not, simply revert the change.
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.