Main menu

Category Archives: XEO

Post navigation

When building any web application, one of the first requirements is to have the concept of a user who can login to the application. In order create users in a new XEO Application you can do the following:

If you only need a user without any application-specific attributes, you can use Ebo_Perf instances (a model that comes bundled with the XEO Framework). To create users, login with the SYUSER with the XEO Administration Profile and click on the “Users” menu. It will list the current users and let you create new ones.

Now, if you want to create new users, but you want them to have application-specific attributes? XEO comes bundled with an interface iXEOUser.ixeomodel that you can implement in your models. Whenever a Model implements the iXEOUser interface its instances become a user (the iXEOUser interface provides a username and password attribute).

So, how do you implement an Interface? In Eclipse, open the Model that you want to make a user from and under the “general” section click the “edit” button. In the right pane find the implemented interfaces section and click the plus button, save and build.

Interfaces

After this you should probably use the Scaffolding tool to generate (or re-generate) the list/edit viewer for this Model (don’t forget to check the “Include attributes from interfaces”). Create a new instance, give it a username and password and save. Logout and login with the newly created username

Hi, today is all about XEO Community, which had a new release (version 1.1.0) back in February. It took a long time (for various reasons) but the commitment is to have more releases this year (the goal it to have one every three months). It took even longer for me to make this blog post, but as you can see no other posts were made in the meantime, for various reasons.

It’s almost time for a new release but, for now, I’m going to talk about what you can find in the current one.

In the time that has passed we’ve added several new features to the code base, such as:

Themes (Skins):
You can now use the boconfig file to set Themes (they will be automatically converted to instances of the Theme XEO Model, which you can also create at runtime), which are basically a set of CSS files to be included in each page. The XEO Framework now comes bundled with a few themes (designed by the ExtJS community mostly, such as the slate theme)

GridExplorer – List with Preview and Searches saves, multiple groupingThe GridPanel component was extended to support three new features:

Preview

Saved Searches/Views

Multi Group

The preview allows you to “preview” (hence the name) an instance being displayed in the list. In the GridExplorer toolbar you can select where to preview the instance (bottom, left or right) and when selecting an instance it will display a preview in that area.

The saved searches/views allows you to customize the view of the GridExplorer (by sorting, grouping, filtering, etc…) and then save those views with a given name, so that those criteria can be easily reapplied later (depending on what you are doing with the information)

Multi-Group support means that you can now group the results in a GridExplorer (well, in reallity, in any GridPanel) by any number of columns. (Previously you could only group by one column)

PostGreSQL support
You can now use the PostGreSQL database in an XEO Application. For every fan of the PostGre database this will be most welcome (support is also included in the XEO Studio plugin)

Region Layouts
One of the things that was really “blocking” the creativity around layouts was the fact that when you created the Main viewer you really only had the choice to design a left-sided tree panel which opens new viewers in a central area. Now you can declare a Main viewer using the regionLayout component (which allows you to created up to four-regions – north, west, east, south with the fifth region being the center tabpanel). In each of those regions you can regular components to define your interface.

ToolBar with Input Components and Profile restriction
It’s sometimes useful to have not only buttons in a toolbar but also input elements. From this version on, you can use text, numeric, date e combox components in a toolbar. Toolbars can also restrict their menus to only users who have a given profile (much like the case with the TreePanel component)

TreePanel Toolbar
TreePanels can have a child TreePanelToolbar component which allows you to customize a main viewer TreePanel with a set of buttons that you deem appropriate. Any TreePanel can use the TreePanel toolbar, it’s used just like the regular toolbar component.

Lookups with Favorites Selections
Lookup Components can now toggle a “favorites” feature, which means that for each user in each relation, the component can remember the selections made by that user and present them in a quick way to user.

Multi-page selections (and selection counter)
Selection of instances in a Lookup viewer can be preserved across page navigation. Up until now you had to select instances from one page, confirm the selection and then do it again in instances of another page. Also, when multiple selections are possible, a small counter with total instances selected appears in the panel’s toolbar.

Lovs from Database Tables
Lists of values are typically static. but from now on you can declare a Lov as having its values retrieved from a SQL query. To do that you create an empty Lov and then use the Administration interface to define the SQL query to execute.

CardIdLinks in Columns
In any type of GridPanel you can now set the columns that represent relations with instances display the label with a link to open the edit viewer for that instance (you’ll need to declared the column as a xeo:columnAttribute and use the enableCardIdLink property.

Inline Bridge with Favorite Selections
Collection attributes are displayed using the Bridge component, now you can display them inline as a “regular” attribute (such as the Lookup component). You can also activate the favorite selections for this type of component

Quick Date Input (DateField)
Date Fields can now have an abbreviated method of input by using the ‘.’ to select the current date, and the ‘.+3’ / ‘.-5’ syntax to select three days from now and five days ago (respectively)

Cardinality restriction in collections
XEO Models have a minOccurs and maxOccurs property in collection attributes which was not being used. Now when you set a minOccurs bigger than 0 or a maxOccurs smaller than ‘N’ the platform will enforce that situation (selecting instances in a lookup will even prevent you from selection if you have already reached the limit for that collection)

Charts with SQL Bind parameters and Label Formatting
Charts can now have bind parameters when using a SQL query and you can provide a map between labels coming from the data source and what to display in chart.

Column wrap (LongText)
GridPanels having columns with LongText content can now be wrapped so that the entire content is displayed in the visible space (property wrapText)

boObjectListBuilder (Builder Pattern to create boObjectLists)
If you ever thought that creating boObjectList instances required you to know a lot of parameters (when you need to tweak things a bit) you can now use the boObjectListBuilder class which implements the builder pattern to create boObjectList instances like the following:

Favorites (Edit viewers)
Edit viewers can now be added to the list of favorites for a given user. This allows users that do much work in a given instance to mark it, and then quickly have access to it using the favorites list.

Lots of Bug fixes: I won’t even start enumerating them as there were lots of them. We really need another way of managing this.

I’ll make a few posts explaining some of the new features in the following days

Starting a new XEO Application leads you to create the basic XEO Models that comprise the application’s domain, their attributes and relations. Often you’ll also begin by implementing some business logic in events and methods. In parallel you can also deal with the viewers required to display and create instances of said models. The first viewer you’ll need to deal with is the “Main” viewer where you’ll have your application workspace and navigation menu.

If you ever used XEO Studio’s scaffolding option or Viewer wizard you may have already created a main viewer and you have noticed something like this in the viewers’ XML code.

If you preview a main viewer with such a tree panel declaration you’ll see something like the following:

Main Viewer

So as you can see, the xvw:treePanel component is used to create, unsurprisingly, tree panels, and the xvw:menu component is used to create the menu structure. Today’s post is all about the menu component.

Menu’s are hierarchical, meaning that if you create a menu component it will be displayed as a leaf in the tree, but if you create a menu nested in another menu, the top menu will be displayed as folder. See the following code:

Menu Properties

The menu component has a set of properties, namely (not all are included see the documentation for further options):

text – The label of the menu

tooltip – The menu’s tool tip

icon – The menu’s icon (path to a 16×16 icon file)

serverAction – The action to execute when the menu is clicked

target – The target of the executed action (can be one of tab – opens in a new application tab, window, blank, top, download, self = default)

expanded – If the menu is a folder (has sub-menus) whether it should be expanded upon rendering (defaults to false)

profiles – a list of comma-separated string with the names of the profiles authorized to see this menu (if a user is logged with profile that it’s not part of the list, he won’t be able to see the menu (or click))

profile – Same as above, for a single profile.

value – Check the section bellow

Menu Actions

More important than what menus look like, is what they do. The action executed by a menu is declared in the serverAction property (as explained above). When in a Main viewer (backed by the netgest.bo.xwc.xeo.beans.XEOMainBean) you have a set of predefined actions that you can reuse (you can pass parameters to that action by using the value property); Let’s examine some of the available actions :

serverAction=’#{viewBean.listObject}’ – List Model Instance

This action is used to list instances of a specific Model, to use it you need to define the value property with a JSON Object with the following properties:

viewerName – The name of the viewer to open (should be a viewer backed by the XEOBaseList bean (or a bean derived from that one)

boql – The boql expression to execute (the result of the boql evaluation will be the instances to display)

So, imagine you have Model A and want to create a menu entry to list all instances of the model. You would create your menu like this (notice the value property as a JSON Object):

Another important thing: Usually the target for these kind of actions is “tab” to open a new tab in the application and also, don’t forget the convention of having icons for each model under the resources/MODEL_NAME/ico16.gif and for viewer location webapps/default/viewers/MODEL_NAME/viewerName.xvw (usually list.xvw, edit.xvw and lookup.xvw).

You can also have the menu to open an edit viewer for a specific instance. It’s not very useful if declared in XML as it requires you to know the identifier (BOUI) of the instance, but you could do it like the following:

serverAction=’#{viewBean.openLink}’ – Open a URL

A not so common, but still useful feature is to open given URL in a new tab (be it google, or a JSP of yours) the difference is that you don’t need a JSON object for the value property, just the url, like this:

Custom Actions and Parameters

Of course, you are not limited to the default actions in the XEOMainBean, if you need something more specific you can always extend the XEOMainBean with a bean of your own and create a method (like the following):

public void openMyCustomViewer() { }

And declare the menu using serverAction=’#{viewBean.openMyCustomViewer}’ you can also do more. You can use the Menu’s value property to pass parameters to your method. For instance, imagine a menu declared like the following: