Take a look into the article that was published in the German “Informatik Aktuell” online magazine:

Click onto the image for reading the text or open the link >HERE<.

The component is part of our component portfolio for quite some time – but we see that it is rarely used… So we want to push the visibility a bit. Here is a short video “from the labs”:

CaptainCasa logs quite useful information – e.g. problems when accessing expressions, performance data about each single request processing – and of course details about errors.

By default the logging is done in the following directory:

<installationDir>/server/tomcat/work/Catalina/localhost/<webApp>/log_eclntjsfserver.txt.*

There maybe several log files (there are 5 rotating files into which the log is written), so sort the directory by date and pick the newest one.

The logging is configured in the file:

<project>/webcontent/eclntjsfserver/config/logging.xml

Please refer to the logging.xml_template file within the corresponding /webcontentcc-directory of your project.

During development it makes sense to use log level “INFO” and to directly output the log to the console, so that you can directly observe what happens. The log configuration to do so is:

<logging level="INFO" console="true">
</logging>

Using log level “INFO” means that each request is logged. In the log you see the processing in different phases. A really useful information is the list of the include-structure of the current dialog. Here you can find out, which layout definitions (.jsp definitions) are used, and how they are nested.

There are a plenty of other configuration parameters that can be used in the logging.xml configuration, each of them being described in the logging.xml_template file. Examples:

• Definition of an explicit directory to log to
• File size of each log file, number of log files that are written
• Link to slf4js logging

We added a tool “Style Editor” to our set of tools. The tool simplifies the creation and editing of own style sheets.

In the tool you create you own style classes based on default classes. You always see the attributes of the default definitions and can easily override.

For one control you may define several style variants that are easily pick-able when designing a dialog.

A short video “from the labs” shows how to use the tool for editing own style classes:

We introduced an new style – and started to publish the new style within the demo workplace. The new style will be positioned as default style for new projects.

The new style’s name is “defaultlightbluerisc”. All existing styles are still valid of course. For viewing the full demo workplace click >HERE<.

The yearly Community Meeting is approaching! This year’s date is: Thursday, Dec 07th 2017

All details – registration, logistics, agenda, hotels, locations, … – are available for download >HERE<.

The agenda includes interesting issues: new features in CaptainCasa WEB Client, deployment in SAP cloud platform, “Wowing!” your application, …

We invite all persons interested in CaptainCasa, Web technologies and Rich Client Systems to join the meeting. Attendance to the meeting is for free. – We are looking forward to meeting and seeing many of you!

We worked on the CALENDAR and the CALENDARFIELD component. Next week’s update will include some new functions. You may now plug information to each date of the calendar – including a tool tip text, a background color and the definition about if/how the user may select the date.

The usage may range from simple from-to-coloring…

…up to defining the data of a factory calendar:

We summarized the functions around the CALENDAR components in a small video, please take a look here:

The addon-package now comes with a PageBean-component for drawing diagrams and charts.

The chart library can be easily ind indivudually defined. Please take a look into the following presentation for overview information:

The inner structure is very flexible, e.g. you may use own PageBean implementations to be rendered inside the area of a shape.

There is a new component available BLOCKABLEAREA which allows to block all its content – regardless of what it contains – for any type of user interaction:

In the example the area on the left (grid + button) is switched to “blocked” when an item is selected – and it is unblocked when the item editing is finished. When being switched to “blocked” then a shading is applied in front of the area, so that there is a clear visual feedback to the user.

The BLOCKABLEAREA component allows to simply define scenarios in which one activity (here: grid navigation) must not be executed until another one (editing) is finished. The typical way to program such scenarios was before to use modal dialog popups, which then did block the whole UI processing. Now the blocking can be much more applied to a certain region, so that other regions are still usable.

By using the layering provided with the PAINTAREA component you may also block the background layer while the editing on the front layer is allowed.

We tidied up certain areas of our toolset.

The update includes:

• Quick access icons for important functions
  • Java API / Component API documentation
  • Tool for flat icon creation
  • Log of the application
• Consistent usage of flat icons throughout the whole toolset
• Tidy up of headers + contained icons
• Improved search for layouts